MYSQL: ОТСТАЮЩАЯ РЕПЛИКА
Все мы знаем, что бывает «холодный» и «горячий» бэкап базы данных.
«Горячий» бэкап позволяет нам переключиться практически «на лету», используя реплику вместо мастера. Да да — речь о репликации.
«Холодный» же бэкап — это копии базы, как правило сжатые в архиве,находящиеся примерно в нескольких местах, и пользуются ими очень редко.
Но представьте ситуацию: у вас есть гигантская база данных, гигобайтов таки 400, она реплицируется на соседний сервер (не важно — репликация мастер-мастер, или же мастер-слэйв), так же раз в неделю вы снимаете «срезы», бэкапы базы данных, и храните их где-нибудь за границей. И тут один криворукий программист дропнул очень большую и очень важную табличку. Сервисы/услуги встали, клиенты звонят, жалуются, начальство рвет и мечет. Ваши действия? Данные тут же отобразятся на реплике — горячего резерва у вас нет. Восстанавливать из холодного бэкапа? Долго, особенно если данных много и они далеко.
Тут к нам на помощь приходит отстающая реплика!
Этот функционал появился в mysql с версии 5.6.
Оригинальная статья тут.
По умолчанию реплика стремится не отставать, то есть задержка равна 0. Ее можно изменить на слэйве командой в консоли (слэйв нужно предварительно остановить):
(root@localhost) [(none)]>stop slave; Query OK, 0 rows affected (0,02 sec)
(root@localhost) [(none)]>CHANGE MASTER TO MASTER_DELAY = 3600; Query OK, 0 rows affected (0,04 sec)
(root@localhost) [(none)]>start slave;
Query OK, 0 rows affected (0,00 sec)
Сразу же смотрим статус слева:
(root@localhost) [(none)]>show slave statusG; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.4 Master_User: db_repl Master_Port: 3306 Connect_Retry: 5000 Master_Log_File: mysql-bin.000059 Read_Master_Log_Pos: 3124328 Relay_Log_File: centos2-relay-bin.000002 Relay_Log_Pos: 283 Relay_Master_Log_File: mysql-bin.000059 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: database.% Replicate_Wild_Ignore_Table: mysql.% Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 283170 Relay_Log_Space: 2841616 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: 157 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: f7b77688-f064-11e3-a26e-5254004d338f Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 3600 SQL_Remaining_Delay: 3443 Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0,00 sec) ERROR: No query specified
Тут два интересных параметра: Seconds_Behind_Master, который начинает потихоньку отставать, и SQL_Delay, говорящий нам, какого максимального отставания оно достигнет (сами же настроили).
Собственно, это все. У нас на продах отставание настроено на сутки. В случае проблемы, которая описана выше, в ручном режиме сервисы переключатся на отстающую реплику, и пока админы чинят основную базу, все работает на ней.