如果你在一个slave上本地执行了一个事务 (在MySQL文档中被称为错误事务), 如果你被这个事务推送到新的master上时会发生什么呢?
使用老协议，基本上没啥事（准确点说，新的master和其slave之间的数据将会出现不一致，但那在稍后就可能会被修复）.
使用新协议，错误的事务将会被识别成为在每个地方都丢失了，并且将会自动在容错备份上被执行，这样就将会导致打断复制的隐患.
比方说，你拥有一个master（M)和两个slave (S1 和 S2). 这里有两种将slave重连到新的master将会发生（带有不同复制错误的）失败的场景:
# 场景 1
| # S1 mysql> CREATE DATABASE mydb; # M mysql> CREATE DATABASE IF NOT EXISTS mydb; # Thanks to 'IF NOT EXITS', replication doesn't break on S1. Now move S2 to S1: # S2 mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE; # This creates a conflict with existing data! mysql> SHOW SLAVE STATUSG [...] Last_SQL_Errno: 1007 Last_SQL_Error: Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'CREATE DATABASE mydb' [...] |
# 场景 2
| # S1 mysql> CREATE DATABASE mydb; # Now, we'll remove this transaction from the binary logs # S1 mysql> FLUSH LOGS; mysql> PURGE BINARY LOGS TO 'mysql-bin.000008'; # M mysql> CREATE DATABASE IF NOT EXISTS mydb; # S2 mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE; # The missing transaction is no longer available in the master's binary logs! mysql> SHOW SLAVE STATUSG [...] Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.' [...] |
你可以这样理解，错误的事务应该借助基于GTID的服务得以避免. 如果你需要运行一个本地事务，最好的选择是针对那条特定的语句禁用二进制日志:
| mysql> SET SQL_LOG_BIN = 0; mysql> # Run local transaction |
结论
GTIDs在让我们方便重新和其他服务器连接副本方面是个不小的进步。然而同样的在运维方面我们也因此面临新的困难和挑战。假如你打算开始使用GTIDs,那么你就得确实理解新的复制协议，否则你就会以一种想不到的方式结束复制过程。
