Тёплая копия базы данных на другом хостинге: минимальная репликация MySQL и PostgreSQL

Для небольшого сайта или интернет-магазина полноценный отказоустойчивый кластер баз данных — явный перебор: он стоит дороже самого бизнеса, который должен защищать. Разумная цель скромнее — чтобы на случай отказа основного хостинга существовала актуальная копия данных на другом сервере, которую можно быстро поднять вручную. Это называется тёплой копией (warm standby): она обновляется в реальном времени, но не принимает трафик сама и не переключается автоматически — решение о переключении принимает человек.

Ниже — минимальная настройка такой копии для MySQL/MariaDB и для PostgreSQL, без дополнительных инструментов оркестрации. Всё проверено на двух реальных машинах (Debian 12 и Debian 13 — версии баз в примерах сознательно разные, это тоже часть проверки).

MySQL и MariaDB: встроенная репликация

У MariaDB (и совместимого с ней MySQL) репликация встроена в сам сервер — отдельный пакет не нужен. Источник записывает все изменения в бинарный журнал (binlog), а копия подключается к источнику как клиент и повторяет эти изменения у себя.

На источнике нужно включить журнал и задать уникальный идентификатор сервера:

# /etc/mysql/mariadb.conf.d/60-repl.cnf — на источнике
[mysqld]
server_id = 1
log_bin = /var/lib/mysql/mariadb-bin
binlog_format = ROW
bind-address = 0.0.0.0

binlog_format = ROW означает, что в журнал пишутся сами изменённые строки, а не SQL-команды, которые их изменили — это надёжнее, потому что устраняет расхождения, способные возникнуть при использовании в запросах недетерминированных функций (например, NOW() или RAND(), дающих разный результат на источнике и на копии). Дальше — пользователь для репликации, доступный только с адреса второго хостинга:

CREATE USER 'repl'@'<адрес_копии>' IDENTIFIED BY '<пароль>';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'<адрес_копии>';

На стороне копии — свой идентификатор сервера и подключение по GTID (Global Transaction ID — глобальному номеру транзакции, одинаковому на источнике и на копии; с ним не нужно вручную искать позицию в журнале, как того требовал более старый способ настройки):

CHANGE MASTER TO MASTER_HOST='<адрес_источника>',
                  MASTER_USER='repl', MASTER_PASSWORD='<пароль>',
                  MASTER_USE_GTID=slave_pos,
                  MASTER_SSL=0;
START SLAVE;

Строка MASTER_SSL=0 понадобилась не для красоты: при проверке на MariaDB 11.8 копия без этого параметра сразу выдавала ошибку SSL is required, but the server does not support it, хотя шифрование соединения никто не запрашивал явно — в этой версии клиент репликации пытается использовать TLS по умолчанию. Без настроенного сертификата на источнике проще отключить попытку явно, чем разбираться с сертификатами ради тестовой задачи; для реального хостинга, если трафик репликации идёт через открытый интернет (а не через приватную сеть провайдера), TLS всё же стоит настроить — соединение между источником и копией иначе передаётся открытым текстом, включая пароль, которым их обменивались при подключении, и всё содержимое базы.

Состояние копии проверяется одной командой:

SHOW SLAVE STATUS\G

Два поля решают всё: Slave_IO_Running: Yes означает, что копия получает журнал с источника, Slave_SQL_Running: Yes — что она успешно применяет полученные изменения. Seconds_Behind_Master при этом показывает отставание в секундах — на проверке оно было нулевым: запись, вставленная на источнике, появилась на копии практически мгновенно.

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

У PostgreSQL принцип тот же — журнал транзакций (WAL, Write-Ahead Log) передаётся с основного сервера (primary) на резервный (standby), только настройка устроена иначе: копия создаётся не с нуля, а как точная бинарная копия текущего состояния базы, к которой затем подключается поток изменений.

