19.4.8 故障转移期间切换源
您可以使用CHANGE REPLICATION SOURCE TO
语句将复制源切换到新源。复制源不检查源数据库与复制数据库的兼容性,而是从指定的新源的二进制日志文件中读取和执行事件。在故障转移情况下,所有服务器通常都执行来自同一个二进制日志文件的事件,因此切换事件源不应影响数据库的结构或完整性,假设您在进行更改时小心。
复制服务器应该启用二进制日志记录(默认情况下),使用--log-bin
选项。如果您不使用GTIDs进行复制,那么复制服务器也应该启用--log-replica-updates=OFF
(默认情况下),以便复制服务器准备好成为新源而不需要重新启动mysqld。假设您已经拥有如Figure 19.4, “Redundancy Using Replication, Initial Structure”所示的结构。
在这个图中,Source
持有源数据库,Replica*
主机是复制服务器,Web Client
机器是数据库读取和写入的客户端。只读的Web客户端(通常连接到复制服务器)没有显示,因为它们不需要在故障转移时切换到新服务器。对于读写扩展复制结构的详细示例,请参阅Section 19.4.5, “Using Replication for Scale-Out”。
每个MySQL复制服务器(Replica 1
,Replica 2
和Replica 3
)都是启用二进制日志记录的复制服务器,并且启用--log-replica-updates=OFF
。由于在指定--log-replica-updates=OFF
时,来自源的更新不会被写入二进制日志,因此每个复制服务器的二进制日志文件是空的。假设源数据库不可用,您可以选择其中一个复制服务器作为新源。例如,如果您选择Replica 1
,所有Web Clients
应该被重定向到Replica 1
,它将写入更新到其二进制日志文件。Replica 2
和Replica 3
应该从Replica 1
复制。
为了防止复制服务器接收到更新两次,在您将一个复制服务器变为新的源时,可以使用--log-replica-updates=OFF
来运行复制服务器。如果Replica 1
启用了--log-replica-updates
,这是默认设置,它将在自己的二进制日志中写入来自Source
的所有更新。这意味着,当Replica 2
从Source
变为Replica 1
时,它可能会从Replica 1
接收已经从Source
接收的更新。
确保所有复制服务器已经处理了其中继日志中的语句。在每个复制服务器上,执行STOP REPLICA IO_THREAD
,然后查看SHOW PROCESSLIST
的输出,直到看到Has read all relay log
。当所有复制服务器都满足这个条件时,他们可以被重新配置到新的设置上。在将复制服务器Replica 1
变为源时,执行STOP REPLICA
和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是默认值。最后,执行START REPLICA
在Replica 2
和Replica 3
上。
在新的复制设置中,您需要将每个Web Client
告知将语句发送到Replica 1
。从那时起,所有由Web Client
发送到Replica 1
的更新将被写入Replica 1
的二进制日志中,该日志中包含自Source
unavailable以来发送到Replica 1
的所有更新。
结果服务器结构在图19.5,“使用复制实现冗余,源端故障后”中显示。
当Source
再次可用时,您应该将其设置为Replica 1
的副本。要实现此操作,在Source
上执行与之前在Replica 2
和Replica 3
上执行的相同CHANGE REPLICATION SOURCE TO
语句。然后,Source
将变为Replica 1
的副本,并捕捉它在离线期间错过的Web Client
写入。
要将Source
设置为源端,请按照前面的过程进行操作,如假设Replica 1
不可用,Source
将成为新的源端。在这个过程中,不要忘记在Source
上运行RESET BINARY LOGS AND GTIDS
语句,以便在将Replica 1
、Replica 2
、Replica 3
设置为Source
的副本。如果您忘记执行此操作,副本可能会从Web Client
应用程序中获取 stale写入,来自于Source
不可用的时间点之前。
您应该注意,即使副本共享同一个源,也没有同步关系,因此一些副本可能会落后于其他副本。这意味着,在某些情况下,前面的过程可能不会如预期那样工作。在实际中,所有副本的relay日志应该相对接近。
一种保持应用程序了解源端位置的方法是使用动态DNS记录。使用BIND
,可以使用nsupdate更新DNS动态记录。