MariaDB Master‑Master на Debian 11

Диаграмма архитектуры master-master

Введение

Этот подробный путеводитель описывает, как настроить MariaDB в режиме master-master («взаимная» репликация) на двух серверах Debian 11. Тут же показана синхронизация времени с помощью Chrony и базовая защита трафика MariaDB через UFW. Материал ориентирован на системных администраторов и DBA с базовыми знаниями Linux и MariaDB.

Коротко о преимуществах master-master:

Высокая доступность записи с двух узлов.
Горизонтальное распределение нагрузки на запись (с оговорками).
Быстрая репликация изменений при корректной настройке и синхронизации часов.

Когда master-master может не подойти:

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

Важно: это руководство не заменяет политики бэкапа и мониторинга. Перед развёртыванием в проде протестируйте сценарии аварийного восстановления.

Короткие определения (1‑строчные)

Master-Master репликация: двунаправленная репликация, где оба узла принимают запись и реплицируют изменения друг другу.
Binary log (binlog): журнал изменений, используемый для репликации.
Chrony: клиент/демон для синхронизации времени (альтернатива ntp/chrony).

Предварительные требования

Минимум два сервера с Debian 11 (в примере — master1 и master2).
Пользователь с sudo-привилегиями.
Базовые навыки работы с shell и редактором (nano/vi).

Быстрая структура руководства

Настройка FQDN и /etc/hosts
Синхронизация времени через Chrony
Установка MariaDB из официального репозитория
Настройка UFW
Конфигурация master1 и master2
Создание пользователя репликации и запуск slave-процессов
Тестирование репликации
Безопасность, мониторинг, откат и отладка

Настройка FQDN и /etc/hosts

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

IP Address      Hostname    FQDN
---------------------------------------------------
192.168.5.10    master1     master1.localdomain.io
192.168.5.11    master2     master2.localdomain.io

Установите FQDN на каждом сервере:

sudo hostnamectl set-hostname master1.localdomain.io

# на втором сервере
sudo hostnamectl set-hostname master2.localdomain.io

Отредактируйте /etc/hosts на каждом хосте:

sudo nano /etc/hosts

Добавьте строки:

192.168.5.10    master1.localdomain.io  master1
192.168.5.11    master2.localdomain.io  master2

Проверьте резолв с помощью ping:

ping -c 3 master1
ping -c 3 master2

Примечание: пинги служат простым способом проверки, но для более серьёзной диагностики используйте ss/sshd и tl;dr проверки сетевого соединения.

Синхронизация времени с Chrony

Почему это важно

Репликация в MariaDB опирается на журналы binlog с позициями и временными метками; расхождение часов между серверами может затруднить диагностику и вызвать неожиданные поведения при конфликтных сценариях.

Установка Chrony:

sudo apt update
sudo apt install chrony

Запуск и включение сервиса:

sudo systemctl start chrony
sudo systemctl enable chrony

Проверка статуса:

sudo systemctl status chronyd

Настройка часового пояса и включение NTP:

sudo timedatectl set-timezone Europe/Stockholm --adjust-system-clock
sudo timedatectl set-ntp yes

Проверка:

timedatectl
chronyc sources
chronyc tracking

установка chrony

Проблемы и советы

Если chronyc sources показывает отсутствие серверов, проверьте сеть и доступ к внешним NTP-серверам или настройте локальный NTP-сервер.
Для изолированных сетей добавьте один из мастер‑узлов как локальный источник времени и пометьте его в конфиге Chrony на других узлах.

Установка MariaDB (репозиторий MariaDB)

Здесь мы установим MariaDB из официального репозитория, чтобы получить нужную версию.

Установите зависимости:

sudo apt install gnupg2 apt-transport-https software-properties-common

Импорт ключа подписи репозитория:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Добавьте репозиторий MariaDB (пример для 10.8.3):

sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.8.3/debian bullseye main'
sudo apt update

Установка пакета:

sudo apt install mariadb-server

Проверьте статус сервиса:

sudo systemctl is-enabled mariadb
sudo systemctl status mariadb
ss -plnt | grep mysql

установка mariadb

Замечания по безопасности после установки:

