升级参与复制设置的服务器时，升级过程取决于当前服务器版本和要升级到的版本。本节提供有关升级如何影响复制的信息。有关升级MySQL的一般信息，请参见章节2.11，“升级MySQL”

当您将一个源代码从早期的MySQL版本系列升级到5.7时，您应该首先确保该源代码的所有副本都使用相同的5.7。x版本。如果不是这样，您应该首先升级副本。要升级每个副本，请关闭它，将其升级到适当的5.7。X版本，重新启动后，重新启动复制。升级后副本创建的中继日志格式为5.7。

影响严格SQL模式下操作的更改(STRICT_TRANS_TABLES或STRICT_ALL_TABLES)可能导致更新副本复制失败。例如，在MySQL 5.7.2中，服务器限制插入默认的严格模式下的时态数据类型为0。如果使用基于语句的日志记录(binlog_format =声明)，如果一个副本在源文件之前升级，未升级的源文件执行的语句没有错误，这些语句可能会在副本上失败，复制也会停止。要处理这个问题，停止源上的所有新语句，并等待副本赶上。然后升级副本。或者，如果不能停止新语句，请临时更改为源(binlog_format =行)并等待，直到所有副本都处理了到此更改点为止产生的所有二进制日志。然后升级副本。

在副本升级之后，关闭源，将其升级到相同的5.7版本。X版本作为副本，并重新启动它。如果您临时将源更改为基于行的日志记录，请将其更改为基于语句的日志记录。5.7源代码能够读取在升级之前写入的旧二进制日志，并将它们发送到5.7副本。副本可以识别旧格式并正确地处理它。升级后源端生成的二进制日志格式为5.7。这些也被5.7复制品识别。

换句话说，当升级到MySQL 5.7时，副本必须是MySQL 5.7，然后才能将源文件升级到5.7。注意，从5.7版本降级到旧版本并不是那么简单:您必须确保任何5.7二进制日志或中继日志都已被完全处理，以便在继续降级之前将其删除。

当您从一个MySQL系列转移到下一个MySQL系列时，某些升级可能要求您删除并重新创建数据库对象。例如，排序规则更改可能需要重新构建表索引。如有必要，此类操作详列于章节2.11.3，“MySQL 5.7的变化”．最安全的方法是分别在副本和源上执行这些操作，并禁止从源复制这些操作到副本。要实现这一点，请使用以下步骤:

如果您正在将现有的复制设置从不支持全局事务标识符的MySQL版本升级到支持全局事务标识符的版本，在确保设置满足基于gtid的复制的所有要求之前，不应该在源或副本上启用gtid。例如server_uuid，它是在MySQL 5.6中添加的，gtid必须存在才能正常工作。看到第16.1.3.4节，“使用gtid建立复制”，其中包含有关将现有复制设置转换为使用基于gtid的复制的信息。

当服务器运行时启用了全局事务标识符(gtid)时(gtid_mode =对)，不启用二进制日志记录bymysql_upgrade．

当服务器开启gtid功能时，不建议加载转储文件。gtid_mode =对)，如果您的转储文件包括系统表。, mysqldump为使用非事务性MyISAM存储引擎的系统表发出DML指令，当启用gtid时，这种组合是不允许的。还要注意，从启用了gtid的服务器加载转储文件到启用了gtid的另一个服务器，会生成不同的事务标识符。