Важное условие, которое легко упустить: версия PostgreSQL на обоих серверах должна совпадать — потоковая репликация работает на уровне внутреннего формата страниц данных, и он может отличаться между основными версиями. Если два хостинга дают разные версии ОС с разными версиями PostgreSQL «из коробки» (в проверке так и было — Debian 12 и Debian 13 ставят по умолчанию PostgreSQL 15 и 17 соответственно), на обоих серверах нужно поставить одну и ту же версию явно через официальный репозиторий проекта (apt.postgresql.org), а не через системный пакет.

На основном сервере:

ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET max_wal_senders = 5;
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD '<пароль>';
SELECT pg_create_physical_replication_slot('standby_shop');

Слот репликации (replication slot) — это именованная резервация места в журнале на стороне основного сервера: пока копия подключена к этому слоту, основной сервер не удалит журнальные файлы, даже если копия временно отстала или отключилась. Без слота основной сервер может очистить нужный копии журнал раньше, чем она успеет его забрать, и тогда копию придётся пересоздавать с нуля.

В pg_hba.conf нужна строка, разрешающая репликацию только с адреса второго хостинга:

host replication replicator <адрес_копии>/32 scram-sha-256

Сама копия создаётся одной командой, выполняемой на будущем резервном сервере — она скачивает полную копию базы с основного сервера и сразу настраивает подключение для продолжения потока:

pg_basebackup -h <адрес_источника> -U replicator -D /var/lib/postgresql/17/main -P -R -X stream -S standby_shop

Ключ -R создаёт файл standby.signal и записывает параметры подключения к основному серверу — вручную их прописывать не нужно, команда делает это сама. После запуска сервера на копии SELECT pg_is_in_recovery(); возвращает t (true) — сервер в режиме восстановления из потока, то есть и есть резервный, а не основной. На основном сервере состояние репликации видно в pg_stat_replication: поле replay_lag показывает задержку применения — при проверке она составила около одной миллисекунды.

Что эта настройка не защищает

Важно понимать границы минимального решения, а не только то, что оно умеет.

Репликация — не резервная копия. Повторяет она в первую очередь ошибки, а не защищает от них: случайная команда DELETE без условия, повреждённые данные, работа программы-шифровальщика — всё это реплика честно повторит на себе за секунды. Резервные копии (регулярные дампы, хранящиеся отдельно и с версионированием по времени) нужны в любом случае, независимо от того, настроена репликация или нет.

Переключение — вручную. Это тёплая, а не горячая копия: при отказе основного сервера приложение не переключится на резервный само — нужно вручную остановить режим восстановления на PostgreSQL (pg_promote()) или переконфигурировать MariaDB из копии в самостоятельный сервер, и вручную же переключить адрес, на который смотрит приложение. Автоматическое переключение — это другая, кластерная задача, и для небольшого магазина его стоимость обычно не оправдана.

Порт базы открыт наружу. В примерах выше брандмауэр ограничивает доступ к портам 3306 и 5432 только адресом второго хостинга, но порт по-прежнему слушает на внешнем интерфейсе. Для чуть более защищённой схемы вместо прямого разрешения по IP-адресу уместнее туннель (например, WireGuard) между двумя серверами — тогда порт базы не виден в интернете вовсе, а трафик идёт через шифрованный канал. Это уже следующий шаг после минимального, в этой статье он не разворачивался отдельно.

Итог

И MySQL/MariaDB, и PostgreSQL умеют вести актуальную копию на другом сервере средствами, которые уже есть в самой базе, без установки дополнительного программного обеспечения. Настройка в обоих случаях — несколько параметров и одна команда создания копии; разница в том, что MariaDB подключается к существующей базе сразу, а PostgreSQL сначала копирует её целиком. Для небольшого сайта или магазина, где сама задача — «чтобы было куда переключиться вручную при аварии», а не «ноль секунд простоя», это разумный минимум: дешевле кластера, но ощутимо надёжнее, чем ничего.

Источники: документация MariaDB (Standard Replication, GTID), документация PostgreSQL 17 (Streaming Replication, pg_basebackup).