升级参与复制设置的服务器时，升级过程取决于当前服务器版本和要升级到的版本。本节提供有关升级如何影响复制的信息。有关升级 MySQL 的一般信息，请参阅第 2.11 节，“升级 MySQL”
当您将源从较早的 MySQL 版本系列升级到 5.6 时，您应该首先确保该源的所有副本都使用相同的 5.6.x 版本。如果不是这种情况，您应该首先升级副本。要升级每个副本，请将其关闭，将其升级到适当的 5.6.x 版本，重新启动它，然后重新启动复制。升级后副本创建的中继日志为 5.6 格式。
影响严格 SQL 模式下操作的更改可能会导致更新副本上的复制失败。例如，从 MySQL 5.6.13 开始，服务器限制
在严格模式（
或）DEFAULT下为临时数据类型插入值 0 。如果您使用基于语句的日志记录（STRICT_TRANS_TABLESSTRICT_ALL_TABLESbinlog_format=STATEMENT) 是如果一个副本被升级，一个没有被升级的源会无错误地执行语句，这些语句可能会在副本上失败并且复制停止。为了解决这个问题，停止源上的所有新语句并等待副本赶上。然后升级副本。或者，如果您无法停止新语句，请暂时更改为源 ( binlog_format=ROW) 上的基于行的日志记录，并等待所有副本处理到此更改点为止生成的所有二进制日志。然后升级副本。
副本升级后，关闭源，将其升级到与副本相同的 5.6.x 版本，然后重新启动。如果您临时将源更改为基于行的日志记录，请将其更改回基于语句的日志记录。5.6 源能够读取升级前写入的旧二进制日志，并将它们发送到 5.6 副本。副本识别旧格式并正确处理它。升级后源创建的二进制日志为 5.6 格式。这些也被 5.6 副本识别。
换句话说，当升级到 MySQL 5.6 时，副本必须是 MySQL 5.6，然后才能将源升级到 5.6。请注意，从 5.6 降级到旧版本并不是那么简单：您必须确保已完全处理任何 5.6 二进制日志或中继日志，以便您可以在继续降级之前将其删除。
当您从一个 MySQL 系列移动到下一个系列时，某些升级可能需要您删除并重新创建数据库对象。例如，排序规则更改可能需要重建表索引。如有必要，此类操作在 第 2.11.3 节“MySQL 5.6 中的更改”中有详细说明。最安全的做法是分别在副本和源上执行这些操作，并禁止将这些操作从源复制到副本。为此，请使用以下过程：
停止所有副本并升级它们。使用该选项重新启动它们，
--skip-slave-start以便它们不连接到源。执行重新创建数据库对象所需的任何表修复或重建操作，例如使用REPAIR TABLEorALTER TABLE或转储和重新加载表或触发器。禁用源上的二进制日志。要在不重新启动源的情况下执行此操作，请执行一条
SET sql_log_bin = OFF语句。或者，停止源并在没有该--log-bin选项的情况下重新启动它。如果重新启动源，您可能还想禁止客户端连接。例如，如果所有客户端都使用 TCP/IP 连接，skip_networking请在重新启动源时启用系统变量。在禁用二进制日志的情况下，执行重新创建数据库对象所需的任何表修复或重建操作。在此步骤中必须禁用二进制日志，以防止这些操作被记录下来并在以后发送到副本。
在源上重新启用二进制日志。如果设置
sql_log_bin为OFF更早，则执行一条SET sql_log_bin = ON语句。如果您重新启动源以禁用二进制日志，请使用 重新启动它--log-bin，并且不启用skip_networking系统变量，以便客户端和副本可以连接。重新启动副本，这次没有
--skip-slave-start选项。
MySQL 5.6.7 中引入了具有全局事务标识符的复制。如果要将现有复制设置从不支持 GTID 的 MySQL 版本升级到支持 GTID 的版本，则在确保设置满足基于 GTID 的所有要求之前，不应在源或副本上启用 GTID复制。请参阅 第 17.1.3.2 节，“使用 GTID 设置复制”，其中包含有关将现有复制设置转换为使用基于 GTID 的复制的信息。
当服务器在启用全局事务标识符 (GTID) 的情况下运行时 ( gtid_mode=ON)，不要通过mysql_upgrade启用二进制日志记录。
gtid_mode=ON如果您的转储文件包含系统表，
则不建议在服务器 ( ) 上启用 GTID 时加载转储文件。mysqldump为使用非事务性 MyISAM 存储引擎的系统表发出 DML 指令，并且在启用 GTID 时不允许这种组合。另请注意，将转储文件从启用了 GTID 的服务器加载到另一台启用了 GTID 的服务器中，会导致生成不同的事务标识符。