Репликация

Что такое репликация

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

Три причины, по которым репликацию включают:

• Отказоустойчивость. Сгорел диск на основном сервере — реплика становится основной, данные не потеряны.
• Масштабирование чтения. Тяжёлые SELECT и отчёты уходят на реплики, разгружая основной узел.
• Резерв и география. Копия в другом ЦОД переживает аварию в первом.

Термины «репликация», «реплицирование», «репликация БД» означают одно и то же. Роли узлов называют primary/replica (раньше — master/slave), в MongoDB — primary/secondary.

Важно: репликация — это не бэкап

Самое дорогое заблуждение в теме. Репликация повторяет все изменения, включая ошибочные: DELETE FROM orders без WHERE приедет на реплику за миллисекунды и уничтожит данные там же. Она защищает от отказа железа, но не от ошибки человека, бага приложения или шифровальщика — от них спасает только резервное копирование с историей.

Синхронная и асинхронная

Практический компромисс: синхронная реплика в том же ЦОД (RTT доли миллисекунды), асинхронная — в удалённом. Синхронная репликация через континент превращает каждый COMMIT в ожидание десятков миллисекунд.

Топологии

• Primary → реплики. Пишем в один узел, читаем из многих. Простая и предсказуемая схема, покрывает большинство задач.
• Multi-master. Пишем в несколько узлов, нужен механизм разрешения конфликтов. Сложно, применяют осознанно.
• Каскад. Реплика реплики — снижает нагрузку на основной узел при большом числе копий.

Репликация копирует одни и те же данные целиком; шардирование наоборот разрезает данные на части. В больших системах их комбинируют: каждый шард имеет свои реплики.

PostgreSQL: потоковая репликация

Основана на WAL — журнале, куда PostgreSQL пишет изменения до применения к файлам данных. Реплика подключается к основному узлу и непрерывно получает поток WAL.

# На primary, postgresql.conf
wal_level = replica
max_wal_senders = 10
synchronous_commit = on
# synchronous_standby_names = 'replica1'   # раскомментировать для синхронной

# Снять базовую копию и запустить реплику
pg_basebackup -h primary.internal -U replicator -D /var/lib/postgresql/data -R -P

-- Отставание реплики в байтах, смотреть с primary
SELECT client_addr, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

Помимо потоковой, Postgres умеет логическую репликацию (CREATE PUBLICATION / CREATE SUBSCRIPTION) — она переносит отдельные таблицы и работает между разными мажорными версиями, чем удобна при переездах.

MySQL: репликация через binlog

# my.cnf на primary
server-id = 1
log_bin = mysql-bin
binlog_format = ROW

-- На реплике
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='primary.internal', SOURCE_USER='repl',
  SOURCE_PASSWORD='secret', SOURCE_AUTO_POSITION=1;
START REPLICA;
SHOW REPLICA STATUS\G   -- смотреть Seconds_Behind_Source

В MySQL изменения пишутся в бинарный журнал и проигрываются на реплике. binlog_format = ROW надёжнее STATEMENT: переносятся сами изменения строк, а не SQL-запросы, которые на реплике могут дать иной результат.

Лаг репликации

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

Лаг растёт от долгих транзакций, массовых UPDATE, медленного диска на реплике и узкого канала. Метрику pg_stat_replication или Seconds_Behind_Source выводят в мониторинг (Zabbix, Prometheus) с алертом на превышение порога.

Failover

Переключение на реплику бывает ручным и автоматическим. Автоматику дают внешние средства: Patroni для PostgreSQL, Orchestrator для MySQL, Sentinel для Redis. Главный риск — split-brain, когда после разрыва сети два узла считают себя основными и принимают запись независимо. Поэтому решение о смене лидера принимают через кворум, а не одним наблюдателем.

Связанные термины

• Резервное копирование — то, что репликация не заменяет
• Шардирование — разрезание данных вместо копирования
• PostgreSQL — потоковая и логическая репликация
• MySQL / MariaDB — репликация через binlog
• Кластер — группа узлов с репликацией и failover
• SLA и отказоустойчивость — зачем всё это нужно бизнесу