4.10.3 Как настроить репликацию

Здесь кратко описано как настроить полную репликацию вашего MySQL-сервера. Предполагается, что реплицироваться будут все базы данных и репликация ранее не настраивалась. Для того чтобы выполнить указанные здесь действия, вам придется на короткое время остановить головной сервер.

Это самый простой способ установки подчиненного сервера, однако он не единственный. Например, если уже имеется образ головного сервера, на головном сервере уже установлен ID сервера и производятся записи в журнал, подчиненный сервер можно установить, не останавливая головной сервер и даже не устанавливая блокировки обновлений (за дополнительной информацией обращайтесь к разделу See section 4.10.7 Часто задаваемые вопросы по репликации.

Чтобы стать настоящим гуру по репликации в MySQL, советуем сначала изучить, осмыслить и опробовать все команды, упомянутые в разделе See section 4.10.6 SQL-команды, относящиеся к репликации. Необходимо также ознакомиться с опциями запуска репликации из файла `my.cnf' в разделе See section 4.10.5 Опции репликации в файле `my.cnf'.

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

   mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY '<password>';
   

3. Завершите работу MySQL на головном сервере.

   mysqladmin -u root -p<password> shutdown
   

4. Создайте образ всех данных на головном сервере. Легче всего сделать это (на Unix), создав при помощи tar архив всей своей директории данных. Точное местоположение директории данных зависит от вашей инсталляции.

   tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir
   

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

   [mysqld]
   log-bin
   server-id=1
   

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

   master-host=<имя хоста головного сервера>
   master-user=<имя пользователя репликации >
   master-password=<пароль пользователя репликации >
   master-port=<порт TCP/IP для головного сервера>
   server-id=<некоторое уникальное число между 2 и 2^32-1>
   

   заменяя значения в <> значениями, соответствующими вашей системе. Значения server-id должны быть различными на каждом сервере, участвующем в репликации. Если значение server-id не определено, оно будет установлено в 1, если также не определено значение master-host, оно будет установлено в 2. Обратите внимание, что если значение server-id опущено, то головной сервер будет отказывать в соединении всем подчиненным серверам, а подчиненный сервер - отказывать в соединении головному серверу. Таким образом, опускать установку значения server-id можно лишь в случае резервного копирования с использованием двоичного журнала.
8. Скопируйте данные снимка в директорию данных на подчиненном сервере (ах). Удостоверьтесь в правильности привилегий для файлов и каталогов. Пользователь, от имени которого запускается MySQL, должен иметь возможность читать и записывать данные в них так же, как и на головном сервере.
9. Перезапустите подчиненный(ые) сервер(ы).

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

Если не установлен идентификатор 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.

User Comments

LOAD DATA FROM MASTER (3.23.41 master and 4.01a slave) doesn't seem to load the mysql.* tables. On my installation it loads the data for additional databases but not the mysql stuff. As a result, the slave fails to start properly to catch up with subsequent updates from the master's binary log. The slave fails with its log file showing that it was unable to run SQL commands that modify data in the mysql.* tables. In my case, the slave's log shows that it stopped with a failure to run a revoke command that the master ran (since the user was never replicated in the first place to the client.) The old tar-ball trick seemed to work OK though.

V.4.0.1a: To use 'LOAD DATA FROM MASTER;' the
replication-
user has to have also the 'SELECT', 'RELOAD'
and 'PROCESS'
privileges and not only the 'FILE' privilege as
stated in the manual. Otherwise you'll get
an 'access denied' error from the master. From
the moment, where the replication is successfully
running, the 'SELECT', 'RELOAD' and 'PROCESS'
privileges
are no longer needed.

For those who want their server to be both master
and slave at the same time, please note that you
should have only one 'server-id' in your my.cnf file; if
you copy the two sections of statements (Paras. 5
and 7) above into
your my.cnf , you will end up having a connection
problem like:
020821 17:34:47 Slave: connected to
master '[email protected]:3306', replication
started in log 'FIRST' at position 32
020821 17:34:47 Slave: received 0 length
packet from server, apparent master
shutdown:
020821 17:34:47 Slave: Failed reading log
event, reconnecting to retry, log 'FIRST' position
32
020821 17:34:47 Slave: reconnected to
master '[email protected]:3306',replication
resumed in log 'FIRST' at position 32
020821 17:34:47 Slave: received 0 length
packet from server, apparent master
shutdown:

You do not need the line
master-port=<TCP/IP port for master>

of the slave, if you not changed the port. Normal :
3306

To add a user for the master server you need this
line
mysql> GRANT FILE ON *.* TO repl@"%"
IDENTIFIED BY '<password>';

You have to change "%" to the IP Adress from the
SLAVE.
Example: mysql> GRANT FILE ON *.* TO
[email protected] IDENTIFIED BY 'yourpass';

A few things I came across while setting up
replication:

- Passwords can only be 16 characters long. This will
cause 'Access Denied' errors while trying to connect
to the master if set too long.

- When running replication numerous files are
created that can cause problems getting back on
track if something goes wrong. If there are
problems after you edit your my.cnf and restart
mysqld here's some cleaning up that needs to be
done while the server is shutdown (your file names
might differ):

1) On the slave (in the mysql data dir): remove
master.info file, remove all binary files created and
their indexes, remove the .err and .pid files, remove
the log.info file.

2) On the master (in the mysql data dir): remove all
binary files created and their indexes, remove
the .err and .pid files.

3) If for some reason you need to redo replication I
have found it is best to tar up the mnaster and put a
fresh copy of the database on the slave and start
again rather than trying to resolve every issue the
slave spits out. Although, it should be noted that this
is not always possible - it's a judgement call.

I beat my head against the wall trying to figure
this one out:

These instructions assume that you do not
previously have binary loggin on the master
server. If you do have binary logging on (which
you should have if you follow the install
instructions), and you follow these instructions,
you will have problems.

For instance, if logging is on the master and you
create a database and then follow the replication
instructions, replication will not work. This is
because the replication process will try to
replicate the create database command on the slave
and fail because the database is already exists
(because you brought it over with the tar file
from the master).

To work around this you can either drop the
database on the slave or do a 'reset master;' on
the master (this will delete inactive binary logs
on the master so be careful).

Its worth mentionning that if your server-id
values are too large, the communication dies every
time it starts and you'll have to change the IDs,
then reset things to get started again.

The line below:
> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY '<password>';
doesn't work correctly on v4.0. The correct privileges for this version are:
> GRANT REPLICATION SLAVE ON *.* TO repl@"%" IDENTIFIED BY '<password>';

You cannot add REPLICATION SLAVE on a table level. You need to grant privileges to the entire database (kinda disturbing, since it would be a nice fallback for a bogus config file). It seems to apply to 'FILE' as well.

In fact - there's no REPLICATION SLAVE in the db table, so it probably should be ignored by the GRANT command as well, since it now gives you OK, while in fact there's nothing happening.

Our Main mysql server (3.23.54) has many,many databases. Curently I run a replication setup for redundency purpose, and it's working well.

I want to setup a server with only one of the db's replicated. I can't grant a user file priv only one one db. Is there a way to setup so that the salve won't be able to read all of the dbs' ?

When setting up mysql replication, you may find it necessary to test your username and password settings; in my scenario, I do replication through an SSH tunnel to our live server. If you're doing this, there're a couple of things to note:

1. the GRANT FILE command should be set so that the replication user is allowed access from the server

2. when testing the username/password using the mysql login prompt, this will fail if you've followed the instructions above AND have specified a database to connect to. If you leave the dB name out, the login will work.

Add your own comment.