Мы используем Apache Flink job cluster в Kubernetes, который состоит из одного Job Manager и двух Task Managers с двумя слотами каждый. Кластер развертывается и настраивается с использованием структуры Lightbend Cloudflow.
Мы также используем серверную часть состояния RocksDB вместе с S3-совместимым хранилищем для сохранения состояния. При создании обоих savepoints из CLI проблем нет. Наша работа состоит из нескольких ключевых состояний (MapState) и имеет тенденцию быть довольно большой (мы ожидаем не менее 150 ГБ на каждое состояние). Restart Strategy для задания устанавливается на Failure Rate. Мы используем Apache Kafka как источник и приемник на протяжении всей нашей работы.
В настоящее время мы проводим некоторые тесты (в основном Po C), и есть несколько вопросов:
Мы сделали некоторые Syntheti c тестируют и передают в задание неверные события. Это ведет к Exceptions, брошенным во время казни. Из-за стратегии Failure Rate выполняются следующие шаги: Сообщение Corrupted от Kafka читается через источник -> Оператор пытается обработать событие и в конечном итоге выдает Exception -> Задание перезапускается и читает ТО ЖЕ запись из Kafka, как на предыдущем шаге -> Оператор терпит неудачу -> Failure Rate наконец превышает заданное значение, и работа в конечном итоге останавливается. Что я должен делать дальше? Если мы попытаемся перезапустить задание, кажется, что оно будет восстановлено с последним состоянием потребителя Kafka и снова прочитает поврежденное сообщение, что приведет нас к ранее упомянутому поведению? Каковы правильные шаги, чтобы справиться с такими проблемами? И использует ли Flink какие-либо так называемые Dead Letter Queues?
Другой вопрос касается механики контрольных точек и восстановления. В настоящее время мы не можем определить, какие исключения, возникшие во время выполнения задания, считаются критическими и приводят к сбою задания, после которого происходит автоматическое c восстановление с последней контрольной точки? Как было описано в предыдущем случае, обычное Exception, инициированное внутри задания, приводит к непрерывным перезапускам, за которыми, наконец, следует завершение задания. Мы ищем случаи для воспроизведения, когда что-то происходит с нашим кластером (Job Manager сбой, Task Manager сбой или что-то в этом роде), что приводит к автоматическому восстановлению c с последней контрольной точки. Любые предложения приветствуются, учитывая такой сценарий в кластере Kubernetes.
Мы погрузились в официальную документацию Flink, но не нашли никакой связанной информации или, возможно, неправильно ее восприняли. Большое спасибо!