Что такое репликация базы данных и зачем она нужна

Репликация простыми словами

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

Самая распространённая схема — primary-replica (её же называют leader-follower, а в старой документации master-slave):

• Primary принимает все записи.
• Реплики получают поток изменений от primary и применяют их.
• Приложение может читать с реплик, а писать — только в primary.

PostgreSQL передаёт репликам журнал предзаписи (WAL), MySQL — бинарный лог (binlog). Суть одна: каждое изменение на primary воспроизводится на копиях.

Зачем она нужна

• Высокая доступность. Если основной сервер вышел из строя, у реплики уже есть почти все данные, и она может принять нагрузку за секунды или минуты, а не за часы восстановления.
• Масштабирование чтения. Отчёты, поиск и аналитика работают на репликах и не тормозят основную нагрузку.
• География. Реплика ближе к пользователям или в другом дата-центре снижает задержки и переживает аварию площадки.
• Безопасные тяжёлые операции. Длинные выгрузки и аналитические запросы можно запускать на реплике.

Синхронная и асинхронная репликация

Асинхронная репликация — вариант по умолчанию в большинстве схем: быстро, но реплики немного отстают. Синхронная гарантирует, что подтверждённые данные есть в двух местах, ценой скорости и доступности. Часто комбинируют: одна синхронная реплика рядом, остальные асинхронные. В MySQL есть ещё промежуточный полусинхронный режим.

Масштабирование чтения и отставание реплик

Отправлять чтение на реплики удобно, но помните про отставание (replication lag): реплика может отставать от primary на миллисекунды, а под нагрузкой — заметно больше.

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

• Какое-то время после изменения читать «свои записи» с primary.
• Критичные чтения (балансы, платежи, остатки) держать на primary.
• Мониторить отставание и убирать из пула чтения реплики, которые слишком отстали.

Переключение при сбое (failover)

Failover — передача роли primary реплике, когда основной сервер упал.

• Ручной failover: инженер повышает реплику и перенастраивает приложение. Просто, но медленно, особенно ночью.
• Автоматический failover: инструменты вроде Patroni для PostgreSQL или встроенные механизмы облачных управляемых баз сами обнаруживают сбой и повышают реплику.

Главная опасность — split-brain, когда два сервера одновременно считают себя primary и принимают записи. Правильный автоматический failover опирается на консенсус или кворум и изолирует старый primary. Регулярно тестируйте переключение: непроверенный failover обычно ломается именно тогда, когда нужен.

Репликация — это не бэкап

Репликация честно копирует каждое изменение, в том числе ошибочное:

• DROP TABLE или неудачный UPDATE без WHERE за мгновения доходят до всех реплик.
• Баги приложения, портящие данные, тоже реплицируются.
• Вирус-шифровальщик или взломанная учётная запись затрагивают все копии.

Нужны резервные копии, которые хранятся отдельно, в идеале с восстановлением на момент времени (PITR), чтобы вернуть состояние прямо перед ошибкой. Отложенная реплика, применяющая изменения с фиксированной задержкой, помогает поймать ошибку, но бэкапы не заменяет.