Автор:
SQLYARD,
Replication Across Engines — What to Use, When, and How to Mitigate Their Limitations
Репликация данных лежит в основе многих современных систем: обеспечение непрерывной работы (высокая доступность), катастрофоустойчивость (восстановление после сбоев), наполнение аналитических конвейеров или хранилищ, выполнение миграций или поддержка глобальных приложений и мульти-региональных требований к данным. Но не все инструменты и стратегии репликации одинаковы. Зачастую, вы сталкиваетесь с компромиссами, которые могут определять:
- Как фиксируются изменения (на основе журнала/логов, триггеры, загрузки изменений, пакетные загрузки);
- Насколько «в реальном времени» должна быть синхронизация (подойдут ли минуты, или нужен почти мгновенный обмен);
- Используют ли источник и приёмник одну и ту же СУБД или разные («гомогенная» vs «гетерогенная» репликация);
- Как вы справляетесь с различиями в схемах, эволюцией схем, идентификаторами/последовательностями, вычисляемыми полями и т. п.;
- Какие конфликты могут возникнуть при наличии более чем одного пишущего узла и как их разрешать;
- Операционная сложность, мониторинг, стоимость, лицензирование и т. д.
Каждая крупная реляционная СУБД (SQL Server, PostgreSQL, Oracle, MySQL…) использует свои внутренние механизмы (redo-журналы, журналы транзакций, binlog, WAL и т. п.), имеет нюансы типов данных и собственные ограничения. Репликация между разными СУБД часто усиливает эти несоответствия (например, SQL Server NVARCHAR(MAX) vs PostgreSQL TEXT; Oracle NUMBER vs SQL Server DECIMAL; MySQL JSON vs SQL Server JSON).
Ниже — сравнение ведущих инструментов (включая варианты, которые часто упускают), где они подходят, чего следует избегать и как смягчать типичные проблемы. Поскольку эта статья об SQL Server, для каждого инструмента приведена пометка о совместимости с SQL Server.
