Комментарии 4
Вот у вас во flint оконная агрегация перед тем как записать в конечную систему(наверно база).
Флинт же не умеет отправлять только конечный результат окна , а делает как kafka в стрим.
Тоесть на каждый чих вы делаете апдейт в базе ?
Конечная система в нашем случае - Elasticsearch, его индекс обновляется результатом окна (в финальной агрегации). Обращение к elastic выполняется один раз для каждого агрегата в окне.
Параллельно в отдельные индексы записывается каждое обновление отдельных таблиц Postgres. В этом случае да, пишем каждый "чих", впрочем для elasticsearch такое обращение проблем не представляет.
Так как под капотом крутится дебезиум, то ему, получается, нужен мастер кластера postgres, с реплик он не умеет читать же? Тестировали switchover и failover мастера postgres на предмет потери данных в вашей целевой бд, куда складываете сообщения об изменениях в бд?
Начну ответ со второй части.
Switchover/failover мастера PG не тестировал, но так как репликация WAL выполняется через logical slot'ы, указатели в которых сохраняются только во время чекпоинтов, при падении мастера есть риск получить указатель на более ранний LSN, чем тот, что был обработан фактически. При этом, насколько я могу судить, embedded Debezium сохраняет последний обработанный LSN в локальном стейте, таким образом дедуплицируя возможные дубли событий изменений. То есть в worst-case scenario получаем семантику at-least-once на стороне падающего мастера, которая амортизируется дедупликацией Debezium. Своего рода effectively exactly-once. Но запись в конечные системы я бы все же рекомендовал реализовывать идемпотентной.
По первой части вопроса:
PG 9.6 умеет работать с logical slot'ами только от мастер-ноды кластера. Если после падения мастера в качестве мастера будет выбран тот же узел - то коннектор восстановит подключение самостоятельно (возможно потребуется рестарт джоба), иначе - придется передать ему новую конфигурацию мастер узла кластера.
Потоковый захват изменений из PostgreSQL/MySQL с помощью Apache Flink