Запустите mysql_secure_installation для базовой жёсткой настройки учётных записей и отключения анонимных пользователей (при желании — вручную).
По умолчанию MariaDB привязана к 0.0.0.0 или 127.0.0.1 в зависимости от пакета — мы изменим bind-address вручную.

Настройка брандмауэра UFW

Использование UFW ограничивает доступ к портам сервиса. В примере разрешён доступ к MariaDB только из сети 192.168.5.0/24.

Установка UFW:

sudo apt install ufw

Разрешаем OpenSSH и включаем UFW:

sudo ufw allow OpenSSH
sudo ufw enable

Открываем порты MariaDB и вспомогательные порты для репликации (TCP): 3306, 4567, 4568, 4444.

На master1 (192.168.5.10):

sudo ufw allow from 192.168.5.0/24 to 192.168.5.10 port 3306 proto tcp
sudo ufw allow from 192.168.5.0/24 to 192.168.5.10 port 4567 proto tcp
sudo ufw allow from 192.168.5.0/24 to 192.168.5.10 port 4568 proto tcp
sudo ufw allow from 192.168.5.0/24 to 192.168.5.10 port 4444 proto tcp

На master2 (192.168.5.11) аналогично:

sudo ufw allow from 192.168.5.0/24 to 192.168.5.11 port 3306 proto tcp
# и т.д.

Проверка:

sudo ufw status verbose

UFW правила

Советы:

Избегайте открытия MariaDB в публичный интернет без VPN/IP-allowlist.
При использовании Orchestration/Cloud может быть лучше управлять доступом на сетевом уровне (security groups).

Конфигурация master1 (192.168.5.10)

Остановите MariaDB перед внесением изменений:

sudo systemctl stop mariadb

Отредактируйте файл /etc/mysql/mariadb.conf.d/50-server.cnf и добавьте под [mysqld]:

[mysqld]
bind-address = 192.168.5.10

server-id              = 1
report_host            = master1

log_bin                = /var/log/mysql/mariadb-bin
log_bin_index          = /var/log/mysql/mariadb-bin.index

relay_log              = /var/log/mysql/relay-bin
relay_log_index        = /var/log/mysql/relay-bin.index

Пояснения:

server-id должен быть уникален для каждого мастера.
report_host устанавливает значение, отображаемое в SHOW SLAVE STATUS.
Путь к бинарным логам может быть перенесён на отдельный диск для производительности.

Перезапустите сервис и убедитесь, что MariaDB слушает нужный IP:

sudo systemctl start mariadb
ss -plnt | grep mysqld

конфиг master1

Создайте пользователя репликации и получите положение binlog:

sudo mysql -u root -p

CREATE USER 'replusr'@'%' IDENTIFIED BY 'replusr';
GRANT REPLICATION SLAVE ON *.* TO 'replusr'@'%';
FLUSH PRIVILEGES;

SHOW MASTER STATUS;
quit

Примечание: в продакшне замените пароль на сильный, используйте пользователь с минимальными правами и TLS.

создание пользователя репликации

Конфигурация master2 (192.168.5.11)

Шаги для master2 похожи на master1, но server-id и report_host другие.

Остановите MariaDB, отредактируйте /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
bind-address = 192.168.5.11

server-id              = 2
report_host            = master2

log_bin                = /var/log/mysql/mariadb-bin
log_bin_index          = /var/log/mysql/mariadb-bin.index

relay_log              = /var/log/mysql/relay-bin
relay_log_index        = /var/log/mysql/relay-bin.index

Запустите MariaDB и проверьте список прослушиваемых адресов:

sudo systemctl start mariadb
ss -plnt | grep mysqld

конфиг master2

Создайте того же пользователя репликации на master2 (должен совпадать логин/пароль):

sudo mysql -u root -p

CREATE USER 'replusr'@'%' IDENTIFIED BY 'replusr';
GRANT REPLICATION SLAVE ON *.* TO 'replusr'@'%';
FLUSH PRIVILEGES;
quit

На master2 укажите параметры master (указываем master1 как источник) и запустите slave:

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='replusr', MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=773;
START SLAVE;
SHOW SLAVE STATUS\G

