Comments 4
А как Kafka Connect ведет себя при повторной обработке данных после сбоя? Насколько реально получить дубли при падении worker’а между записью сообщения в Kafka и сохранением source offset, и как обычно решают эту проблему на практике?
Теперь ясно, кто занял мой ник :)))
Да, дубли возможны. Если запись уже ушла в Kafka, а source offset еще не успел сохраниться, после рестарта Connect может прочитать ее повторно. Поэтому обычно либо используют exactly-once, если конкретный connector это поддерживает, либо делают обработку идемпотентной, например по ключу
Это не этот Кафка Коннект, который вызывает бесконтрольный рост WAL, если неиспользуемый слот репликации не удалить. Может что и путаю, давно дела были...
Да, не путаете :) Но это скорее не Kafka Connect сам по себе, а PostgreSQL CDC-коннекторы типа Debezium. Они используют replication slot и если коннектор долго не читает его, то PostgreSQL вынужден удерживать WAL. Поэтому, если кратко, то да, могут
Kafka Connect без магии: как переносить данные и не писать еще один сервис