Comments 11
Только два решения? А почему инструменты репликации master-slave СУБД не подошли? Работа для DBA, Java знать не надо, Кафка не нужна ..
Кстати, в диаграмме последовательности обычно есть и обратные стрелки. По ним можно косвенно оценить атомарность действий - от отправил и забыл до подтверждения распределенной транзакции end to end. Какова надёжность описанной репликации?
Потому что Алексей не описал изначальную задачу, а она такая: каждый датацентр - самостоятельный, любой датацентр может быть потерян, пользователь может прийти в один датацентр, продолжить в другом, репликация full-mesh. Поэтому физическая репликация не подходит.
При использовании Kafka экспертиза в Java может быть околонулевая, Для debezium её нужно побольше.
Как решаете проблему с изменением структуры таблиц? Добавление нового поля, например, символьного типа: Kafka/Debezium позволяют передать изменения и в таблице получателе, но новое поле будет максимальной длины. А еще веселее если мы добавим поле GUID оно приедет в получатель тоже как строка максимальной длины - привет индексам.
Как решаете проблему консистентности? Например документ состоит из нескольких записей таблице строк и записи в заголовочной таблице. Как гарантировать что на клиенте документ обрабатывается либо полностью переданный, либо не обрабатывается вовсе. Я пришел к решению, что такие данные передаются в кафку в виде JSON - документа и распаковываются на стороне клиента, но это плохо ложится в стек кафка+дебезиум. Может быть есть более элегантные решения?
Причем Кафка не гарантирует что сообщение не будет отправлено повторно. Сколько партиций участвует в репликации, используются ли оффсеты и как. Самое интересное осталось не раскрытыми.
Сделали у себя репликацию с Debezium т.к. нет других решений для репикации MSSQL -> PostgreSQL
Часто ломается, не изза ошибок, а других технических причин.
Две проблемы написали выше: "изменением структуры таблиц", неконсистентность.
Хочу его удалить и сделать свой аналог :-) уговариваю начальство
У нас нет сложных отношений в базах, а там где были - разорвали. В постгресе логическая репликация отдаёт транзакцию полностью, от begin до commit, т.е. отдаваемые данные консистентны. Дебезиум уплощает поток данных, и в общем случае не приспособлен под вашу задачу. Либо нужно денормализовать данные в базе, либо писать свой клиент логической репликации с учётом транзакций. Кстати, это несложно, дебезиум у нас в процессе замены на своё.
Мне нравится решение Debezium + Kafka. Удобно собирать данные для аналитики в DWH. Из Oracle, PostgreSQL, MySQL, MongoDB. И складывать это в Clickhouse, BigQuery. Правда коннектор от Clickhouse не может создавать таблицы автоматически, структуру не обновляет, с датой плохо работает. Пришлось потратить 2 выходных и расширить эти функции самому. Сейчас работает как часы! Может тоже написать статью на тему Как готовить Debezium?
Репликация данных с использованием Debezium и Kafka