Репликация MySQL на Fedora 10

TL;DR

Краткое руководство по настройке master-slave репликации MySQL на двух серверах Fedora 10. Вы настроите master (server1) и slave (server2), зафиксируете позицию бинлога, снимете дамп, импортируете его на slave и запустите репликацию.

Введение

Версия 1.0
Автор: Falko Timme

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

Я использую Fedora 10 как для master, так и для slave в этом руководстве. Это один из возможных способов настройки; он не гарантирует работу в любой среде.

Окружение (preliminary)

В примере используются два сервера:

server1.example.com (IP 192.168.0.100): master
server2.example.com (IP 192.168.0.101): slave

Мы будем реплицировать базу exampledb с server1 на server2. Предполагается, что MySQL уже установлен на обеих машинах и база exampledb с таблицами и данными уже существует на master, но отсутствует на slave.

1. Настройка master (server1)

Создайте директорию для бинарных логов MySQL и выставьте владельца:

mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql

Отредактируйте /etc/my.cnf и в секции [mysqld] укажите, какие базы логировать, имя бинлога и идентификатор сервера. Мы хотим реплицировать exampledb, поэтому добавьте следующие строки в секцию [mysqld]:

vi /etc/my.cnf

| [mysqld] [...] log-bin = /var/log/mysql/mysql-bin.log binlog-do-db=exampledb server-id=1 [...] |

Перезапустите MySQL:

/etc/init.d/mysqld restart

Войдите в MySQL как root и создайте пользователя для репликации:

mysql -u root -p

(Введите пароль root при запросе.)

В MySQL shell выполните:

STOP SLAVE;
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';
FLUSH PRIVILEGES;

Зафиксируйте текущее состояние master, заблокировав таблицы, чтобы получить согласованную точку для дампа:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Команда SHOW MASTER STATUS вернёт имя файла бинлога и позицию, например:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |       98 | exampledb    |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Важно записать значения File и Position — они понадобятся на slave.

Пока таблицы заблокированы, в отдельной командной оболочке сделайте дамп и скопируйте его на slave:

cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

Вернитесь в первую MySQL-сессию и снимите блокировку:

UNLOCK TABLES;
quit;

Важно: не снимайте блокировку раньше, чем завершается создание и передача дампа. Блокировка нужна для согласованного снимка.

2. Настройка slave (server2)

На slave укажите, что это slave, и задайте параметры подключения к master. Добавьте в секцию [mysqld] /etc/my.cnf:

vi /etc/my.cnf

| [mysqld] [...] server-id=2 master-host=192.168.0.100 master-user=slave_user master-password=slave_password master-connect-retry=60 replicate-do-db=exampledb [...] |

Перезапустите MySQL:

/etc/init.d/mysqld restart

Создайте пустую базу exampledb на slave (при необходимости остановите slave):

mysql -u root -p

(Введите пароль.)

STOP SLAVE;
CREATE DATABASE exampledb;
quit;

Импортируйте дамп, который вы скопировали на server2:

cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Подключитесь снова к MySQL и укажите мастера, используя ранее записанные MASTER_LOG_FILE и MASTER_LOG_POS:

mysql -u root -p

Затем выполните (замените значения на полученные с master):

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=98;

Запустите репликацию:

START SLAVE;

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

SHOW SLAVE STATUS\G

В выводе обязательно проверяйте, что Slave_IO_Running и Slave_SQL_Running равны Yes. Пример вывода:

mysql> 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: 98
             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: 98
            Relay_Log_Space: 235
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

mysql>

Если значения не равны Yes, проверьте /var/log/mysqld.log и параметры подключения.

Проверка работы и тест

Вставьте/обновите/удалите строку в exampledb на master и убедитесь, что изменения появились на slave.
На slave проверьте Seconds_Behind_Master — 0 или небольшое число означает актуальность реплики.

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

На slave SHOW SLAVE STATUS показывает Slave_IO_Running: Yes и Slave_SQL_Running: Yes.
Данные в exampledb на master и slave совпадают после внесения изменений.
Логи ошибок пусты или содержат только информационные сообщения.

Быстрый чеклист для администратора

На master: настроен log-bin и server-id, binlog-do-db содержит нужную базу.
На master: создан пользователь репликации с привилегией REPLICATION SLAVE.
Выполнен FLUSH TABLES WITH READ LOCK и создан дамп в одной транзакции/снимке.
На slave: server-id отличен от master, заданы параметры master-host и master-user.
На slave: импортирован дамп, выполнен CHANGE MASTER TO и запущен START SLAVE.
Проверен SHOW SLAVE STATUS и логи.

Шаблон команд — cheat sheet

Перезапуск MySQL:

/etc/init.d/mysqld restart

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

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';
FLUSH PRIVILEGES;

Получить позицию бинлога на master:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
UNLOCK TABLES;

Копирование дампа на slave:

mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

На slave: установить параметры мастера и запустить репликацию:

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=98;
START SLAVE;
SHOW SLAVE STATUS\G

Отладка и частые проблемы

Slave_IO_Running = No — проверьте сетевое соединение, правильно ли указаны MASTER_HOST/MASTER_USER/MASTER_PASSWORD и доступ ли у slave_user с этого хоста.
Slave_SQL_Running = No — проверьте ошибки в Last_Error из SHOW SLAVE STATUS; возможно, конфликты данных или несовместимость структур таблиц.
Неверная позиция бинлога — убедитесь, что при создании дампа вы использовали согласованную точку (FLUSH TABLES WITH READ LOCK и SHOW MASTER STATUS) и затем импортировали этот же дамп на slave.
Права доступа к файлам логов — проверьте владельца /var/log/mysql и права на запись.

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

Используйте отдельного пользователя с минимальными привилегиями для репликации.
Ограничьте доступ для slave_user по IP-адресу вместо ‘%’ в GRANT.
Рассмотрите включение SSL для соединения репликации при передаче данных по ненадёжным сетям.
Регулярно проверяйте целостность бинлогов и состояние репликации.

Дополнительные варианты и улучшения

Multi-source репликация: один slave может принимать данные от нескольких master (требует более сложной настройки).
Асинхронная vs semi-synchronous репликация: по умолчанию MySQL репликация асинхронная; для меньшего риска потери данных изучите semi-sync плагины.
Использование Percona XtraBackup для создания онлайн-снимков без блокировок (подходит для больших баз).

Факто-бокс

Не путать репликацию с резервным копированием — репликация отражает все операции.
Ключевые параметры: log-bin, server-id, binlog-do-db, replicate-do-db, MASTER_LOG_FILE, MASTER_LOG_POS.
Обязательно проверяйте SHOW SLAVE STATUS после запуска репликации.

Вывод

Следуя шагам выше, вы настроите простую master-slave репликацию MySQL между двумя серверами Fedora 10. Проверяйте состояние репликации регулярно и применяйте рекомендации по безопасности.