Репликация MySQL
Данная статья является вольным и сокращённым переводом официальной документации!
Настройка
master-сервер[1]
На master-сервере необходимо включить бинарные логи и установить уникальный server ID. Если бинарные логи не включены, то репликация не будет работать. После установки потребуется перезагрузка MySQL-сервера.
Для обеспечения целостности данных рекомендуется включить опции innodb_flush_log_at_trx_commit и sync_binlog. Параметр innodb_flush_log_at_trx_commit
позволяет выбрать стратегию сброса данных на диск при работе MySQL:
- 0 - наибольшая производительность. В этом случае буфер будет сбрасываться в лог файл независимо от транзакций. В этом случае риск потери данных возрастает.
- 1 - любая завершенная транзакция будет синхронно сбрасывать лог на диск. Это вариант по-умолчанию, он является самым надежным с точки зрения сохранности данных, но самым медленным по скорости работы.
- 2 - любая завершенная транзакция будет синхронно сбрасывать лог в кеш операционной системы (т.е. не происходит flush после каждой операции). Это значение подойдет в большинстве случаев, т.к. не выполняет дорогой операции записи после каждой транзакции. При этом лог пишется на диск с задержкой в несколько секунд, что весьма безопасно с точки зрения сохранности данных.
На каждом сервере должен быть уникальный server ID в диапазоне от 1 до (2^32)-1. Если вы забудете указать server-id или установите его в 0 (значение по умолчанию), то master-сервер не будет принимать подключения со slave-серверов. Так же убедитесь, что в конфиге master-сервера отсутствует параметр skip-networking, иначе slave-сервера не смогут подключиться.
Настройки необходимо поместить в секцию [mysqld]
конфига my.cnf
:
[mysqld]
innodb_flush_log_at_trx_commit = 2
log-bin = /var/log/mysql/mysql-bin
server-id = 1
sync_binlog = 1
После внесения изменений перезагрузите MySQL-сервер:
# service mysql-server restart
slave-сервер[2]
На slave-сервере вы должны установить уникальный server ID, который не должен совпадать с master-сервером. Включать ведение бинарных логов на slave-серверах не обязательно. После установки потребуется перезагрузка MySQL-сервера:
[mysqld]
server-id = 2
После внесения изменений перезагрузите MySQL-сервер:
# service mysql-server restart
Создание пользователя для репликации[3]
Каждый slave-сервер должен подключаться к master-серверу используя логин и пароль, поэтому на master-сервере должен быть пользователь, которого сможет использовать slave-сервер. У такого пользователя должна быть разрешена привилегия REPLICATION SLAVE.
Для создания нового пользователя используйте CREATE USER. Для предоставления прав на репликацию используйте GRANT. Например:
mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';
Получение координат бинарного лога[4]
Для настройки репликации на slave-сервере необходимо узнать позицию в бинарном логе на master-сервере. Если на master-сервере есть данные, которые необходимо реплицировать, то необходимо остановить запись данных на master-сервере, подготовить дамп данных и получить позицию в бинарном логе перед тем, как продолжить запись в базу. Если этого не сделать, то можно получить повреждённые или неконсистентные данные на slave-сервере.
1. Подключитесь к master-серверу и переведите таблицы в режим только для чтения следующей командой:
mysql> FLUSH TABLES WITH READ LOCK;
Внимание! Если выйти с клиента, где вы ввели команду FLUSH TABLES, то сервер разблокирует таблицы и они снова будут доступны на запись.
2. Откройте новую сессию на master-сервере и для получения позиции в бинарном логе набираем команду:
mysql> SHOW MASTER STATUS;
Запоминаем значение Position, оно нам потребуется для настройки slave-сервера.
Создание копии данных
C помощью mysqldump[5]
Один из способов создания копии данных - использование утилиты mysqldump
.
shell> mysqldump --all-databases --master-data > dbdump.db
Если не использовать --master-data, то необходимо вручную лочить таблицы в режим только для чтения (FLUSH TABLES WITH READ LOCK).
C помощью "сырых" данных[6]
Если база данных очень большая, то эффективнее будет импортировать файлы данных на slave-сервер.
Этот способ не работает если master и slave имеют разные значения настроек ft_stopword_file, ft_min_word_len, ft_max_word_len или копируются таблицы с полнотекстовыми индексами.
Для получения копии данных:
- Заблокируйте таблицы в режим только для чтения и получите позицию в бинарном логе.
- В отдельном окне остановите сервер:
shell> mysqladmin shutdown
- Сделайте копию файлов стандартными утилитами копирования.
- Перезапустите master-сервер.
Настройка подключения к master-серверу на slave-сервере[7]
Для установки связи slave-сервера с master-сервером необходимо указать информацию для подключения. Для того, чтобы сделать это, запустите на slave-сервере следующую команду, указав свои значения для переменных:
mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
Команда CHANGE MASTER TO имеет большое количество настроек. Например, возможность использовать SSL-соединение.
Запуск репликации
На slave-сервере запустите:
mysql> START SLAVE;
После этого slave-сервер соединится с master-сервером и будет получать все обновления.
Во время репликации на slave-сервере в папке с данными будет находится 2 файла: master.info
и relay-log.info
. Slave-сервер использует эти 2 файла для отслеживания изменений. Не удаляйте и не редактируйте эти файлы! Безопаснее использовать команду CHANGE MASTER TO для изменения параметров репликации.
Проверка статуса репликации[8]
Для мониторинга состояния репликации запустите на slave-сервере команду:
mysql> SHOW SLAVE STATUS\G;
Вывод команды будет примерно таким:
*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: master1 Master_User: root Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000004 Read_Master_Log_Pos: 931 Relay_Log_File: slave1-relay-bin.000056 Relay_Log_Pos: 950 Relay_Master_Log_File: mysql-bin.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: 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: 931 Relay_Log_Space: 1365 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 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: 0
Slave_IO_State
: текущий статус. Полный список статусов можно прочитать в статье Replication Slave I/O Thread States. Если статусWaiting for master to send event
, то slave-сервер подключён к master-серверу и ждёт обновлений, т.е. всё работает.Slave_IO_Running
: в нормальном состоянииYes
, если только вы не запустили репликацию или не остановили её командой STOP SLAVE.Slave_SQL_Running
: должно бытьYes
, для того, чтобы SQL-потоки могли выполнять команды из журнала изменений.Last_IO_Error
,Last_SQL_Error
: последние зарегистрированные ошибки. Данные поля должны быть пустыми при безошибочной работе.Seconds_Behind_Master
: количество секунд на которое отстает SQL-поток от бинарного лога на master-сервере. Большие или увеличивающиеся значения сообщают о проблемах с обработкой данных вовремя.Master_Log_file
,Read_Master_Log_Pos
: координаты в бинарном логе на master-сервере. Позволяют контролировать отставание slave-сервера по чтению из этого лога.Relay_Master_Log_File
,Exec_Master_Log_Pos
: координаты в бинарном логе на master-сервере. Позволяют контролировать на сколько SQL-поток отстаёт при обработке событий из этого лога.Relay_Log_File
,Relay_Log_Pos
: координаты в логе репликации. Позволяют контролировать на сколько SQL-поток отстаёт при выполнении событий из этого лога.
На master-сервере используйте команду:
mysql> SHOW PROCESSLIST \G;
..., чтобы получить вывод:
*************************** 4. row *************************** Id: 10 User: root Host: slave1:58371 db: NULL Command: Binlog Dump Time: 777 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL
..., который позволит следить за статусом подключенных slave-серверов.
Приостановка репликации[9]
Приостановка и возобновление репликации осуществляется с помощью команд STOP SLAVE и START SLAVE
Переключение роли сервера (master-slave)[10]
Переключение Slave в Master
Slave-сервер должен работать с включенной опцией --log-bin с выключенной опцией --log-slave-updates. В этом случае slave-сервер готов стать master-сервером без перезагрузки mysqld.
mysql> STOP SLAVE IO_THREAD;
mysql> SHOW PROCESSLIST;
Как только появится статус Has read all relay log
, то можно перенастраивать slave-сервер.
mysql> STOP SLAVE;
mysql> RESET MASTER;
Переключение Slave на другой Master
Останавливаем репликацию, переключаемся на новый master-сервер и возобновляем репликацию:
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST='NEW MASTER SERVER';
mysql> START SLAVE;
Примечания
- ↑ Setting the Replication Master Configuration
- ↑ Setting the Replication Slave Configuration
- ↑ Creating a User for Replication
- ↑ Obtaining the Replication Master Binary Log Coordinates
- ↑ Creating a Data Snapshot Using mysqldump
- ↑ Creating a Data Snapshot Using Raw Data Files
- ↑ Setting the Master Configuration on the Slave
- ↑ Checking Replication Status
- ↑ Pausing Replication on the Slave
- ↑ Switching Masters During Failover