Записки старого админа

После того, как восстановили root пароль, поставили мне задачу сделать репликацию содержимого баз, на другой сервер.

Привожу пример настройки репликации на другой сервер, с учетом того что ранее на этих серверах подобное не делалось.

Итак, для настройки полной репликации вашего MySQL-сервера, необходимо на короткое время остановить главный SQL сервер.

Удостоверьтесь, что на главном и подчиненном(ых) серверах установлена свежая версия MySQL. Используйте версию не ниже 3.23.29. В предыдущих релизах применялся другой формат двоичного журнала и содержались ошибки, которые были исправлены в более новых релизах.

Установите на главном сервере отдельного пользователя для репликации с привилегией FILE (в версиях MySQL ниже 4.0.2) или REPLICATION SLAVE в более новых версиях MySQL. У этого пользователя должно быть также разрешение подсоединяться со всех подчиненных серверов. Если пользователь будет выполнять только репликацию (рекомендую), то ему не нужно предоставлять какие-либо дополнительные привилегии. Например, чтобы создать пользователя с именем replic, который может иметь доступ к головному серверу с любого хоста, можно использовать такую команду:

mysql> GRANT FILE ON *.* TO replic@"%" IDENTIFIED BY '<password>'; # главный < 4.0.2
 
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@"%" IDENTIFIED BY '<password>'; # главный >= 4.0.2

Если вы планируете использовать LOAD TABLE FROM MASTER или LOAD DATA FROM MASTER (доступные с версии 4.0.0), вам также надо выделить привилегии RELOAD и SUPER на главном сервере для вышеуказанного пользователя.

Если вы используете MyISAM-таблицы, сохраните содержимое и заблокируйте модифицирующие запросы командой FLUSH TABLES WITH READ LOCK.

mysql> FLUSH TABLES WITH READ LOCK;

только после этого — снимите образ данных на вашем главном сервере.

Легче всего это сделать создав при помощи tar архив всей своей директории данных. Точное местоположение директории данных зависит от вашей инсталляции. К примеру:

# tar -cvf /backup_disk/mysql-snapshot.tar /db_disk/mysql

Пользователи Windows для создания архива каталога данных могут использовать WinZIP или другую удобную для них программу.

После того как снимок будет или прямо во время этого процесса, узнайте значения: имя текущего двоичного журнала и позицию на головном сервере:

mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+-------------------------------+
| File          | Position | Binlog_do_db | Binlog_ignore_db              |
+---------------+----------+--------------+-------------------------------+
| mysql-bin.002 | 72       | test,bar     | foo,manual,sasha_likes_to_run |
+---------------+----------+--------------+-------------------------------+
1 row in set (0.06 sec)

Столбец File дает имя журнала, Position дает информацию о смещении в журнале (позиции). В этом примере имя журнала — mysql-bin.002 и смещение — 72. Запишите эти значения — они вам понадобятся чуть позже, когда будете настраивать подчиненный сервер.

После получения образа и сохранения указанной информации, вы можете снова разрешить запись в таблицы на головном сервере:

mysql> UNLOCK TABLES;

Если вы используете таблицы InnoDB, то в идеале было бы хорошо, чтобы вы использовали ПО InnoDB Hot Backup. Она берет целостный снимок без установки каких-либо блокировок на головном сервере, и сохраняет имя журнала и позицию непосредственно в снимке, что позволит в дальнейшем использовать эту информацию на подчиненном сервере. Более подробная информация об этой программе доступна на http://www.innodb.com/hotbackup.html.

Без использования этой утилиты, наиболее быстрый способ получить снимок таблиц InnoDB — это остановить головной сервер и скопировать файлы данных, журналы, и файлы определений формата таблицы (.frm). Для сохранения текущего имени файла журнала и смещения, вам следует выполнить следующее перед остановкой сервера:

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

Затем сохранить имя журнала и смещение из вывода команды SHOW MASTER STATUS. После этого остановите сервер без снятия блокировок с таблиц. Это нужно сделать именно так, чтобы быть уверенным, что сервер остановится именно с тем снимком, который мы сделали:

# mysqladmin -uroot shutdown

Если головной сервер был ранее запущен без опции log-bin, то значения имени файла журнала и позиции будут пустыми в выводе SHOW MASTER STATUS. В этом случае, сохраните пустую строку (») как имя файла журнала и 4 как позицию.

В /etc/my.cnf на головном сервере добавьте к разделу [mysqld] записи log-bin и server-id=уникальный номер и перезапустите сервер. Очень важно, чтобы номер подчиненного сервера отличался от номера главного сервера. Можно считать, что server-id играет роль IP-адреса — он уникально идентифицирует сервер среди участников репликации.

[mysqld]
log-bin
server-id=1

Добавьте в my.cnf на подчиненном сервере(ах) следующий фрагмент:

server-id=<некоторое уникальное число между 2 и 2^32-1>

заменяя значения в <> значениями, соответствующими вашей системе. Значения server-id должны быть различными на каждом сервере, участвующем в репликации. Если значение server-id не определено, оно будет установлено в 1, если также не определено значение master-host, оно будет установлено в 2. Обратите внимание, что если значение server-id опущено, то головной сервер будет отказывать в соединении всем подчиненным серверам, а подчиненный сервер — отказывать в соединении головному серверу. Таким образом, опускать установку значения server-id можно лишь в случае резервного копирования с использованием двоичного журнала.

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

mysql> RESET SLAVE;

Скопируйте данные снимка в директорию данных на подчиненном сервере (ах). Удостоверьтесь в правильности привилегий для файлов и каталогов. Пользователь, от имени которого запускается MySQL, должен иметь возможность читать и записывать данные в них так же, как и на головном сервере.

Перезапустите подчиненный(ые) сервер(ы).

Когда подчиненные сервера запустятся, выполните:

mysql> CHANGE MASTER TO MASTER_HOST='<имя хоста главного сервера>',
 
 MASTER_USER='<имя пользователя репликации>',
 MASTER_PASSWORD='<пароль репликации>',
 MASTER_LOG_FILE='<записанное вами имя журнала>',
 MASTER_LOG_POS=<записанная вами позиция>;

заменяя значения в <> значениями, соответствующими вашей системе.

Запустите поток подчиненного сервера:

mysql> SLAVE START;

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

Если не установлен идентификатор server-id для подчиненного сервера, в журнальный файл регистрации ошибок будет внесена следующая ошибка:

Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave.

(Предупреждение: если задан master_host, следует установить server_id в ненулевое значение. Сервер не будет работать как подчиненный сервер.)

Если не установлен идентификатор главного сервера, подчиненные серверы не смогут подключиться к головному серверу.

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

После того как подчиненный сервер начнет выполнять репликацию, в той же директории, где находится журнал регистрации ошибок, появится файл master.info. Файл master.info используется подчиненным сервером для отслеживания того, какие записи двоичных журналов главного сервера обработаны. Не удаляйте и не редактируйте этот файл, если не уверены в том, что это необходимо. Даже если такая уверенность есть, все равно лучше использовать команду CHANGE MASTER TO.

На данном этапе у вас есть снимок, который вы можете использовать для настройки и установки других подчиненных серверов. Чтобы сделать это, вам надо повторить вышеописанную процедуру в части настройки подчиненного сервера. Вам не нужно создавать еще один снимок главного сервера.

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