手册版本同步的

6.5 不同MySQL版本之间的同步兼容性

最早的二进制格式是在MySQL 3.23中开发出来的。在MySQL 4.0中改进了，MySQL 5.0又改进了。在配置同步时需要升级服务器的话，它们之间的因果关系在\"6.6 Upgrading a Replication Setup\"中描述了。

如果只关心同步，任何MySQL 4.1.x版本和MySQL 4.0.x是一样的，因为它们都使用相同格式的二进制日志。所以，这些版本是互相兼容的，它们之间可以无缝地运行同步。一个例外的情况是，MySQL 4.0.0到4.0.2由于开发的较早，无法和后来的版本互相兼容，所以不要使用它们(它们是4.0版本的alpha系列。它们之间的兼容性在发布包的手册中均有相关文档)。

下表展示了不同版本的MySQL之间的master/slave同步兼容性。

Master Master Master3.23.33 and up 4.0.3 and up or any 4.1.x 5.0.0Slave 3.23.33 and up yes no noSlave 4.0.3 and up yes yes noSlave 5.0.0 yes yes yes

一个通常的规则是，我们建议使用最近的MySQL版本，因为同步兼容性一直在改善。我们也建议master和slave都使用同一个版本。

6.6 升级同步

如果升级服务器时涉及到配置同步，升级设置的步骤跟当前版本以及升级后的版本不同而异。

6.6.1 升级同步到 4.0 或 4.1

本节适用于从MySQL 3.23升级到4.0或者4.1的情况。4.0的服务器必须是4.0.3或者更高，\"6.5 Replication Compatibility Between MySQL Versions\"中提到了。

把master从MySQL 3.23升级到4.0或4.1时，首先要确认这个master的所有slave都已经是4.0或4.1了，否则的话，要先升级slave：挨个关闭，升级，重启，重启同步等。

通过以下步骤可以实现安全地升级，假定master要升级到3.23，而slave已经是4.0或4.1了。注意，master升级后，不要重启使用任何旧的二进制日志的同步，因为它会干扰到4.0或4.1 slave的同步。

在master上执行 FLUSH TABLES WITH READ LOCK 语句，阻止所有的更新。

等到所有的slave都跟上了master的数据更新。在master上执行 SHOW MASTER STATUS 语句取得二进制日志以及偏移位置。然后，再slave用这些值执行 SELECT MASTER_POS_WAIT() 语句，它会阻止slave上的同步且返回它已经同步的偏移位置。然后在slave上执行 STOP SLAVE 语句。

关闭master，将它升级到MySQL 4.0或4.1。

重启master，记下它的新的二进制文件名。可以在master上执行 SHOW MASTER STATUS 语句来取得这些信息。然后在每个slave上都执行如下语句：

mysql CHANGE MASTER TO MASTER_LOG_FILE=\'binary_log_name\',

- MASTER_LOG_POS=4;

mysql START SLAVE;

6.6.2 升级同步到 5.0

用的好。因此 本节适用于从MySQL 3.23，4.0或4.1升级到5.0的情况。4.0的服务器必须是4.0.3或者更高，\"6.5 Replication Compatibility Between MySQL Versions\"中提到了。

首先，注意到MySQL 5.0还是alpha发布系列。它在各方面都比旧版本好(更容易升级一些同步中重要的会话变量，例如 sql_mode；详情请看\"C.1.3 Changes in release 5.0.0 (22 Dec 2003: Alpha\")。不过，它还没经过广泛测试。由于是alpha版本，我们不建议用于任何生产环境(现在已经可以用于生产了，译者注)。

把master 从MySQL 3.23，4.0或4.1升级到5.0.0时，首先要确认这个master的所有slave都已经是5.0.0了，否则的话，要先升级slave：挨个关闭，升级，重启，重启同步等。5.0.0的slave可以读取升级前写入的执行语句的中继日志。升级完后的slave创建的中继日志就是5.0格式了。

当所有的slave都升级完了，关闭master，升级到5.0.0，然后重启。5.0.0的master也可以读取旧格式的二进制日志。slave能识别旧的格式并且合理处理它们。master上新建的二进制日志都是5.0.0格式的。slave也能识别这格式。

换言之，在升级到5.0.0时无需特殊的规定，除非在升级master到5.0.0之前slave必须使用旧版本的。注意，把5.0.0降级到旧版本中不能自动地做了：必须确保所有的5.0.0格式二进制日志和中继日志都已经处理完了，然后才能把它们删除完成降级。

6.7 同步特性及已知问题

以下列出了同步支持什么，不支持什么。附加的 InnoDB 特殊相关的信息以及同步请看\"16.7.5 InnoDB and MySQL Replication\"。

AUTO_INCREMENT, LAST_INSERT_ID(), 和 TIMESTAMP 的值都能被正常同步。

USER(), UUID(), 和 LOAD_FILE() 函数都完完全全地同步到slave，因此可能不大可靠。MySQL 4.1.1以前的版本中的 CONNECTION_ID() 函数也是如此。从MySQL 4.1.1及更高以后，新的 PASSWORD() 函数可以正常同步，当然了，slave必须是4.1.1或更高或者不同步它。如果有旧版本的slave必须要同步 PASSWORD() 函数，那么master启动时必须增加 --old-password 选项，这样在master上就用旧的方法来实现 PASSWORD() 了(注意，MySQL 4.1.0的 PASSWORD() 函数实现跟其他的版本都不同，最好不要同步4.1.0)。

从MySQL 4.0.14开始同步 FOREIGN_KEY_CHECKS 变量。从5.0.0开始同步 sql_mode, UNIQUE_CHECKS,和 SQL_AUTO_IS_NULL 变量。 SQL_SELECT_LIMIT 和 table_type 变量目前还不能被同步。