Настройка отказоустойчивых кластеров и репликации для PostgreSQL и MariaDB: сравнение подходов

Введение: зачем нужна отказоустойчивость баз данных

Простой базы данных в production-среде означает остановку бизнес-процессов, потерю заявок и финансовые убытки. Для PostgreSQL и MariaDB, двух наиболее распространённых open-source СУБД, существуют два базовых механизма обеспечения высокой доступности: репликация и кластеризация. PostgreSQL предлагает потоковую репликацию с асинхронным или синхронным режимом, MariaDB использует кластер Galera для синхронной multi-master архитектуры. Эта статья содержит практические инструкции по настройке обоих решений, сравнение их характеристик и рекомендации по выбору под конкретную инфраструктуру.

Главный вопрос, который решает материал: как выбрать между master-slave репликацией PostgreSQL и multi-master кластером Galera для MariaDB. Ответ зависит от требований к консистентности, доступности и производительности. Мы разберём пошаговую настройку, типичные ошибки и процедуры обработки сбоев.

Основные понятия: репликация и кластеризация

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

Репликация: master-slave и её виды

Потоковая репликация PostgreSQL работает через передачу WAL-журнала (Write-Ahead Log) с мастера на реплики. Мастер записывает изменения в WAL, реплика получает поток этих записей и применяет их к своей копии данных. Асинхронный режим, используемый по умолчанию, передаёт WAL без ожидания подтверждения от реплики. При сбое мастера возможна потеря последних транзакций, которые не успели передаться. Задержка минимальна, производительность мастера практически не страдает.

Синхронный режим гарантирует фиксацию транзакции на реплике до подтверждения клиенту. Параметр synchronous_commit управляет этим поведением, а synchronous_standby_names определяет, какие реплики считаются синхронными. Транзакция на мастере ожидает подтверждения от синхронной реплики, что увеличивает latency, но обеспечивает нулевую потерю данных при отказе мастера.

Кластеризация: multi-master на примере Galera

Galera Cluster - это плагин для MariaDB, обеспечивающий синхронную multi-master репликацию. Все узлы содержат одинаковые данные. Транзакция подтверждается после получения подтверждений от всех узлов или кворума. Запись можно выполнять на любой узел, изменения синхронно реплицируются на остальные. Конфликты при одновременной записи в разных узлах разрешаются автоматически: если две транзакции изменяют одну строку, одна из них откатывается с ошибкой deadlock.

Ограничения Galera: требуется низкая задержка сети между узлами, все узлы должны находиться в одной подсети. Географическое распределение узлов по разным дата-центрам с высокой latency приведёт к деградации производительности.

Настройка потоковой репликации PostgreSQL

Потоковая репликация настраивается в три этапа: подготовка мастера, создание реплики, проверка состояния. Инструкция актуальна для PostgreSQL 12 и новее, где вместо recovery.conf используется файл standby.signal.

Подготовка мастера

В файле postgresql.conf мастера установите параметры:

wal_level = replica
max_wal_senders = 5
listen_addresses = '*'

Создайте роль для репликации:

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'strong_password';

В pg_hba.conf добавьте правило доступа для реплики:

host replication replicator 192.168.1.0/24 md5

Перезапустите PostgreSQL. Параметр wal_level = replica включает запись достаточного объёма данных в WAL для репликации, max_wal_senders определяет максимальное количество одновременных подключений реплик.

Создание и настройка реплики

На реплике выполните создание базовой копии с мастера:

pg_basebackup -h master_ip -U replicator -D /var/lib/postgresql/16/main -P -R

Флаг -R автоматически создаёт файл standby.signal и добавляет primary_conninfo в postgresql.auto.conf. Если флаг не использован, создайте файл вручную:

touch /var/lib/postgresql/16/main/standby.signal

В postgresql.auto.conf укажите:

primary_conninfo = 'host=master_ip port=5432 user=replicator password=strong_password'

Запустите PostgreSQL на реплике. Реплика начнёт получать WAL-поток и применять изменения.

Проверка и мониторинг репликации

На мастере выполните запрос:

SELECT client_addr, state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;

Состояние streaming означает активную репликацию. На реплике проверьте, что она находится в режиме восстановления:

SELECT pg_is_in_recovery();

Результат t подтверждает, что узел работает как реплика. Отставание реплики отслеживается по полям write_lag, flush_lag и replay_lag. Значительный рост replay_lag указывает на проблемы с производительностью реплики или сетью.

Настройка синхронной репликации PostgreSQL

Синхронный режим включается поверх существующей потоковой репликации. Мастер будет ожидать подтверждения от реплики перед фиксацией каждой транзакции.

Конфигурация синхронного режима

На мастере в postgresql.conf установите:

synchronous_commit = on
synchronous_standby_names = 'pgstandby1'

Значение pgstandby1 должно соответствовать имени реплики, указанному в параметре primary_conninfo через application_name. Для нескольких реплик с кворумом используйте синтаксис:

synchronous_standby_names = 'ANY 2 (node1, node2, node3)'

Это означает, что транзакция подтверждается после получения подтверждения от любых двух из трёх перечисленных реплик. Если синхронная реплика недоступна и нет других кандидатов, мастер приостановит обработку записей до восстановления связи.

Компромиссы синхронной репликации

