Documentation Home
MySQL 8.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 39.8Mb
PDF (A4) - 39.9Mb
Man Pages (TGZ) - 257.9Kb
Man Pages (Zip) - 364.9Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 Reference Manual  /  ...  /  Switching Sources During Failover

19.4.8 故障转移期间切换源

您可以使用CHANGE REPLICATION SOURCE TO语句将复制源切换到新源。复制源不检查源数据库与复制数据库的兼容性,而是从指定的新源的二进制日志文件中读取和执行事件。在故障转移情况下,所有服务器通常都执行来自同一个二进制日志文件的事件,因此切换事件源不应影响数据库的结构或完整性,假设您在进行更改时小心。

复制服务器应该启用二进制日志记录(默认情况下),使用--log-bin选项。如果您不使用GTIDs进行复制,那么复制服务器也应该启用--log-replica-updates=OFF(默认情况下),以便复制服务器准备好成为新源而不需要重新启动mysqld。假设您已经拥有如Figure 19.4, “Redundancy Using Replication, Initial Structure”所示的结构。

Figure 19.4 Redundancy Using Replication, Initial Structure

Two web clients direct both database reads and database writes to a single MySQL source server. The MySQL source server replicates to Replica 1, Replica 2, and Replica 3.

在这个图中,Source持有源数据库,Replica*主机是复制服务器,Web Client机器是数据库读取和写入的客户端。只读的Web客户端(通常连接到复制服务器)没有显示,因为它们不需要在故障转移时切换到新服务器。对于读写扩展复制结构的详细示例,请参阅Section 19.4.5, “Using Replication for Scale-Out”

每个MySQL复制服务器(Replica 1Replica 2Replica 3)都是启用二进制日志记录的复制服务器,并且启用--log-replica-updates=OFF。由于在指定--log-replica-updates=OFF时,来自源的更新不会被写入二进制日志,因此每个复制服务器的二进制日志文件是空的。假设源数据库不可用,您可以选择其中一个复制服务器作为新源。例如,如果您选择Replica 1,所有Web Clients应该被重定向到Replica 1,它将写入更新到其二进制日志文件。Replica 2Replica 3应该从Replica 1复制。

为了防止复制服务器接收到更新两次,在您将一个复制服务器变为新的源时,可以使用--log-replica-updates=OFF来运行复制服务器。如果Replica 1启用了--log-replica-updates,这是默认设置,它将在自己的二进制日志中写入来自Source的所有更新。这意味着,当Replica 2Source变为Replica 1时,它可能会从Replica 1接收已经从Source接收的更新。

确保所有复制服务器已经处理了其中继日志中的语句。在每个复制服务器上,执行STOP REPLICA IO_THREAD,然后查看SHOW PROCESSLIST的输出,直到看到Has read all relay log。当所有复制服务器都满足这个条件时,他们可以被重新配置到新的设置上。在将复制服务器Replica 1变为源时,执行STOP REPLICARESET BINARY LOGS AND GTIDS

在其他复制服务器Replica 2Replica 3上,使用STOP REPLICACHANGE REPLICATION SOURCE TO SOURCE_HOST='Replica1'(其中'Replica1'表示Replica 1的实际主机名)。要使用CHANGE REPLICATION SOURCE TO,添加来自Replica 2Replica 3Replica 1的连接信息(userpasswordport)。在这种情况下,不需要指定Replica 1的二进制日志文件或日志位置,因为第一个二进制日志文件和位置4是默认值。最后,执行START REPLICAReplica 2Replica 3上。

在新的复制设置中,您需要将每个Web Client告知将语句发送到Replica 1。从那时起,所有由Web Client发送到Replica 1的更新将被写入Replica 1的二进制日志中,该日志中包含自Source unavailable以来发送到Replica 1的所有更新。

结果服务器结构在图19.5,“使用复制实现冗余,源端故障后”中显示。

图19.5 使用复制实现冗余,源端故障后

The MySQL source server has failed, and is no longer connected into the replication topology. The two web clients now direct both database reads and database writes to Replica 1, which is the new source. Replica 1 replicates to Replica 2 and Replica 3.

Source再次可用时,您应该将其设置为Replica 1的副本。要实现此操作,在Source上执行与之前在Replica 2Replica 3上执行的相同CHANGE REPLICATION SOURCE TO语句。然后,Source将变为Replica 1的副本,并捕捉它在离线期间错过的Web Client写入。

要将Source设置为源端,请按照前面的过程进行操作,如假设Replica 1不可用,Source将成为新的源端。在这个过程中,不要忘记在Source上运行RESET BINARY LOGS AND GTIDS语句,以便在将Replica 1Replica 2Replica 3设置为Source的副本。如果您忘记执行此操作,副本可能会从Web Client应用程序中获取 stale写入,来自于Source不可用的时间点之前。

您应该注意,即使副本共享同一个源,也没有同步关系,因此一些副本可能会落后于其他副本。这意味着,在某些情况下,前面的过程可能不会如预期那样工作。在实际中,所有副本的relay日志应该相对接近。

一种保持应用程序了解源端位置的方法是使用动态DNS记录。使用BIND,可以使用nsupdate更新DNS动态记录。