MySQL手册版本 5.0.20-MySQL同步(三) （3）

   来源：MySQL手册版本 5.0.20    作者：译者：叶金荣

提交一个 STOP SLAVE 语句。

使用 SHOW STATUS 语句检查变量 Slave_open_temp_tables 的值。

如果它的值是0，运行 mysqladmin shutdown 命令关闭slave。

如果它的值不是0，用 START SLAVE 语句重启slave线程。

如果还有这样的好运气就再次执行同样的步骤吧。^_^

我们会尽快解决这个问题。

如果在一个循环master/slave同步关系中指定 --log-slave-updates 选项，那么就可以安全地连接到各个服务器上。注意，很多语句可能在这种设置环境下不能正常工作，除非程序中已经特别注意避免这种更新时潜在的问题了，因为可能在不同服务器上不同的顺序上发生更新问题。这意味着可以设定像下面的循环：

A -> B -> C -> A

服务器ID都已经编码到二进制日志中了，因此服务器A知道那些自己创建的日志，从而不会去执行它们(除非在服务器A上启动时增加 --replicate-same-server-id 选项，这个选项只在极少数情况下设置有意义)。因此，这就不会存在无限循环了。不过这个循环只有在更新表时没有发生冲突才不会发生问题。换言之，如果在A和C中同时插入一条记录，那么可能在A中不可能插入数据，因为它的键可能跟C的键冲突了。同样地，也不能在两个服务器上更新同一条记录，除非2次更新操作间有足够的时间间隔。

如果在slave上执行一个SQL语句后产生错误，那么slave的SQL线程就终止，然后它在错误日志中写入一条信息。可以连接到slave上，解决问题(例如，不存在表)后，运行 START SLAVE 语句重启它。

可以放心地关闭master(干净地)之后再重启它。如果slave到master的连接断开了，它会立刻重连。如果失败了，slave会定期重试(默认是每60秒重试一次，可通过 --master-connect-retry 选项来修改)。slave也会处理网络断开的情况。不过，slave会在 slave_net_timeout 秒之后如果还没收到来自master的数据才会当作网络断开的情况来处理。如果断开时间不长，可以减少 slave_net_timeout 的值。详情请看"5.2.3 Server System Variables"。

也可以放心地关闭slave(干净地)，它会记录停止的地方。不干净地关闭slave可能产生问题，特别是系统关闭了但缓存还没刷新到磁盘时。可以提供不间断电源来提高系统容错性。master的不干净关闭可能导致表和二进制内容的不一致；如果是 InnoDB 表，使用 --innodb-safe-binlog 选项在master上就能避免这个问题。详情请看"5.9.4 The Binary Log"。

由于 MyISAM 表的非事务本质，就可能发生一个语句只更新了部分表就返回错误代码的情况。例如，一个多重插入语句中，有一条记录违反了约束键规则，一个更新语句在更新了一些记录后辈杀掉了。如果在master上发生这种情况了，那么slave线程会推出，等待数据库管理员决定要怎么做，除非这个错误代码是合法的并且这个语句的执行结果也是一样的错误代码。并没有关于错误代码是否合法的详细描述，一些错误代码可以用 --slave-skip-errors 选项屏蔽掉。这个选项从MySQL 3.23.47开始就可以用了。

如果把非事务表同步到事务表时在一个 BEGIN/COMMIT 段内更新数据表了，如果在非事务表提交之前有其他线程更新它了，那么这个更新操作就不会正确地同步到二进制日志中。这是因为只有整个事务成功提交了才会写到二进制日志中。

在4.0.15之前，任何在非事务表的更新操作会在它执行的时候立刻写入到二进制日志中，然而事务表的更新只有在 COMMIT 后才写入，ROLLBACK 的话就不写入了。因此在一些事务中更新事务表或非事务表时就需要考虑这个情况了(不只是同步时会碰到这个问题，想要把二进制日志作为备份时也一样)。在MySQL 4.0.15中，我们已经修改了更新事务和非事务表混合的情况下的日志记录行为，它解决了这个问题(对于二进制日志来说顺序地记录语句是比较不错的做法，所有必须的语句都会写进去，ROLLBACK 也一样)。当第二个连接更新非事务表而第一个连接的事务还没结束时，就会有同样的问题了；仍会发记录语句顺序发生错误的问题，因为第二个连接会在更新完成后立刻写入到日志中。

当4.x的slave从3.23的master上同步 LOAD DATA INFILE 时，SHOW SLAVE STATUS 中的 Exec_Master_Log_Pos 和 Relay_Log_Space 字段的值就不正确了。Exec_Master_Log_Pos 值不正确的话在重启slave之后会导致问题；因此最好在重启前修改一下这个值，只需在master上运行 FLUSH LOGS。这个bug在MySQL 5.0.0的slave中已经解决了。

下表列出了MySQL 3.23同步时会发生的问题，它们在MySQL 4.0已经解决了：

LOAD DATA INFILE 能正确处理，只要那个数据文件在更新开始时仍然存在于master上。

LOAD DATA LOCAL INFILE 不再像以前3.23那样被略过了。

在3.23中，RAND() 更新同步不正常。因此在使用 RAND() 更新时采用 RAND(some_non_rand_expr) 格式。例如，可以用 UNIX_TIMESTAMP() 作为 RAND() 的参数。