Настройка асинхронной репликации MySQL: Пошаговое руководство

Репликация MySQL — это фундаментальная функция для обеспечения высокой доступности, масштабируемости и надежных стратегий резервного копирования. Асинхронная репликация, наиболее распространенный тип, гарантирует, что данные, записанные на основной сервер (Master), в конечном итоге будут скопированы на один или несколько вторичных серверов (Slaves) без ожидания подтверждения транзакции со стороны Master.

Это полное руководство представляет собой подробное пошаговое руководство по настройке стандартной асинхронной репликации Master-Slave с использованием MySQL. Мы рассмотрим необходимые корректировки конфигурации сервера, настройку пользователей и критически важные шаги для инициализации синхронизации данных.

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

Перед началом настройки убедитесь, что у вас есть:

Два работающих сервера MySQL (Сервер A: Master, Сервер B: Slave).
Сетевое соединение между двумя серверами (обычно порт TCP 3306 должен быть открыт).
Права root или администратора для настройки обоих экземпляров MySQL и изменения конфигурационных файлов my.cnf или my.ini.

Для целей этого руководства мы предполагаем, что IP-адрес Master-сервера — 192.168.1.100, а IP-адрес Slave-сервера — 192.168.1.101.

Этап 1: Настройка Master-сервера

Master-сервер должен быть настроен для записи всех событий изменения данных в файл двоичного журнала (binary log), который будет читать Slave.

Шаг 1: Редактирование конфигурационного файла Master (`my.cnf`)

Найдите файл конфигурации MySQL (обычно /etc/mysql/my.cnf или /etc/my.cnf) и добавьте или измените следующие директивы в разделе [mysqld].

[mysqld]
# 1. Уникальный идентификатор этого сервера (должен быть больше 0)
server-id=1

# 2. Включить двоичное журналирование
log-bin=mysql-bin

# 3. Список баз данных для репликации (необязательно, но рекомендуется)
# binlog-do-db=mydatabase

# 4. Необязательно: Убедиться, что соединение использует TCP/IP, полезно для тестирования
# bind-address=0.0.0.0

Примечание: server-id должен быть уникальным для всех серверов, участвующих в топологии репликации.

Шаг 2: Перезапуск MySQL и проверка двоичного журналирования

После сохранения конфигурационного файла перезапустите службу MySQL на Master-сервере.

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

Войдите в интерфейс командной строки MySQL и проверьте, активно ли двоичное журналирование:

SHOW VARIABLES LIKE 'log_bin';
-- Значение должно быть ON

Шаг 3: Создание пользователя для репликации

Репликация требует выделенной учетной записи пользователя на Master-сервере с определенными привилегиями, которые Slave будет использовать для подключения и получения двоичных журналов. Убедитесь, что этот пользователь может подключаться удаленно с IP-адреса Slave (192.168.1.101).

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;

Шаг 4: Запись текущего статуса Master

Прежде чем продолжить, необходимо определить точное положение (файл и позицию) в двоичном журнале, с которого Slave должен начать чтение. Этот шаг критически важен для синхронизации.

FLUSH TABLES WITH READ LOCK; -- Временно приостановить запись
SHOW MASTER STATUS;

-- ВАЖНО: Запишите эти два значения:
-- File: mysql-bin.000001
-- Position: 1234

-- НЕ ВЫПОЛНЯЙТЕ UNLOCK TABLES, если вы делаете начальный снимок (Шаг 6)

Этап 2: Настройка Slave-сервера

Шаг 5: Редактирование конфигурационного файла Slave (`my.cnf`)

Настройте Slave-сервер с уникальным идентификатором и необязательными параметрами.

[mysqld]
# Уникальный идентификатор этого сервера (должен отличаться от Master)
server-id=2

# Необязательно: Рекомендуется для безопасности
read_only=1

# Необязательно: Включить ретрансляционное журналирование
relay_log=mysql-relay-bin

Перезапустите службу MySQL на Slave-сервере после сохранения изменений.

Шаг 6: Начальная передача данных (снимок)

Если Slave-сервер пуст, его необходимо заполнить текущей структурой данных и содержимым Master. Этот начальный снимок должен быть сделан пока таблицы Master заблокированы (из Шага 4).

С Master-сервера выполните команду mysqldump. Мы используем флаг --master-data=2 для автоматического включения необходимой инструкции CHANGE MASTER TO в файл дампа, что упрощает Шаг 7.

# Выполнить на консоли/оболочке Master-сервера
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# Теперь вернитесь в CLI MySQL Master и снимите блокировку
UNLOCK TABLES;

Передайте master_dump.sql на Slave-сервер и импортируйте его:

# Выполнить на консоли/оболочке Slave-сервера
mysql -u root -p < master_dump.sql

Лучшая практика: Использование master-data=2 настоятельно рекомендуется, поскольку оно автоматически фиксирует правильную позицию двоичного журнала в начале дампа.

Этап 3: Инициализация репликации

Шаг 7: Определение соединения с Master

В интерфейсе командной строки MySQL Slave-сервера выполните команду CHANGE MASTER TO, подставив значения, записанные на Шаге 4, и пользователя, созданного на Шаге 3.

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- Файл, записанный на Шаге 4
    MASTER_LOG_POS=1234;              -- Позиция, записанная на Шаге 4

Шаг 8: Запуск репликации и проверка

После определения параметров соединения запустите репликационные потоки Slave.

START SLAVE;

Проверьте, что репликационные потоки работают и корректно взаимодействуют, используя команду SHOW SLAVE STATUS:

SHOW SLAVE STATUS\G

Изучите вывод на предмет следующих критически важных полей:

Поле	Ожидаемое значение	Описание
`Slave_IO_Running`	`Yes`	Slave успешно подключается к Master.
`Slave_SQL_Running`	`Yes`	Slave применяет транзакции к своей базе данных.
`Seconds_Behind_Master`	`0` или небольшое число	Указывает на задержку репликации. Должна быстро упасть до 0.

Если Slave_IO_Running или Slave_SQL_Running показывает No, изучите поля Last_IO_Error или Last_SQL_Error для получения подсказок по устранению неполадок (например, проблемы с брандмауэром, неверные учетные данные, дубликаты ключей).

Советы по устранению неполадок и обслуживанию

Обработка ошибок репликации

Если Slave сталкивается с ошибкой (например, попытка вставить дублирующий первичный ключ), поток Slave_SQL_Running остановится. Обычно мелкие, некритические ошибки можно обойти, используя:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

Предупреждение: Используйте SQL_SLAVE_SKIP_COUNTER с осторожностью. Пропуск транзакций может привести к расхождению данных (несогласованности) между Master и Slave.

Проверка согласованности

Хотя асинхронная репликация эффективна, она не гарантирует немедленной согласованности. Для критически важных сред используйте такие инструменты, как pt-table-checksum из Percona Toolkit, для периодической проверки расхождения данных между Master и Slave.

Управление двоичными журналами

Двоичные журналы со временем потребляют дисковое пространство. Настройте срок действия журналов на Master, чтобы предотвратить чрезмерное использование диска:

[mysqld]
# Удалять двоичные журналы старше 7 дней (604800 секунд)
expire_logs_days=7