Главная / How-To / SysAdmin / Настройка репликации в MySQL Настройка репликации в MySQL
Здесь кратко описано как настроить
полную репликацию вашего
MySQL-сервера. Предполагается, что
реплицироваться будут все базы
данных и репликация ранее не
настраивалась. Для того чтобы
выполнить указанные здесь
действия, вам придется на короткое
время остановить головной сервер.
Это самый простой способ установки
подчиненного сервера, однако он не
единственный. Например, если уже
имеется образ головного сервера,
на головном сервере уже установлен
ID сервера и производятся записи в
журнал, подчиненный сервер можно
установить, не останавливая
головной сервер и даже не
устанавливая блокировки
обновлений (за дополнительной
информацией обращайтесь к разделу
See Раздел 4.10.7, «Часто задаваемые вопросы по репликации».
Чтобы стать настоящим гуру по
репликации в MySQL, советуем сначала
изучить, осмыслить и опробовать
все команды, упомянутые в разделе
See Раздел 4.10.6, «SQL-команды, относящиеся к репликации». Необходимо
также ознакомиться с опциями
запуска репликации из файла
my.cnf в разделе See
Раздел 4.10.5, «Опции репликации в файле my.cnf ».
Удостоверьтесь, что на головном
и подчиненном(ых) серверах
установлена свежая версия MySQL.
Используйте версию 3.23.29 или выше.
В предыдущих релизах применялся
другой формат двоичного журнала
и содержались ошибки, которые
были исправлены в более новых
релизах. Большая просьба:
пожалуйста, не посылайте
сообщения об ошибках, не
проверив, присутствует ли эта
ошибка в последнем релизе.
Установите на головном сервере
отдельного пользователя для
репликации с привилегией
FILE (в версиях MySQL ниже
4.0.2) или REPLICATION SLAVE в
более новых версиях MySQL. У этого
пользователя должно быть также
разрешение подсоединяться со
всех подчиненных серверов. Если
пользователь будет выполнять
только репликацию
(рекомендуется), то ему не нужно
предоставлять какие-либо
дополнительные привилегии.
Например, чтобы создать
пользователя с именем
repl , который может
иметь доступ к головному серверу
с любого хоста, можно
использовать такую команду:
mysql> GRANT FILE ON *.* TO repl@"%" 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;
и после этого - снимите образ
данных на вашем головном
сервере.
Легче всего сделать это (на Unix),
создав при помощи
tar архив всей
своей директории данных. Точное
местоположение директории
данных зависит от вашей
инсталляции.
tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir
Пользователи Windows для создания
архива каталога данных могут
использовать WinZIP или
другую подобную программу.
После того как снимок будет или
прямо во время этого процесса,
узнайте значения: имя текущего
двоичного журнала и позицию на
головном сервере:
mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+-------------------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+-------------------------------+
| mysql-bin.003 | 73 | test,bar | foo,manual,sasha_likes_to_run |
+---------------+----------+--------------+-------------------------------+
1 row in set (0.06 sec)
Столбец File дает имя
журнала, Position дает
информацию о смещении в журнале
(позиции). В этом примере имя
журнала - mysql-bin.003 и
смещение - 73 . Запишите
эти значения - они вам
понадобятся чуть позже, когда
будете настраивать подчиненный
сервер.
Когда вы получили образ и
сохранили указанную информацию,
вы можете снова разрешить запись
в таблицы на головном сервере:
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 так, как
было показано выше. После этого
остановите сервер без снятия
блокировок с таблиц. Это нужно
сделать именно так, чтобы быть
уверенным, что сервер
остановится именно с тем
снимком, который мы сделали:
shell> mysqladmin -uroot shutdown
Если головной сервер был ранее
запущен без опции log-bin ,
то значения имени файла журнала
и позиции будут пустыми в выводе
SHOW MASTER STATUS . В этом
случае, сохраните пустую строку
('') как имя файла журнала и
4 как позицию.
В 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 .
На данном этапе у вас есть снимок,
который вы можете использовать для
настройки и установки других
подчиненных серверов. Чтобы
сделать это, вам надо повторить
вышеописанную процедуру в части
настройки подчиненного сервера.
Вам не нужно создавать еще один
снимок головного сервера.
Добавлено: 2009/04/13 Обновлено: 2009/04/13 |