Database replication: Master-slave

Репликация баз данных — это фундаментальный механизм для обеспечения отказоустойчивости и высокой доступности в современных распределенных системах. Однако она порождает сложные проблемы согласованности данных, управления задержками и обработки конфликтов, которые часто упускают из виду при поверхностном подходе к проектированию.

Технические вызовы репликации

Основная дилемма репликации — это компромисс между согласованностью данных, доступностью и устойчивостью к разделению сети (теорема CAP). Master-slave и master-master подходы предлагают разные решения этой дилеммы, но оба требуют глубокого понимания внутренних механизмов БД для корректной реализации.

Master-slave репликация: Асимметричная архитектура

В архитектуре master-slave (или primary-replica) существует четкое разделение ролей: один узел обрабатывает все операции записи, а остальные — только чтение. Это создает предсказуемую модель работы, но порождает единую точку отказа.

Механизм работы

1. Master обрабатывает все запросы на запись и транзакционно фиксирует изменения в журнал (binary log для MySQL, WAL для PostgreSQL)
2. Slaves подключаются к master через специальный репликационный поток
3. Slaves асинхронно (или синхронно в зависимости от конфигурации) считывают изменения и применяют их к своим копиям данных
4. Операции чтения могут распределяться по slave-узлам для снижения нагрузки на master

# Конфигурация master (my.cnf)
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
# Обязательные параметры для репликации
sync-binlog = 1
innodb_flush_log_at_trx_commit = 1

# Конфигурация slave (my.cnf)
[mysqld]
server-id = 2
relay-log = mysql-relay-bin
read-only = 1
slave-net-timeout = 60

Узкие места в продакшене

• Задержка репликации: Особенно критична для систем с сильной согласованностью. В асинхронной репликации возможна ситуация чтения “устаревших” данных.
• Проблемы с failover: Процедура переключения master требует остановки всех записей на время переноса данных.
• Ограничения масштабирования: Master становится узким местом для операций записи, что ограничивает общую производительность системы.
• Риск потери данных: В асинхронной репликации возможна потерча данных, если master падает до их отправки на slaves.

Master-master репликация: Симметричная архитектура

В модели master-master (или multi-master) все узелы могут выполнять операции записи. Каждый узел одновременно является и master, и slave для других узлов в кластере. Эта модель сложнее, но обеспечивает лучшую доступность и распределенную нагрузку.

Механизм работы

1. Любой узел может принимать операции записи
2. Изменения фиксируются локально и реплицируются на все остальные узлы
3. Механизм разрешения конфликтов обрабатывает ситуации, когда один и тот же ресурс изменяется на разных узлах
4. Существуют разные модели согласованности: eventual, causal, или strong

# Конфигурация узла 1 (my.cnf)
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
auto-increment-offset = 1
auto-increment-increment = 2
# Отключаем проверку уникальности между узлами
slave-skip-errors = all

# Конфигурация узла 2 (my.cnf)
[mysqld]
server-id = 2
log-bin = mysql-bin
binlog-format = ROW
auto-increment-offset = 2
auto-increment-increment = 2

Узкие места в продакшене

• Конфликты записи: Возникают при одновременном изменении данных на разных узлах. Требуют сложной логики разрешения.
• Сложность управления: Увеличивается количество состояний, которые нужно мониторить.
• Риск расхождения данных: При ошибках сети или конфигурации возможны несоответствия между узлами.
• Снижение производительности: Конфликтующие записи могут приводить к откатам транзакций и снижению общей производительности.

Когда что выбирать

Master-slave репликация подходит:

• Системы с четким разделением операций чтения и записи
• Приложения, где допуст eventual consistency
• Высоконагруженные системы с преобладанием чтения
• Когда важна простота настройки и мониторинга

Master-master репликация подходит:

• Системы, требующие максимальной доступности (99.9%+)
• Распределенные географически приложения
• Системы с равномерной нагрузкой на чтение и запись
• Когда важна отказоустойчивость, а не абсолютная согласованность

Практические рекомендации

Из моего опыта работы с высоконагруженными системами, ключевой аспект успешной репликации — это не просто настройка параметров, а понимание бизнес-требований к согласованности данных. В одном проекте мы использовали гибридную модель: master-slave для основной нагрузки и master-master для резервных зон с механизмом автоматического переключения при недоступности основного master.

Для мониторинга репликации используйте метрики:

• Задержка репликации (seconds behind master)
• Размер бинарных журналов
• Частота ошибок репликации
• Пропускная способность потоков репликации

Всегда тестируйте сценарии отказоустойчивости в staging-окружении, которое максимально приближено к продакшену. В реальных условиях проблемы репликации часто проявляются только под высокой нагрузкой или в специфических крайних случаях.

В конечном счете, выбор между master-slave и master-master — это компромисс между сложностью, доступностью и согласованностью. Нет универсального решения, подходящего для всех случаев.