Репликация MySQL

Материал из Bas Wiki
Перейти к навигации Перейти к поиску

Данная статья является вольным и сокращённым переводом официальной документации!

Настройка

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 или копируются таблицы с полнотекстовыми индексами.

Для получения копии данных:

  1. Заблокируйте таблицы в режим только для чтения и получите позицию в бинарном логе.
  2. В отдельном окне остановите сервер:
    shell> mysqladmin shutdown
  3. Сделайте копию файлов стандартными утилитами копирования.
  4. Перезапустите 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;

Примечания