mysql 5.6主从复制第四部分[一些被忽视的操作细节]
1. stop slave
从服务器上负责同步的有二类线程:
1) io thread
2) sql thread
io thread负责获取master上的binary log, 然后多个sql threads负责执行。
io thread 决定了retrieved_gtid_set
sql thread 决定了executed_gtid_set
由于io thread先于sql thread，retrieved_gtid_set可能会略多于executed_gtid_set。
比如:
mysql [localhost] {msandbox} (test) > show slave status \g
.......
.......
retrieved_gtid_set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-9
executed_gtid_set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-7
auto_position: 1
所以，在stop slave的时候，，正确的操作是：
1) stop slave io_thread;
2) show slave status 确定executed_gtid_set赶上了retrieved_gtid_set
3) stop slave sql_thread.
2.flush tables with read lock 与 show slave status
在一台完全正常的从服务器上开一个session 1:
mysql> flush tables with read lock;
如果主服务器有更新,
在此从服务器上再开一个session2:
mysql> show slave status，将会卡住， 直到在session1中执行unlock tables。
如果show slave status也是在session 1中执行的， 那么就没办法恢复了。。。。
mysql [localhost] {msandbox} (test) > flush tables with read lock;
query ok, 0 rows affected (0.01 sec)
//这时主服务器发生了更新操作。
mysql [localhost] {msandbox} (test) > show slave status;
卡在这里…
当然ctrl+c可以取消，
ctrl-c — sending “kill query 1″ to server …
ctrl-c — query aborted.
ctrl-c — sending “kill 1″ to server …
ctrl-c — query aborted.
error 2013 (hy000): lost connection to mysql server during query
mysql [localhost] {msandbox} (test) >
即使这时再unlock tables也没有用。。早已经断开连接了。。
mysql [localhost] {msandbox} (test) > unlock tables;
error 2006 (hy000): mysql server has gone away
no connection. trying to reconnect…
connection id: 14
current database: test
query ok, 0 rows affected (0.01 sec)
而且现在mysqld都无法stop了…
[modify@h209 msb_5_6_10_b]$ ./stop
warning; aborted waiting on pid file: ‘/home/modify/sandboxes/msb_5_6_10_b/data/mysql_sandbox5612.pid’ after 190 seconds
attempting normal termination — kill -15 10858
所以在 flush tables with read lock 之前，要先stop slave…
?id=68460
相关阅读：
mysql 5.6主从复制第一部分[简介及配置]
mysql 5.6主从复制第二部分[恢复某一台从服务器]
mysql 5.6主从复制第三部分[把从服务器提升为主服务器]
mysql 5.6主从复制第四部分[一些被忽视的操作细节]
mysql 主从复制事件校验 mysql replication event checksum
使用pt-table-checksum检查主从复制是否正常