MySQL 8.4 Release Notes
当您升级参与复制拓扑的服务器时，需要考虑每台服务器在拓扑中的角色，并注意复制特有的问题。有关升级 MySQL 服务器实例的一般信息和说明，请参阅 第 3 章，升级 MySQL。When you upgrade servers that participate in a replication topology, you need to take into account each server's role in the topology and look out for issues specific to replication. For general information and instructions for upgrading a MySQL Server instance, see Chapter 3, Upgrading MySQL.
如在第 19.5.2 节，“MySQL 版本间的复制兼容性”中所解释，MySQL 支持从较旧的源服务器向较新的副本服务器进行复制，适用于我们支持从源版本升级到副本版本的版本组合，如第 1.3 节，“MySQL 发行版：创新与长期支持”和第 3.2 节，“升级路径”中描述的，但不支持从运行较新版本的源复制到运行较早版本的副本。运行较早版本的副本可能不具备处理较新版本源能够处理的事务的能力。因此，在将源服务器升级到目标 MySQL Server 版本之前，必须先将复制拓扑中的所有副本升级到目标版本。这样您就不会处于副本仍运行较早版本却尝试处理来自较新版本源的事务的情况。As explained in Section 19.5.2, “Replication Compatibility Between MySQL Versions”, MySQL supports replication from an older source to a newer replica for version combinations where we support upgrades from the source version to the replica version as described at Section 1.3, “MySQL Releases: Innovation and LTS” and Section 3.2, “Upgrade Paths”, but does not support replication from a source running a later release to a replica running an earlier release. A replica at an earlier release might not have the required capability to process transactions that can be handled by the source at a later release. You must therefore upgrade all of the replicas in a replication topology to the target MySQL Server release, before you upgrade the source server to the target release. In this way you will never be in the situation where a replica still at the earlier release is attempting to handle transactions from a source at the later release.
在存在多个源（多源复制）的复制拓扑中，不支持使用超过两个 MySQL 服务器版本，无论源服务器或副本服务器的数量是多少。例如，在这种设置中，您不能同时使用 MySQL X.Y.1、MySQL X.Y.2 和 MySQL X.Y.3，尽管您可以一起使用这三个版本中的任意两个。In a replication topology where there are multiple sources (multi-source replication), the use of more than two MySQL Server versions is not supported, regardless of the number of source or replica MySQL servers. For example, you cannot use MySQL X.Y.1, MySQL X.Y.2, and MySQL X.Y.3 concurrently in such a setup, although you could use any two of these releases together.
在从尚未升级的早期版本源复制到已经升级的较高版本副本时，可能会遇到复制困难。如果源使用的语句或依赖的行为在安装在副本上的较高版本中不再受支持，就可能发生这种情况。您可以使用 MySQL Shell 升级检查工具 util.checkForServerUpgrade() 来检查 MySQL 8.0 服务器实例是否可以升级到 MySQL 8.4 版本。该工具会识别已知可能导致升级问题的配置和存储数据，包括在较高版本中不再可用的功能和行为。有关升级检查工具的信息，请参见 升级检查工具。It is possible to encounter replication difficulties when
replicating from a source at an earlier release that has not yet
been upgraded, to a replica at a later release that has been
upgraded. This can happen if the source uses statements or
relies on behavior that is no longer supported in the later
release installed on the replica. You can use the MySQL Shell
upgrade checker utility
util.checkForServerUpgrade() to check MySQL
8.0 server instances for upgrade to a MySQL 8.4 release. This
utility identifies configuration and stored data that is known
to potentially cause upgrade problems, including features and
behaviors that are no longer available in the later release. See
Upgrade Checker Utility for information
on the upgrade checker utility.
To upgrade a replication topology, follow the instructions in 第 3 章，升级 MySQL for each individual MySQL Server instance, using this overall procedure:To upgrade a replication topology, follow the instructions in Chapter 3, Upgrading MySQL for each individual MySQL Server instance, using this overall procedure:
先升级副本。对于每个副本实例：Upgrade the replicas first. On each replica instance:
执行第 3.6 节，“为升级准备安装”中描述的初步检查和步骤。Carry out the preliminary checks and steps described in Section 3.6, “Preparing Your Installation for Upgrade”.
关闭 MySQL 服务器。Shut down MySQL Server.
升级 MySQL 服务器二进制文件或软件包。Upgrade the MySQL Server binaries or packages.
重启 MySQL 服务器。Restart MySQL Server.
MySQL 服务器会自动执行整个 MySQL 升级流程，在升级期间会禁用二进制日志记录。MySQL Server performs the entire MySQL upgrade procedure automatically, disabling binary logging during the upgrade.
使用
START REPLICA重新启动复制。Restart replication using aSTART REPLICA.
如果存在多层副本（副本的副本），请先升级距离源最远的副本，以自下而上的方式进行升级。If there are multiple layers of replicas (replicas-of-replicas) start upgrading the replicas that are farthest away from the source, performing the upgrade in a bottom-up fashion.
当所有副本都已升级且只剩下源时，执行切换到其中一个副本。换句话说，停止客户端在源上的更新，等待至少一个副本应用所有更改，重新配置复制拓扑，使该副本成为源，而原源则被移出复制拓扑。按照单服务器的升级程序升级旧源，然后将其重新插入拓扑中。When all replicas have upgraded and only the source remains, perform a switch-over to one of the replicas. In other words, stop client updates on the source, wait for at least one replica to apply all changes, reconfigure the replication topology so that replica becomes the source and that the source is left outside the replication topology. Upgrade the old source according to the procedure for a single server, and then reinsert it into the topology.
如果您需要在复制拓扑中降级服务器，必须先降级源服务器，然后再降级副本。在副本上，您必须确保二进制日志和中继日志已经完全处理完，并在继续降级之前清理它们。If you need to downgrade the servers in a replication topology, the source must be downgraded before the replicas are downgraded. On the replicas, you must ensure that the binary log and relay log have been fully processed, and purge them before proceeding with the downgrade.
滚动降级步骤Rolling Downgrade Procedure
停止更新。Stop the updates.
等待副本接收所有更新。无需等待它们应用所有更改。如果它们尚未应用所有更改，请保持其应用器运行，以便它们可以在后台处理接收到的事务。Wait for replicas to receive all updates. It is not necessary to wait for them to apply all changes. If they have not applied all changes, leave their applier running so they can process the received transactions in the background.
按照单服务器降级的说明降级源服务器。Downgrade the source server, following the instructions for single server downgrade.
将降级后的源服务器重新加入拓扑。Insert the downgraded source server in the topology again.
重新允许更新。Allow updates again.
等待直到所有副本应用完来自之前主服务器的所有剩余事务。Wait until all replicas have applied all remaining transactions from the previous primary.
对于每个副本，将副本从拓扑中取出，等待其应用所有中继日志，按照单服务器降级的说明进行降级，然后将其重新插入到拓扑中。如果存在多级副本（副本的副本），则应从上到下开始降级，从离源服务器最近的副本开始。For each replica, take out the replica from the topology, wait for it to apply all its relay log, downgrade it following the instructions for a single server downgrade, and reinsert it back into the topology. If there are multiple levels of replicas (replicas-of-replicas) then downgrade top-down starting with the replicas nearest to the source server.