Репликация базы данных — автоматическая синхронизация данных между несколькими серверами СУБД в реальном времени. При отказе primary-сервера реплика принимает запросы — это основа high availability. Репликация также разгружает primary: читающие запросы отправляются на реплики.
Типы репликации
- Master-Slave (Primary-Replica)
- Запись только на primary, чтение с реплик. Простая настройка. Широко распространена в MariaDB/MySQL и PostgreSQL. Failover выполняется вручную или через Orchestrator.
- Master-Master (Multi-Primary)
- Запись на любой из нодов, изменения синхронизируются. Требует разрешения конфликтов при одновременной записи. Реализован в Galera Cluster для MariaDB.
- Синхронная репликация
- Транзакция подтверждается только после записи на все реплики. Защищает от потери данных, но увеличивает latency на время сетевого round-trip.
- Асинхронная репликация
- Primary подтверждает транзакцию сразу, реплики получают изменения с задержкой. Быстрее, но при падении primary возможна потеря последних транзакций (replication lag).
Репликация в PostgreSQL
PostgreSQL использует WAL (Write-Ahead Log) для репликации. Варианты:
- Streaming replication — реплика получает WAL-сегменты в реальном времени (PostgreSQL 9.0, 2010). Минимальный lag.
- Logical replication — репликация отдельных таблиц по строкам, совместима между разными версиями PostgreSQL (PostgreSQL 10, 2017).
- Patroni — автоматический failover для PostgreSQL: Etcd/Consul/ZooKeeper хранят состояние кластера.
Репликация в MySQL/MariaDB
MySQL/MariaDB использует binlog (binary log) — журнал всех изменений данных. Форматы: statement-based (SQL-операторы), row-based (изменённые строки — точнее, рекомендован), mixed. MariaDB Galera Cluster — синхронная multi-primary репликация: все ноды равноправны, запись на любую.
История
Репликация появилась в MySQL 3.23 (2001) как statement-based. PostgreSQL добавил WAL-based streaming replication в версии 9.0 (октябрь 2010). Galera Cluster разработан Codership в 2007 году, выпущен как open source в 2009. Logical replication в PostgreSQL 10 (2017) стала долгожданной функцией для частичной репликации таблиц.
На что обращать внимание
Ключевая метрика — replication lag: насколько реплика отстаёт от primary в секундах. В MySQL: SHOW SLAVE STATUS\G → Seconds_Behind_Master. В PostgreSQL: SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay. Допустимый lag зависит от требований: для финансовых транзакций — 0, для аналитики — минуты приемлемы.
Резервное копирование не заменяет репликацию: бэкап — защита от удаления данных, репликация — от отказа оборудования. Нужны оба.
Инструменты управления репликацией
Percona Toolkit — набор утилит для MySQL/MariaDB: pt-table-checksum проверяет консистентность данных между primary и репликами, pt-slave-restart автоматически перезапускает упавшую репликацию. Оркестраторы failover: Orchestrator (Booking.com), MHA (MySQL Master HA).
Для PostgreSQL — Grafana с плагином PostgreSQL отображает метрики репликации: lag в секундах, WAL-позиции, состояние реплик. Мониторинг сервера через Prometheus + postgres_exporter — стандартная связка для production-кластеров.