В выводе должны быть строки Slave_IO_Running: Yes и Slave_SQL_Running: Yes. Затем выполните SHOW MASTER STATUS; чтобы убедиться, что у master2 есть свои binlog и позиция.

master2 статус

Запуск master-master (добавление master2 как мастер для master1)

Вернитесь на master1 и укажите master2 как источник:

sudo mysql -u root -p

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='master2', MASTER_USER='replusr', MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=773;
START SLAVE;
SHOW SLAVE STATUS\G
quit

После этого репликация должна работать в обе стороны: изменения, выполненные на master1, появятся на master2 и наоборот.

добавление master2 в master1

Тестирование репликации (практическая проверка)

На master1 создаём БД и таблицу и вставляем запись:

sudo mysql -u root -p
CREATE DATABASE testdb;
USE testdb;

CREATE TABLE users (id INT AUTO_INCREMENT,
  firstname VARCHAR(30),
  lastname VARCHAR(30),
  date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY(id));

INSERT INTO users(firstname,lastname) VALUES ('Alice','Wonders');
SELECT * FROM users;
quit

создание БД

На master2 проверяем наличие БД и вставляем ещё одну запись:

sudo mysql -u root -p
SHOW DATABASES;
USE testdb;
INSERT INTO users(firstname,lastname) VALUES ('Bob','Burgers');
SELECT * FROM users;
quit

вставка на master2

Вернувшись на master1, вы должны увидеть обе записи:

SELECT * FROM users;

проверка на master1

Проверка прошла успешно — репликация работает в обе стороны.

Частые проблемы и их решение

Slave_IO_Running: No / Slave_SQL_Running: No

Проверьте сеть и DNS (ping, ss, telnet 3306).
Убедитесь, что учётные данные репликации совпадают и пользователь имеет REPLICATION SLAVE.
Проверьте binlog файл и позицию — они должны существовать на мастере.

Ошибки форматов/структур таблиц

Если структуры таблиц не совпадают, репликация INSERT/UPDATE может проваливаться. Всегда синхронизируйте DDL или используйте pt-online-schema-change.

Zаписи с конфликтующими первичными ключами

Для AUTO_INCREMENT настройте auto_increment_increment и auto_increment_offset, чтобы избежать пересечений:

# в конфигурации [mysqld]
auto_increment_increment = 2
auto_increment_offset = 1  # на master1
# на master2 offset = 2

Смещение времени/TTL/кэширования

Убедитесь, что Chrony работает и time drift минимален.

Сбой диска/логов binlog повреждён

Имейте резервную стратегию: регулярные дампы (mysqldump, mariabackup) и прямая проверка целостности журналов.

Безопасность и hardening

Рекомендации:

Включите шифрование соединений (TLS) между мастерами: создайте сертификаты и настройте [client] и [mysqld] на использования REQUIRE SSL для репликационного пользователя.
Ограничьте доступ к порту 3306 только по IP-адресам/сетям.
Не используйте простой пароль replusr в проде; применяйте менеджер секретов.
Отключите удалённый root-доступ: удалите root@”%” если он есть.
Включите аудит и логирование медленных запросов.

Пример включения TLS для репликации (фрагмент конфигурации):

# в [mysqld]
mysqld_tls_cert=/etc/mysql/certs/server-cert.pem
mysqld_tls_key=/etc/mysql/certs/server-key.pem

# при создании пользователя
CREATE USER 'replusr'@'%' IDENTIFIED BY 'StrongPassword' REQUIRE SSL;

Бэкапы и откат (короткий план)

Регулярные бэкапы: mariabackup или xtrabackup для больших БД.
Перед выполнением глобальных изменений сделайте полный бэкап и сохраните текущие binlog-имена/позиции.
План отката: остановить запись на одном узле, восстановить данные на нём из бэкапа, пересинхронизовать binlog если требуется.

SOP / Playbook — краткий пошаговый план для развёртывания (для инженера)