Синхронная репликация гарантирует нулевую потерю данных при сбое мастера. Цена - увеличение задержки на каждую транзакцию и снижение пропускной способности. Используйте синхронный режим для критичных данных, где потеря даже одной транзакции недопустима: финансовые операции, заказы, медицинские записи. Для высоконагруженных систем с большим объёмом записей асинхронный режим с мониторингом отставания часто оказывается более практичным.

Развертывание кластера Galera для MariaDB

Кластер Galera разворачивается минимум из трёх узлов для обеспечения кворума и предотвращения split-brain. Инструкция применима для MariaDB 10.6 и новее с Galera 4.

Установка и базовая конфигурация

Установите пакеты на все узлы:

apt install mariadb-server galera-4

В файле /etc/mysql/mariadb.conf.d/50-server.cnf на каждом узле укажите:

[mysqld]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_address = 'gcomm://192.168.1.10,192.168.1.11,192.168.1.12'
wsrep_cluster_name = 'my_cluster'
wsrep_node_address = '192.168.1.10'
wsrep_sst_method = mariabackup

IP-адрес в wsrep_node_address меняется для каждого узла. Параметр wsrep_sst_method определяет метод передачи состояния новому узлу: mariabackup не блокирует донор, rsync проще, но требует блокировки.

Инициализация кластера и добавление узлов

На первом узле запустите кластер:

galera_new_cluster

На остальных узлах выполните обычный запуск MariaDB:

systemctl start mariadb

При присоединении нового узла происходит SST (State Snapshot Transfer) - полная синхронизация данных с донора. Для больших баз данных этот процесс может занять значительное время, поэтому выбирайте метод SST с учётом объёма данных.

Проверка работоспособности и синхронизации

На любом узле выполните:

SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_local_state_comment';

Значение wsrep_cluster_size должно равняться 3, wsrep_local_state_comment - Synced. Проверьте репликацию, создав таблицу на одном узле и прочитав её на другом. Запись должна появиться мгновенно.

Сравнение PostgreSQL репликации и MariaDB Galera

Ключевые различия в таблице

Сценарии использования: когда что выбирать

PostgreSQL с синхронной репликацией подходит для финансовых приложений, где критична нулевая потеря данных. Асинхронная репликация PostgreSQL - для географически распределённых систем, где узлы находятся в разных дата-центрах. Galera Cluster выбирают для высоконагруженных веб-приложений с балансировкой записи между узлами и требованием высокой доступности. Если нужен автоматический failover для PostgreSQL, используйте Patroni, который управляет переключением ролей и предотвращает split-brain.

Для инфраструктуры, где базы данных работают в Kubernetes, выбор оператора определяет поведение при сбоях. Подробное сравнение операторов для PostgreSQL, MariaDB и других СУБД с критериями выбора дано в руководстве по репликации и шардированию.

Типичные ошибки и подводные камни

Ошибки в PostgreSQL репликации

Забытая настройка pg_hba.conf для репликации - самая частая причина отказа подключения реплики. Мастер отклоняет соединение, в логах появляется ошибка аутентификации. Проверьте правило host replication до запуска pg_basebackup. Вторая ошибка: настройка synchronous_standby_names без резервной реплики. Если единственная синхронная реплика упала, мастер блокирует все записи. Всегда настраивайте минимум две синхронные реплики или используйте конструкцию ANY с кворумом.

Ошибки в Galera Cluster

Использование таблиц MyISAM в Galera не поддерживается. MyISAM не реплицируется, данные на узлах разойдутся. Переведите все таблицы в InnoDB до включения в кластер. Большие транзакции, изменяющие миллионы строк, вызывают задержки репликации и блокировки на всех узлах. Разбивайте крупные операции на пакеты. Конфликты при одновременной записи в разных узлах приводят к откату одной из транзакций с ошибкой deadlock - приложение должно обрабатывать такие ситуации и повторять запись.

Управление узлами и обработка сбоев

Failover в PostgreSQL

При отказе мастера выполните на реплике:

pg_ctl promote

Реплика станет новым мастером. Перенаправьте приложение на новый мастер. Старый мастер после восстановления перестройте как реплику через pg_basebackup. Для автоматизации используйте Patroni, который выполняет failover без ручного вмешательства. Резервное копирование остаётся критичным элементом стратегии отказоустойчивости - практики настройки бэкапов PostgreSQL и MySQL дополняют репликацию.

Управление узлами в Galera

Добавление узла: установите ПО, настройте конфигурацию, запустите MariaDB. SST автоматически синхронизирует данные. Удаление узла: остановите MariaDB и удалите узел из wsrep_cluster_address на остальных узлах. Восстановление после полного отказа: если все узлы упали, определите узел с наиболее актуальными данными, запустите его с параметром --wsrep-new-cluster, затем запустите остальные узлы обычным способом. Для предотвращения split-brain при чётном количестве узлов используйте Galera arbitrator - лёгкий процесс без данных, который участвует в голосовании кворума.

Заключение: выбор оптимального решения

PostgreSQL репликация - проверенное решение для master-slave архитектуры с возможностью синхронного режима для нулевой потери данных. Galera Cluster - мощный multi-master кластер для высокой доступности записи и горизонтального масштабирования. Оцените требования: консистентность, доступность, производительность, географическое распределение. Тестируйте выбранное решение в среде, приближенной к production, до внедрения. Настройте мониторинг состояния репликации и кластера с первого дня эксплуатации. Для размещения отказоустойчивых кластеров баз данных подойдёт облачная инфраструктура Timeweb Cloud с гибким масштабированием ресурсов.