升级参与复制设置的服务器时，升级过程取决于当前服务器版本和要升级到的版本。本节提供有关升级如何影响复制的信息。有关升级MySQL的一般信息，请参见第2.11节“升级MySQL”
从较早的MySQL版本系列将主服务器升级到5.6时，首先应确保该主服务器的所有从服务器都使用相同的5.6.x版本。如果不是这种情况，则应首先升级从站。要升级每个从属服务器，请将其关闭，将其升级到适当的5.6.x版本，重新启动它，然后重新启动复制。从站在升级后创建的中继日志为5.6格式。
影响严格SQL模式下操作的更改可能会导致更新的从属服务器上的复制失败。例如，从MySQL 5.6.13开始，服务器DEFAULT在严格模式（STRICT_TRANS_TABLES 或STRICT_ALL_TABLES）下限制为临时数据类型插入 值0 。如果使用基于语句的日志记录（binlog_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系列迁移到另一个MySQL系列时，某些升级可能需要删除并重新创建数据库对象。例如，排序规则更改可能需要重建表索引。如有必要，此类操作在第2.11.3节“ MySQL 5.6中的更改”中进行了详细介绍 。在从属服务器和主服务器上分别执行这些操作，并禁用这些操作从主服务器到从属服务器的复制是最安全的。为此，请使用以下过程：
停止所有从属并升级它们。使用–skip-slave-start选项重新启动它们，以 使它们不连接到主机。执行重新创建数据库对象所需的任何表修复或重建操作，例如使用REPAIR TABLE或 ALTER 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_mode=ON）全局事务标识符（GTID）的情况下运行时，请勿通过mysql_upgrade启用二进制日志记录。
gtid_mode=ON如果转储文件包含系统表， 则不建议在服务器（）上启用GTID时加载转储文件。 mysqldump为使用非事务性MyISAM存储引擎的系统表发出DML指令，并且在启用GTID时不允许这种组合。还应注意，将一个启用了GTID的服务器中的转储文件加载到另一个启用了GTID的服务器中，会导致生成不同的事务标识符。
