мы создаем простую конфигурацию MySQL master / slave с использованием асинхронной репликации с MySQL Enterprise 5.5.17 на обоих серверах и таблицах на основе innoDB. В случае сбоя главного сервера мы хотели бы предложить нашим пользователям возможность восстановления главного сервера, используя самое последнее содержимое базы данных подчиненного сервера. На главном сервере база данных и двоичные журналы хранятся на разных дисковых устройствах для большей надежности.
Как лучше всего это сделать? Я пытался наметить процедуру для этого, но не уверен, что это правильно:
Это нормально?
Чтобы упростить продвижение ведомого к мастеру, я предлагаю поддерживать более тесную синхронизацию ведомого с ведущим.
Вам следует использовать инструмент mk-slave-prefetch.
В этом прелесть этого инструмента: на ведомом устройстве он будет читать журналы реле, искать все запросы, содержащие предложение WHERE, преобразовывать их в SELECT и выполнять. Таким образом, кеши для InnoDB и MyISAM по существу такие же на ведомом устройстве, как и на ведущем устройстве. Отличия должны быть незначительными.
Вот еще кое-что, что вам понадобится: Настройте главный и подчиненный сервер с помощью круговой репликации. Таким образом, и Master, и Slave будут иметь двоичное ведение журнала.
Как это помогает? Когда мастер выходит из строя и вы переключаетесь на подчиненное устройство, файл master.info на главном устройстве будет содержать последнее место, где подчиненное устройство выполнило свой SQL. Вот как вы узнаете:
В этом примере у нас будет круговая репликация между M1 и M2.
Выполните эту команду на M2 (ваш текущий Мастер): SHOW SLAVE STATUS\G
Вы должны увидеть что-то вроде этого:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.64.100.253
Master_User: replicant
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000834
Read_Master_Log_Pos: 823413571
Relay_Log_File: relay-bin.002505
Relay_Log_Pos: 823391419
Relay_Master_Log_File: mysql-bin.000834
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: 823391282
Relay_Log_Space: 823413708
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: 1
1 row in set (0.00 sec)
Обратите внимание на два поля:
Эти два поля представляют последний файл журнала и позицию в журнале от мастера, который был успешно выполнен на подчиненном.
Предположим, что произошел сбой M1, вы переключаетесь на M2 и вызываете M1. Ваша цель - восстановить круговую репликацию. При сбое существует вероятность потери места репликацией. Вот что надо делать:
Step01) Выполнить SHOW SLAVE STATUS\G на М1
Step02) Получить Relay_Master_Log_File и Exec_Master_Log_Pos из Step01. Для этого примера пусть Relay_Master_Log_File быть mysql-bin.000834 и Exec_Master_Log_Pos быть 823391282.
Шаг03) Запустите эти команды
STOP SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000834',master_log_pos=823391282;
START SLAVE;
SELECT SLEEP(5);
SHOW SLAVE STATUS\G
Вот что нужно искать:
Вы можете исправить это с помощью
STOP SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000835',master_log_pos=<new pos>;
START SLAVE;
SELECT SLEEP(5);
SHOW SLAVE STATUS\G
Что такое newpos?
Если вы реализуете круговую репликацию и правильно запишете эти вещи, используя эти принципы, вы добьетесь восстановления Master и Slave.