MySQL 8.4 Release Notes
您可以使用 CHANGE REPLICATION SOURCE TO 语句告诉副本切换到新的源。副本不会检查源上的数据库是否与副本上的数据库兼容；它只是开始从新源的二进制日志中指定的坐标读取和执行事件。在故障切换的情况下，组中的所有服务器通常都在从同一二进制日志文件执行相同的事件，因此更改事件源不应影响数据库的结构或完整性，前提是您在进行更改时要小心。You can tell a replica to change to a new source using the
CHANGE REPLICATION SOURCE TO
statement. The replica does not check whether the databases on the
source are compatible with those on the replica; it simply begins
reading and executing events from the specified coordinates in the
new source's binary log. In a failover situation, all the
servers in the group are typically executing the same events from
the same binary log file, so changing the source of the events
should not affect the structure or integrity of the database,
provided that you exercise care in making the change.
副本应在启用二进制日志的情况下运行（--log-bin 选项），这是默认设置。如果您没有使用 GTID 进行复制，那么副本也应该运行 --log-replica-updates=OFF（记录副本更新是默认设置）。通过这种方式，副本可以在无需重启副本 mysqld 的情况下准备好成为源。假设您拥有 图 19.4，“使用复制实现冗余，初始结构” 中显示的结构。Replicas should be run with binary logging enabled (the
--log-bin option), which is the
default. If you are not using GTIDs for replication, then the
replicas should also be run with
--log-replica-updates=OFF (logging
replica updates is the default). In this way, the replica is ready
to become a source without restarting the replica
mysqld. Assume that you have the structure
shown in Figure 19.4, “Redundancy Using Replication, Initial Structure”.
在此图中，Source 保存源数据库，Replica* 主机是副本，而 Web Client 机器正在发起数据库读取和写入。仅发起读取的 Web 客户端（通常会连接到副本）未显示，因为在发生故障时它们无需切换到新的服务器。有关读/写扩展复制结构的更详细示例，请参见 第 19.4.5 节，“使用复制进行扩展”。In this diagram, the Source holds the source
database, the Replica* hosts are replicas, and
the Web Client machines are issuing database
reads and writes. Web clients that issue only reads (and would
normally be connected to the replicas) are not shown, as they do
not need to switch to a new server in the event of failure. For a
more detailed example of a read/write scale-out replication
structure, see Section 19.4.5, “Using Replication for Scale-Out”.
每个 MySQL 副本（Replica 1、Replica
2 和 Replica 3）都是启用二进制日志的副本，并且设置了 --log-replica-updates=OFF。由于当指定 --log-replica-updates=OFF 时，从源接收的更新不会写入二进制日志，因此每个副本的二进制日志最初都是空的。如果由于某种原因 Source 变得不可用，您可以选择一个副本成为新的源。例如，如果选择 Replica 1，所有 Web Clients 应该重定向到 Replica 1，该副本将更新写入其二进制日志。然后，Replica 2 和 Replica
3 应该从 Replica
1 进行复制。Each MySQL replica (Replica 1, Replica
2, and Replica 3) is a replica
running with binary logging enabled, and with
--log-replica-updates=OFF. Because
updates received by a replica from the source are not written to
the binary log when --log-replica-updates=OFF is
specified, the binary log on each replica is initially empty. If
for some reason Source becomes unavailable, you
can pick one of the replicas to become the new source. For
example, if you pick Replica 1, all
Web Clients should be redirected to
Replica 1, which writes the updates to its
binary log. Replica 2 and Replica
3 should then replicate from Replica
1.
运行副本时使用 --log-replica-updates=OFF 的原因是防止在你让其中一个副本成为新的源时，副本接收更新两次。如果 Replica 1 启用了 --log-replica-updates（默认设置），它会将从 Source 接收到的任何更新写入自己的二进制日志。这意味着，当 Replica 2 将其源从 Source 改为 Replica 1 时，它可能会从 Replica
1 接收到它已经从 Source 接收过的更新。The reason for running the replica with
--log-replica-updates=OFF is to
prevent replicas from receiving updates twice in case you cause
one of the replicas to become the new source. If Replica
1 has --log-replica-updates enabled,
which is the default, it writes any updates that it receives from
Source in its own binary log. This means that,
when Replica 2 changes from
Source to Replica 1 as its
source, it may receive updates from Replica 1
that it has already received from Source.
确保所有副本都已处理其中继日志中的任何语句。在每个副本上，执行 STOP REPLICA
IO_THREAD，然后检查 SHOW PROCESSLIST 的输出，直到看到 Has read all relay log。当所有副本都满足此条件时，它们可以重新配置为新的设置。在被提升为源的副本 Replica 1 上，执行 STOP REPLICA 和 RESET BINARY LOGS AND GTIDS。Make sure that all replicas have processed any statements in their
relay log. On each replica, issue STOP REPLICA
IO_THREAD, then check the output of
SHOW PROCESSLIST until you see
Has read all relay log. When this is true for
all replicas, they can be reconfigured to the new setup. On the
replica Replica 1 being promoted to become the
source, issue STOP REPLICA and
RESET BINARY LOGS AND GTIDS.
在其他副本 Replica 2 和 Replica 3 上，使用 STOP
REPLICA 和 CHANGE REPLICATION SOURCE TO
SOURCE_HOST='Replica1'（其中 'Replica1' 代表 Replica 1 的真实主机名）。要使用 CHANGE
REPLICATION SOURCE TO，需添加如何从 Replica 2 或 Replica 3 连接到 Replica 1 的所有信息（user、password、port）。在此场景下执行该语句时，无需指定 Replica 1 的二进制日志文件名或读取的日志位置，因为默认使用第一个二进制日志文件和位置 4。最后，在 Replica
2 和 Replica 3 上执行 START
REPLICA。On the other replicas Replica 2 and
Replica 3, use STOP
REPLICA and CHANGE REPLICATION SOURCE TO
SOURCE_HOST='Replica1' (where
'Replica1' represents the real host name of
Replica 1). To use CHANGE
REPLICATION SOURCE TO, add all information about how to
connect to Replica 1 from Replica
2 or Replica 3
(user,
password,
port). When issuing the statement in
this scenario, there is no need to specify the name of the
Replica 1 binary log file or log position to
read from, since the first binary log file and position 4 are the
defaults. Finally, execute START
REPLICA on Replica 2 and
Replica 3.
一旦新的复制设置到位，你需要告诉每个 Web Client 将其操作指向 Replica 1。从那时起，所有由 Web Client 发送到 Replica 1 的更新都会写入 Replica 1 的二进制日志中，该日志随后会包含自 Replica
1 不可用以来发送到 Source 的每一次更新。Once the new replication setup is in place, you need to tell each
Web Client to direct its statements to
Replica 1. From that point on, all updates sent
by Web Client to Replica 1
are written to the binary log of Replica 1,
which then contains every update sent to Replica
1 since Source became unavailable.
由此形成的服务器结构如 图 19.5，“使用复制实现冗余，源故障后” 所示。The resulting server structure is shown in Figure 19.5, “Redundancy Using Replication, After Source Failure”.
当 Source 再次可用时，你应该将它设置为 Replica 1 的副本。为此，在 Source 上执行与先前在 Replica 2 和 Replica 3 上执行的相同的 CHANGE REPLICATION SOURCE TO 语句。Source 然后变成 Replica 1 的副本，并补上在它离线期间错过的 Web Client 写入操作。When Source becomes available again, you should
make it a replica of Replica 1. To do this,
issue on Source the same
CHANGE REPLICATION SOURCE TO
statement as that issued on Replica 2 and
Replica 3 previously. Source
then becomes a replica of Replica 1 and picks
up the Web Client writes that it missed while
it was offline.
要使 Source 再次成为源，请按照前述步骤操作，就像 Replica 1 不可用且 Source 将成为新的源一样。在此过程中，不要忘记在将 RESET BINARY LOGS AND GTIDS、Replica 2 和 Source 设置为 Source 的副本之前，在 Source 上运行 Replica
1。如果不这样做，副本可能会从 Web Client 应用程序中获取过时的写入，这些写入发生在 Replica
3 变得不可用之前。To make Source a source again, use the
preceding procedure as if Replica 1 were
unavailable and Source were to be the new
source. During this procedure, do not forget to run
RESET BINARY LOGS AND GTIDS on
Source before making Replica
1, Replica 2, and Replica
3 replicas of Source. If you fail to
do this, the replicas may pick up stale writes from the
Web Client applications dating from before the
point at which Source became unavailable.
您应该注意，即使副本共享相同的源，副本之间也没有同步，因此有些副本可能比其他副本领先很多。这意味着在某些情况下，前面示例中列出的操作可能无法按预期工作。然而，在实际操作中，所有副本的中继日志应相对接近。You should be aware that there is no synchronization between replicas, even when they share the same source, and thus some replicas might be considerably ahead of others. This means that in some cases the procedure outlined in the previous example might not work as expected. In practice, however, relay logs on all replicas should be relatively close together.
让应用程序了解源位置的一种方法是为源主机设置动态 DNS 条目。使用 BIND，您可以使用 nsupdate 动态更新 DNS。One way to keep applications informed about the location of the
source is to have a dynamic DNS entry for the source host. With
BIND, you can use
nsupdate to update the DNS
dynamically.