Настройка MySQL-слейва через SSL

Требования и пояснения

Сервер-мастер должен быть уже настроен и иметь экспортированный SQL-дамп (snapshot.sql) и данные из SHOW MASTER STATUS; с указанием имени бинарного лога и позиции.
На слейве доступ к root MySQL или учетная запись с правами для создания базы и настройки репликации.
На слейве должны быть SSL-файлы: ca-cert.pem, client-cert.pem, client-key.pem в указанном пути.
Пояснение: server-id — уникальный числовой идентификатор для каждого экземпляра MySQL в кластере репликации.

1. Редактирование /etc/my.cnf на слейве

Откройте конфигурацию на сервере-слейве (server2):

vi /etc/my.cnf

В секции [mysqld] проверьте и добавьте следующие строки (сохраните существующие параметры):

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# По умолчанию используем старый формат паролей для совместимости с клиентами mysql 3.x
old_passwords=1
ssl
server-id=2
master-connect-retry=60
replicate-do-db=exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Важно: значение server-id должно быть уникальным и отличаться от server-id мастера.

2. Перезапуск MySQL на слейве

Перезапустите службу, чтобы применить изменения:

/etc/init.d/mysqld restart

Если система использует systemd, используйте: systemctl restart mysqld (это зависит от дистрибутива).

3. Создание пустой базы и импорт дампа

Создайте пустую базу exampledb на сервере-слейве:

mysql -u root -p

В интерактивной консоли MySQL выполните:

CREATE DATABASE exampledb;
quit;

Остановите slave-IO при необходимости и импортируйте дамп (на слейве):

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

После импорта подключитесь к MySQL снова:

mysql -u root -p

4. Установка параметров мастера (CHANGE MASTER TO)

Теперь нужно настроить слейв так, чтобы он подключался к мастеру. Очень важно заменить значения MASTER_LOG_FILE и MASTER_LOG_POS на те, что вы получили с мастера командой SHOW MASTER STATUS; а также правильно указать адрес мастера и данные для репликации.

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

Короткие пояснения к полям:

MASTER_HOST — IP или DNS-имя мастера (в примере 192.168.0.100).
MASTER_USER — пользователь, которому на мастере выдали права REPLICATION SLAVE.
MASTER_PASSWORD — пароль этого пользователя на мастере.
MASTER_LOG_FILE и MASTER_LOG_POS — значения из SHOW MASTER STATUS; на мастере.
MASTER_SSL — включает использование SSL для соединения слейва с мастером.
MASTER_SSL_CA, MASTER_SSL_CERT, MASTER_SSL_KEY — пути к SSL-файлам на слейве.

Запустите слейв:

START SLAVE;

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

SHOW SLAVE STATUS \G

Ожидаемый признак успешной репликации: в выводе должны быть

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

А также при использовании SSL должны быть заполнены поля Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert и Master_SSL_Key.

Пример вывода SHOW SLAVE STATUS:\G

************************* 1. row *************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.100
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 3096416
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: exampledb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 3096416
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/newcerts/client-key.pem
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

После успешной проверки выйдите из MySQL:

quit;

Теперь все изменения в базе exampledb на мастере будут реплицироваться на слейв.

Частые ошибки и как их исправлять

Slave_IO_Running = No или Slave_SQL_Running = No
- Проверьте /var/log/mysqld.log и /var/log/syslog. Частая причина — неправильный MASTER_LOG_FILE или MASTER_LOG_POS.
- Для ошибок авторизации проверьте, что MASTER_USER и MASTER_PASSWORD корректны и пользователь имеет права REPLICATION SLAVE на мастере.
SSL не установился (поля MasterSSL* пусты)
- Убедитесь, что файлы сертификатов доступны процессу mysqld и что указанные пути верны.
- Проверьте права доступа к файлам: владелец mysql, права 600 для приватного ключа.
Несовпадение структур БД
- Если структура таблиц отличается, репликация SQL-режима может упасть. Всегда синхронизируйте схемы перед импортом.
Seconds_Behind_Master > 0 и постоянно растёт
- Проверьте нагрузку на слейве: медленные запросы, блокировки, недостаток I/O.

Когда это не сработает (контрпримеры)

Если вы используете разные версии MySQL с несовместимыми формами бинарных логов, репликация может не работать.
Если дамп сделан с пропуском таблиц или с включёнными триггерами, которые влияют на порядок выполнения, возможны конфликты.
При использовании GTID без корректной настройки старых бинарных логов стратегия CHANGE MASTER TO по файлу/позиции может быть неприменима.

Альтернативные подходы

GTID-based replication — более современный способ управления позициями репликации (используйте при поддержке версии сервера).
File-based backup + restore — применимо при первом развёртывании слейва без прямого подключения к мастеру.
MySQL Group Replication или Percona XtraDB Cluster — для мульти-мастерной репликации и автоматического переключения.

Контрольный список (Role-based)

DBA:
- Получить SHOW MASTER STATUS с мастера.
- Выдать пользователю права REPLICATION SLAVE.
DevOps:
- Развернуть SSL-файлы, проверить права доступа и пути в конфиге.
- Перезапустить службу и контролировать логи.
QA/разработчик:
- Проверить, что данные в exampledb на слейве соответствуют мастеру после тестовой записи.

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

Slave_IO_Running: Yes и Slave_SQL_Running: Yes.
Seconds_Behind_Master: близко к нулю при тестовой записи.
Поля MasterSSL* заполнены и путь к CA/сертификатам корректен.

Быстрые рекомендации по безопасности

Храните приватный ключ в защищённом каталоге с правами доступа 600 и владельцем mysql.
Используйте пользователя с минимальными правами: только REPLICATION SLAVE.
Ограничьте доступ по сети: firewall/iptables, разрешая подключение к порту 3306 только между мастером и слейвом.

Короткая методология тестирования

Сделать контрольную запись в exampledb на мастере.
Проверить появление записи на слейве.
При расхождениях смотреть SHOW SLAVE STATUS и логи.

Глоссарий (1 строка)

master — сервер, на котором записываются изменения; slave (слейв) — сервер, который читает эти изменения и применяет их локально.

Краткое резюме

Следуйте шагам: отредактируйте /etc/my.cnf на слейве, перезапустите сервис, создайте пустую базу, импортируйте дамп, выполните CHANGE MASTER TO с указанием SSL-параметров и проверьте SHOW SLAVE STATUS. При проблемах проверяйте логи и соответствие схемы.