Debezium и некоторые мои исследования
Q: возможно ли переключить коннектор на другой сервер?
A: это делается через удаление коннектора методом delete и создания нового. Можно сделать обновление через PUT, но через delete надёжнее. Подробнее можно смотреть доку к кафка коннекторам. в доке дебезиума этого нихрена нет.
Q: можно ли объединить коннекторы в один топик? в том смысле что мы запускаем 2 дебезиума на разных серверах, например.
А: Как показали тесты, нет. записи в schemas_history начинают дублироваться, а параметры коннектора вообще в случае разнесения на разные группы не могут быть никак в одних топиках, иначе будет работать только один коннектор из двух. В итоге на каждый коннектор должен быть 5 топиков: 3 для хранения параметров коннектора и 2 для хранения схемы базы и истории изменений схемы.
Q: что происходит при ротации binlog, если коннектор был выключен
A: Если бинлог не удалился, но отротировался, то будет запрошен существующий бинлог и продолжит с последнего считанного места. После чего постепенно перейдет на чтение актуального бинлога.
Q: можно ли чтобы изменения с разных коннекторов, которые читаю разные таблицы писать в один топик?
А: да, это делается через трансформации, описывается регулярное выражение источник и из него можно формировать целевое название очереди. Этот же прицип можно использовать для переименования топика. Только у них есть
баг что это не работает в некоторых версиях. помимо указанной версии я это еще в 1.1 встретил. в 1.3 всё ок.
Q: добавление новой таблицы "на лету"
A: Схема создается дебезиумом при первом инсерте в таблицу. и далее на лету подхватывается. Если таблица только создана и пустая, то это не поедет в кафку.
Q: как правильно настроить retention на топиках?
А: согласно
документации требуется бесконечный или очень долгий только на history топиках Infinite (or very long) retention (no compaction!), partition count of 1. И на всех нужно выставить cleanup.policy=compact
В итоге мы делаем как-то так:
--partitions 1 --replication-factor 3 --config
retention.ms=-1 --config min.insync.replicas=1 --config cleanup.policy=compact
Q: Можно ли полностью контролировать имена топиков в кафке?
А: да, вполне.
database.server.name - это просто логическое имя. оно будет использовано по-умолчанию как префикс для именования топика с данными (что не очень удобно), но к счастью все топики с данными через трансформацию можно переименовать.
statuses configs offsets - топики которые мы можем создать с любым именем и при старте дебезиума указать их в env.
схему можно задать в конфиге например так: "
database.server.name": "debezium.database_name.logical_connector_name.schema"
историю схемы: "database.history.kafka.topic": "debezium.database_name.logical_connector_name.history"
а затем через трансформацию переименовать целевые топики с данными
"transforms": "Reroute",
"transforms.Reroute.type": "io.debezium.transforms.ByLogicalTableRouter",
"transforms.Reroute.topic.regex": "debezium.logical_connector_name.logical_connector_name.schema.<REGEXP>",
"transforms.Reroute.topic.replacement": "my_fucking_awesome_new_name_with_group_capture_$1",
#debezium #mysql #kafka
