16.4.3 升级复制拓扑

当您升级参与复制拓扑的服务器时，您需要考虑每个服务器在拓扑中的角色并注意特定于复制的问题。有关升级 MySQL 服务器实例的一般信息和说明，请参阅第 2.11 节，“升级 MySQL”。

如 第 16.4.2 节“MySQL 版本之间的复制兼容性”中所述，MySQL 支持从运行一个版本系列的源复制到运行下一个更高版本系列的副本，但不支持从运行更高版本的源复制到运行更早版本的副本。较早版本的副本可能不具备处理可由较晚版本的源处理的事务的能力。因此，在将源服务器升级到目标版本之前，您必须将复制拓扑中的所有副本升级到目标 MySQL 服务器版本。通过这种方式，您永远不会遇到仍然处于较早版本的副本试图处理来自较晚版本的源的事务的情况。

在有多个源（多源复制）的复制拓扑中，不支持使用两个以上的 MySQL 服务器版本，无论源或副本 MySQL 服务器的数量如何。此限制不仅适用于发布系列，还适用于同一发布系列中的版本号。例如，您不能在这样的设置中同时使用 MySQL 5.7.22、MySQL 5.7.24 和 MySQL 5.7.28，尽管您可以同时使用这些版本中的任何两个。

如果您需要降级复制拓扑中的服务器，则必须在降级副本之前降级源。在副本上，您必须确保二进制日志和中继日志已被完全处理，并在继续降级之前将其删除。

版本之间的行为变化

尽管此升级顺序是正确的，但从尚未升级的较早版本的源复制到已升级的较新版本的副本时，仍然可能遇到复制困难。如果源使用的语句或依赖的行为在副本上安装的更高版本中不再受支持，则可能会发生这种情况。您可以使用 MySQL Shell 的升级检查器实用程序 util.checkForServerUpgrade()检查 MySQL 5.7 服务器实例或 MySQL 8.0 服务器实例以升级到 GA MySQL 8.0 版本。该实用程序会识别该服务器实例需要修复的任何内容，以便在升级后不会引起问题，包括在更高版本中不再可用的功能和行为。有关 升级检查器实用程序的信息，请参阅升级检查器实用程序。

如果您要将现有复制设置从不支持全局事务标识符 (GTID) 的 MySQL 版本升级到支持的版本，请仅在确保设置满足所有要求后在源和副本上启用 GTID用于基于 GTID 的复制。有关将基于二进制日志文件位置的复制设置转换为使用基于 GTID 的复制的信息 ，请参阅 第 16.1.3.4 节，“使用 GTID 设置复制”。

影响严格 SQL 模式 (STRICT_TRANS_TABLES或 STRICT_ALL_TABLES) 操作的更改可能会导致升级副本上的复制失败。如果您使用基于语句的日志记录 ( binlog_format=STATEMENT)，如果副本在源之前升级，则源执行的语句在那里成功但可能在副本上失败，因此导致复制停止。为了解决这个问题，停止源上的所有新语句并等待副本赶上，然后升级副本。或者，如果您无法停止新语句，请暂时更改为基于行的源日志记录（binlog_format=ROW) 并等到所有副本都处理了到此更改为止生成的所有二进制日志，然后升级副本。

默认字符集在 MySQL 8.0 中 已从更改 latin1为。utf8mb4在复制设置中，从 MySQL 5.7 升级到 8.0 时，建议在升级前将默认字符集更改回 MySQL 5.7 中使用的字符集。升级完成后，可以将默认字符集更改为utf8mb4. 假设使用了以前的默认值，一种保留它们的方法是使用my.cnf文件中的这些行启动服务器： 

[mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ci

标准升级程序

要升级复制拓扑，请按照 第 2.11 节“升级 MySQL”中的说明为每个单独的 MySQL 服务器实例使用此总体过程：

  1. 首先升级副本。在每个副本实例上：

    • 执行 准备升级安装中描述的初步检查和步骤。

    • 关闭 MySQL 服务器。

    • 升级 MySQL 服务器二进制文件或包。

    • 重新启动 MySQL 服务器。

    • 如果您升级到 MySQL 8.0.16 之前的版本，请手动调用mysql_upgrade来升级系统表和模式。当服务器运行时启用了全局事务标识符 (GTID) ( gtid_mode=ON)，请不要通过 mysql_upgrade启用二进制日志记录（因此不要使用该 --write-binlog 选项）。然后关闭并重新启动服务器。

    • 如果您已升级到 MySQL 8.0.16 或更高版本，请不要调用mysql_upgrade。从那个版本开始，MySQL 服务器执行整个 MySQL 升级过程，在升级期间禁用二进制日志记录。

    • 使用START REPLICAorSTART SLAVE语句重新启动复制。

  2. 当所有副本都已升级后，按照相同的步骤升级并重新启动源服务器，但START REPLICAorSTART SLAVE语句除外。如果您临时更改了基于行的日志记录或默认字符集，您现在可以恢复更改。

表修复或重建的升级过程

当您从一个 MySQL 系列移动到下一个系列时，某些升级可能需要您删除并重新创建数据库对象。例如，排序规则更改可能需要重建表索引。如有必要，此类操作在 第 2.11.3 节“MySQL 5.7 中的更改”中有详细说明。最安全的做法是分别在副本和源上执行这些操作，并禁止将这些操作从源复制到副本。为此，请使用以下过程：

  1. 停止所有副本并升级二进制文件或包。--skip-slave-start使用系统变量选项或从 MySQL 8.0.24 重新启动它们 skip_slave_start ，这样它们就不会连接到源。执行重新创建数据库对象所需的任何表修复或重建操作，例如使用REPAIR TABLEorALTER TABLE或转储和重新加载表或触发器。

  2. 禁用源上的二进制日志。要在不重新启动源的情况下执行此操作，请执行一条SET sql_log_bin = OFF语句。或者，停止源并使用该 --skip-log-bin 选项重新启动它。如果重新启动源，您可能还想禁止客户端连接。例如，如果所有客户端都使用 TCP/IP 连接， skip_networking 请在重新启动源时启用系统变量。

  3. 在禁用二进制日志的情况下，执行重新创建数据库对象所需的任何表修复或重建操作。在此步骤中必须禁用二进制日志，以防止这些操作被记录下来并在以后发送到副本。

  4. 在源上重新启用二进制日志。如果设置 sql_log_bin为 OFF更早，则执行一条SET sql_log_bin = ON语句。如果您重新启动源以禁用二进制日志，请在 --skip-log-bin不启用 skip_networking系统变量的情况下重新启动它，以便客户端和副本可以连接。

  5. 重新启动副本，这次没有 --skip-slave-start选项或 skip_slave_start系统变量。