Подготовка ОС: обновление, настройка hostname и /etc/hosts.
Установить Chrony и синхронизировать время.
Установить MariaDB из репозитория и установить зависимости.
Настроить UFW: разрешить OpenSSH и доступ к MariaDB по внутренней сети.
Отредактировать /etc/mysql/mariadb.conf.d/50-server.cnf: задать bind-address, server-id, binlog.
Перезапустить MariaDB.
Создать пользователя репликации на каждом узле с одинаковыми правами и паролем.
На одном узле выполнить SHOW MASTER STATUS; и сохранить file/position.
На другом узле выполнить CHANGE MASTER TO … с данными из шага 8; START SLAVE; и проверить SHOW SLAVE STATUS.
Повторить зеркально для второго узла.
Тест: создать базу/таблицу/запись на одном узле, проверить на другом.
Настроить мониторинг и бэкапы.

Ролевые чек-листы

Для системного администратора:

Настроить hostname и /etc/hosts.
Обеспечить сетевую связанность и правила UFW.
Установить и настроить Chrony.
Установить MariaDB и подготовить конфигурацию server-id/binlog.

Для DBA:

Создать пользователя репликации.
Проверить корректность схемы БД и DDL.
Настроить параметры auto_increment при необходимости.
Планировать бэкапы и откатные сценарии.

Критерии приёмки

Slave_IO_Running: Yes и Slave_SQL_Running: Yes на обоих узлах.
Данные, вставленные на одном узле, появляются на другом в течение ожидаемого окна задержки.
Chrony показывает синхронизированное время между узлами (drift минимален).
UFW блокирует доступ снаружи и разрешает доступ внутри выделенной сети.

Тестовые случаи и проверки

Тест 1: вставка строки на master1 -> проверка США появления на master2 через SELECT.
Тест 2: вставка строки на master2 -> проверка на master1.
Тест 3: создать схему на master1 (DDL) и убедиться, что DDL корректно реплицируется (внимание: блокирующие DDL операции могут приводить к проблемам).
Тест 4: отключить сеть между мастерами и проанализировать поведение репликации при восстановлении.

Шпаргалка (cheat sheet) — важные команды

Остановить/запустить MariaDB:

sudo systemctl stop mariadb
sudo systemctl start mariadb
sudo systemctl restart mariadb

Проверки сетевых слушателей:

ss -plnt | grep mysqld
sudo ufw status

MariaDB: создать репликационного пользователя:

CREATE USER 'replusr'@'%' IDENTIFIED BY 'replusr';
GRANT REPLICATION SLAVE ON *.* TO 'replusr'@'%';
FLUSH PRIVILEGES;

Настройка мастера/слейва:

SHOW MASTER STATUS;
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='replusr', MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=773;
START SLAVE;
SHOW SLAVE STATUS\G

Простая диаграмма принятия решения (Mermaid)

flowchart TD
  A[Начало: есть два сервера Debian11?] -->|Да| B{Синхронное время?}
  B -->|Нет| C[Установить Chrony и синхронизировать]
  B -->|Да| D{MariaDB установлена?}
  D -->|Нет| E[Установить MariaDB из репозитория]
  D -->|Да| F{Конфигурация server-id и binlog настроена?}
  F -->|Нет| G[Изменить 50-server.cnf, задать bind-address, server-id, log_bin]
  F -->|Да| H[Создать пользователя репликации]
  H --> I[Настроить CHANGE MASTER на каждом узле]
  I --> J[START SLAVE и проверка Slave_IO_Running/Slave_SQL_Running]
  J --> K[Тестовая вставка данных и проверка]
  K --> L[Готово]

Заключение

Поздравляем — вы настроили двунаправленную репликацию MariaDB (master-master) на Debian 11, синхронизировали время через Chrony и ограничили доступ через UFW. Дальше — настроить TLS для репликации, автоматизированные бэкапы и мониторинг (Prometheus/Alertmanager, Grafana) для эксплуатации в продакшне.

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

Настройте FQDN и hosts.
Синхронизируйте время с Chrony.
Установите MariaDB, включите binlog и назначьте уникальные server-id.
Создайте пользователя репликации, выполните CHANGE MASTER и START SLAVE на обоих узлах.
Протестируйте, включив контрольные вставки и проверки.

проверка статуса chrony