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'ами только от мастер-ноды кластера. Если после падения мастера в качестве мастера будет выбран тот же узел - то коннектор восстановит подключение самостоятельно (возможно потребуется рестарт джоба), иначе - придется передать ему новую конфигурацию мастер узла кластера.
Конечная система в нашем случае - Elasticsearch, его индекс обновляется результатом окна (в финальной агрегации). Обращение к elastic выполняется один раз для каждого агрегата в окне.
Параллельно в отдельные индексы записывается каждое обновление отдельных таблиц Postgres. В этом случае да, пишем каждый "чих", впрочем для elasticsearch такое обращение проблем не представляет.
Верно, аналог есть и в Apache Flink, только называется иначе -
Operator State: https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/dev/datastream/fault-tolerance/state/#operator-state
Обладает довольно узкими сценариями использования, оттого не рассматривался.
Начну ответ со второй части.
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'ами только от мастер-ноды кластера. Если после падения мастера в качестве мастера будет выбран тот же узел - то коннектор восстановит подключение самостоятельно (возможно потребуется рестарт джоба), иначе - придется передать ему новую конфигурацию мастер узла кластера.
Конечная система в нашем случае - Elasticsearch, его индекс обновляется результатом окна (в финальной агрегации). Обращение к elastic выполняется один раз для каждого агрегата в окне.
Параллельно в отдельные индексы записывается каждое обновление отдельных таблиц Postgres. В этом случае да, пишем каждый "чих", впрочем для elasticsearch такое обращение проблем не представляет.