Mysql replication: различия между версиями
(Новая: =Репликация Mysql= Заметка для себя, что бы не забыть... <BR> ==Как это работает== <BR> Slave-сервер с определённой ...) |
Sirmax (обсуждение | вклад) |
||
(не показано 6 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
+ | [[Категория:Linux]] |
||
+ | [[Категория:MySQL]] |
||
=Репликация Mysql= |
=Репликация Mysql= |
||
Заметка для себя, что бы не забыть... |
Заметка для себя, что бы не забыть... |
||
Строка 19: | Строка 21: | ||
server-id является обязательным параметром, это идентификатор базы, пускай будет 1, каждый сервер в схеме репликаций должен иметь уникальный номер. На slave-сервере мы укажем server-id=2. slave-compressed я включил, потому что мой slave-сервер находиться не “рядом” и передача идёт по сети, в этом случае можно повысить скорость и разрешить сжимать поток. bin-do-db — необязательный параметр, позволяет указать изменения какой именно базы будет писаться в бинарный журнальный лог. |
server-id является обязательным параметром, это идентификатор базы, пускай будет 1, каждый сервер в схеме репликаций должен иметь уникальный номер. На slave-сервере мы укажем server-id=2. slave-compressed я включил, потому что мой slave-сервер находиться не “рядом” и передача идёт по сети, в этом случае можно повысить скорость и разрешить сжимать поток. bin-do-db — необязательный параметр, позволяет указать изменения какой именно базы будет писаться в бинарный журнальный лог. |
||
<BR> |
<BR> |
||
− | Создадим отдельную учётную запись на головном сервере c привилегиями REPLICATION SLAVE, SELECT, RELOAD, SUPER. При создании учётной записи не забудьте правильно указать “Хост”. Например, если все наши slave-сервера находятся в зоне webnext.ru то мы можем ограничить доступ как ‘%. |
+ | Создадим отдельную учётную запись на головном сервере c привилегиями REPLICATION SLAVE, SELECT, RELOAD, SUPER. При создании учётной записи не забудьте правильно указать “Хост”. Например, если все наши slave-сервера находятся в зоне webnext.ru то мы можем ограничить доступ как ‘%.shost,net.ua’. |
+ | <BR> |
||
+ | На мастере: |
||
+ | <PRE> |
||
+ | GRANT replication slave ON *.* TO "replication"@"slave-mysq.shost,net.ua" IDENTIFIED BY "password"; |
||
+ | </PRE> |
||
<BR> |
<BR> |
||
Перед запуском подчинённого (slave) сервера, на нём необходимо разместить полную копию данных главного (master) сервера. Задача состоит в том, что на головном сервере необходимо сделать дамп базы в режиме блокировки на запись. И пока делается дамп необходимо узнать номер журнала и смещение от начала файла. Для этого выполните запрос: |
Перед запуском подчинённого (slave) сервера, на нём необходимо разместить полную копию данных главного (master) сервера. Задача состоит в том, что на головном сервере необходимо сделать дамп базы в режиме блокировки на запись. И пока делается дамп необходимо узнать номер журнала и смещение от начала файла. Для этого выполните запрос: |
||
Строка 43: | Строка 50: | ||
start slave; |
start slave; |
||
</PRE> |
</PRE> |
||
+ | |||
==Послесловие== |
==Послесловие== |
||
+ | Проверить статус: |
||
− | После рестарта все поднимается нормально. О мониторинге и тонкостях работы отпишу позже. |
||
+ | <PRE> |
||
+ | mysql@replica> SHOW SLAVE STATUS\G |
||
+ | Slave_IO_State: Waiting for master to send event |
||
+ | Master_Host: 192.168.1.101 |
||
+ | Master_User: replication |
||
+ | Master_Port: 3306 |
||
+ | Connect_Retry: 60 |
||
+ | Master_Log_File: mysql-bin.000003 |
||
+ | Read_Master_Log_Pos: 98 |
||
+ | Relay_Log_File: mysql-relay-bin.001152 |
||
+ | Relay_Log_Pos: 235 |
||
+ | Relay_Master_Log_File: mysql-bin.000003 |
||
+ | Slave_IO_Running: Yes |
||
+ | Slave_SQL_Running: Yes |
||
+ | Replicate_Do_DB: testdb,testdb |
||
+ | 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: 98 |
||
+ | Relay_Log_Space: 235 |
||
+ | 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: 5 |
||
+ | </PRE> |
||
+ | |||
+ | Наиболее интересные сейчас значения: |
||
+ | <PRE> |
||
+ | Slave_IO_Running: Yes |
||
+ | Slave_SQL_Running: Yes |
||
+ | Seconds_Behind_Master: 5 |
||
+ | </PRE> |
||
+ | При успешном начале репликации их значения должны быть примерно такими, как в листинге (см. описание команды "show slave status " в документации). Значение Seconds_Behind_Master может быть любым целым числом. |
||
+ | Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Время отставания реплики от мастера (Seconds_Behind_Master), в идеале, должно быть равно нулю. Если оно не сокращается или растет, возможно, что нагрузка на реплику слишком высока — она просто не успевает повторять изменения, происходящие на мастере. |
||
+ | Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. Смотрите лог MySQL для выяснения причины, устраняйте её и заново запускайте репликацию. |
||
+ | <BR> |
||
+ | Для мониоринга я использую стандартый плагин к nagios: |
||
+ | <PRE> |
||
+ | # MySQL Slave status |
||
+ | command[check_mysql_slave]=/usr/lib64/nagios/plugins#./check_mysql -H 172.16.255.13 -u USERNAME -pPASSWORD -S -w 60 -c 120 |
||
+ | </PRE> |
Текущая версия на 15:52, 28 сентября 2012
Репликация Mysql
Заметка для себя, что бы не забыть...
Как это работает
Slave-сервер с определённой периодичностью будет опрашивать master-сервер на предмет изменений в базе. Таким образом все изменения в master-сервере будут повторяться на slave-сервере. Таким образом создаётся избыточность данных на двух серверах и тем самым достигается высокая доступность и надёжность данных. Важным преимуществом между “холодным копированием” заключается в том, что мы переносим по сети только изменения, а не все данные каждый раз. Тем более не стоит забывать что во время создания backup`а мы нагружаем наш master-сервер. Здесь же всё иначе, master-сервер все изменения в базе пишет в “бинарный журнальный лог”, присваивая каждой операции номер. Когда slave-сервер обращается к нашему главному серверу, то он сообщает номер последней операции, которую он уже произвёл у себя и получает все новые изменения отсчитывая от этого номера.
Настраиваем
Первым делом надо включить “Бинарный журнал” на master-сервере. Это файл, в котором регистрируются все изменения данных. Однако, опреаторы update и delete, которые не затронули ни одной строки — регистрироваться в журнале не будут. Включение журнала немного понижают общую производительноть базы, но не сильно, примерно на 1%. Зато, в случае падения базы, этот журнал используется для “автоматического восстановления после сбоя”. Для включения этого журнала отредактируем конфигурационный файл (у меня в Gentoo Linux это /etc/mysql/my.cnf)
log-bin = my-bin
my-bin в данном случае — это имя файла бинарного лога. В ходе работы базы в папке с данными (у меня это /var/lib/mysql) будут создаваться файлы my-bin.000001, my-bin.000002 и так далее, при каждом старте базы, будет создан новый файл. Вместе с этим будет создан файл my-bin.index в котором будут перечислен список всех бинарных логов. Продолжим настройку нашего главного сервера, добавим следующие строки:
server-id = 1 slave-compressed = 1 binlog-do-db = mydb
server-id является обязательным параметром, это идентификатор базы, пускай будет 1, каждый сервер в схеме репликаций должен иметь уникальный номер. На slave-сервере мы укажем server-id=2. slave-compressed я включил, потому что мой slave-сервер находиться не “рядом” и передача идёт по сети, в этом случае можно повысить скорость и разрешить сжимать поток. bin-do-db — необязательный параметр, позволяет указать изменения какой именно базы будет писаться в бинарный журнальный лог.
Создадим отдельную учётную запись на головном сервере c привилегиями REPLICATION SLAVE, SELECT, RELOAD, SUPER. При создании учётной записи не забудьте правильно указать “Хост”. Например, если все наши slave-сервера находятся в зоне webnext.ru то мы можем ограничить доступ как ‘%.shost,net.ua’.
На мастере:
GRANT replication slave ON *.* TO "replication"@"slave-mysq.shost,net.ua" IDENTIFIED BY "password";
Перед запуском подчинённого (slave) сервера, на нём необходимо разместить полную копию данных главного (master) сервера. Задача состоит в том, что на головном сервере необходимо сделать дамп базы в режиме блокировки на запись. И пока делается дамп необходимо узнать номер журнала и смещение от начала файла. Для этого выполните запрос:
SHOW master STATUS;
В столбце File указано имя текущего журнального файла, а в столбце Position — смещение относительно начала файла. Эти значения представляют собой координаты, с которых подчинённому серверу следует получать новые изменения.
Далее на slave-сервере следует выполнить следующую sql-команду.
CHANGE master TO master_host = 'master_host', master_user = 'user'. master_password = 'password', master_log_file = 'log_file', master_log_pos = log_pos;
Тут master_host — хост или ip главного (master) сервера с которого мы делаем репликацию. user и password — имя пользователя, которого мы завели специально для репликаций и его пароль. log_file и log_pos — имя текущего журнального файла на
главном сервере и смещение от начала файла, эти поля мы получили выше с главного (master) сервера. И последнее что осталось, это запустить на подчинёном сервере процесс репликации, это делается sql-командой.
start slave;
Послесловие
Проверить статус:
mysql@replica> SHOW SLAVE STATUS\G Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.101 Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 98 Relay_Log_File: mysql-relay-bin.001152 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: testdb,testdb 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: 98 Relay_Log_Space: 235 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: 5
Наиболее интересные сейчас значения:
Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 5
При успешном начале репликации их значения должны быть примерно такими, как в листинге (см. описание команды "show slave status " в документации). Значение Seconds_Behind_Master может быть любым целым числом.
Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Время отставания реплики от мастера (Seconds_Behind_Master), в идеале, должно быть равно нулю. Если оно не сокращается или растет, возможно, что нагрузка на реплику слишком высока — она просто не успевает повторять изменения, происходящие на мастере.
Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. Смотрите лог MySQL для выяснения причины, устраняйте её и заново запускайте репликацию.
Для мониоринга я использую стандартый плагин к nagios:
# MySQL Slave status command[check_mysql_slave]=/usr/lib64/nagios/plugins#./check_mysql -H 172.16.255.13 -u USERNAME -pPASSWORD -S -w 60 -c 120