Гид по технологиям

Настройка MariaDB Master-Master репликации на Debian 11

• 8 min read • Databases • Обновлено 24 Nov 2025
MariaDB Master‑Master на Debian 11 — пошагово
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).

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

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

Настройка 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)

  1. Остановите MariaDB перед внесением изменений:
sudo systemctl stop mariadb
  1. Отредактируйте файл /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.
  • Путь к бинарным логам может быть перенесён на отдельный диск для производительности.
  1. Перезапустите сервис и убедитесь, что MariaDB слушает нужный IP:
sudo systemctl start mariadb
ss -plnt | grep mysqld

конфиг master1

  1. Создайте пользователя репликации и получите положение 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 другие.

  1. Остановите 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
  1. Запустите MariaDB и проверьте список прослушиваемых адресов:
sudo systemctl start mariadb
ss -plnt | grep mysqld

конфиг master2

  1. Создайте того же пользователя репликации на master2 (должен совпадать логин/пароль):
sudo mysql -u root -p

CREATE USER 'replusr'@'%' IDENTIFIED BY 'replusr';
GRANT REPLICATION SLAVE ON *.* TO 'replusr'@'%';
FLUSH PRIVILEGES;
quit
  1. На 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

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

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

  1. Slave_IO_Running: No / Slave_SQL_Running: No
  • Проверьте сеть и DNS (ping, ss, telnet 3306).
  • Убедитесь, что учётные данные репликации совпадают и пользователь имеет REPLICATION SLAVE.
  • Проверьте binlog файл и позицию — они должны существовать на мастере.
  1. Ошибки форматов/структур таблиц
  • Если структуры таблиц не совпадают, репликация INSERT/UPDATE может проваливаться. Всегда синхронизируйте DDL или используйте pt-online-schema-change.
  1. Zаписи с конфликтующими первичными ключами
  • Для AUTO_INCREMENT настройте auto_increment_increment и auto_increment_offset, чтобы избежать пересечений:
# в конфигурации [mysqld]
auto_increment_increment = 2
auto_increment_offset = 1  # на master1
# на master2 offset = 2
  1. Смещение времени/TTL/кэширования
  • Убедитесь, что Chrony работает и time drift минимален.
  1. Сбой диска/логов 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;

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

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

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

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

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

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

  • Настроить 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

проверка timezone

установка зависимостей

проверка сервиса mariadb

Поделиться: X/Twitter Facebook LinkedIn Telegram
Автор
Редакция

Похожие материалы

Как устроить идеальную вечеринку для просмотра ТВ
Развлечения

Как устроить идеальную вечеринку для просмотра ТВ

Как распаковать несколько RAR‑файлов сразу
Инструменты

Как распаковать несколько RAR‑файлов сразу

Приватный просмотр в Linux: как и зачем
Приватность

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

Windows 11 не видит iPod — способы исправить
Руководство

Windows 11 не видит iPod — способы исправить

PS5: как настроить игровые пресеты
Консоли

PS5: как настроить игровые пресеты

Как переключить камеру в Omegle на iPhone и Android
Руководство

Как переключить камеру в Omegle на iPhone и Android