属性可以告诉副本更改为新源将复制源更改为语句(从MySQL 8.0.23)或将master更改为语句(MySQL 8.0.23之前)。副本不检查源上的数据库是否与副本上的数据库兼容;它只是开始从新源二进制日志中的指定坐标中读取和执行事件。在故障转移情况下，组中的所有服务器通常都从相同的二进制日志文件执行相同的事件，因此更改事件源不应该影响数据库的结构或完整性，前提是您在进行更改时要谨慎。

副本应该在启用二进制日志记录的情况下运行——log-bin选项)，这是默认值。如果您不使用gtid进行复制，那么也应该使用这些副本运行——log-slave-updates =了(日志副本更新是默认的)。通过这种方式，无需重新启动副本，副本就可以成为源mysqld．假设您拥有中所示的结构图17.4，“使用复制的冗余，初始结构”．

图17.4使用复制、初始结构的冗余

在这个图中，MySQL源控件保存源数据库MySQL复制品主机是副本，而Web客户端机器正在执行数据库读写操作。不显示只发出读取(通常连接到副本)的Web客户机，因为它们不需要在发生故障时切换到新服务器。有关读/写横向扩展复制结构的更详细示例，请参见第17.4.5节，“使用复制进行横向扩展”．

每个MySQL副本(副本1，副本2,副本3)是在启用二进制日志记录的情况下运行的副本——log-slave-updates =了．因为副本从源接收的更新不会记录在二进制日志中——log-slave-updates =了时，每个副本上的二进制日志初始为空。如果出于某种原因MySQL源不可用时，您可以选择其中一个副本作为新的源。例如，如果你选择副本1,所有Web客户端应该重定向到副本1，它会把更新写到二进制日志中。副本2而且副本3然后从副本1．

运行副本的原因——log-slave-updates =了是防止副本接收两次更新，以防您使其中一个副本成为新的源。如果副本1有——log-slave-updates启用，这是默认值，它写入从它接收到的任何更新源在它自己的二进制日志中。这意味着，当副本2改变从源来副本1作为它的来源，它可以从副本1已经收到的源．

确保所有副本都处理了中继日志中的任何语句。在每个副本上，发行停止复制io_thread，然后检查的输出显示PROCESSLIST直到你看到是否已读取所有中继日志．当所有副本都是这样时，可以将它们重新配置为新的设置。在副本上副本1晋升成为源头，成为问题停止复制而且重置的主人．

在其他副本上副本2而且副本3,使用停止复制而且更改复制源为SOURCE_HOST='Replica1'或将MASTER更改为MASTER_HOST='Replica1'(“Replica1”的真实主机名副本1)．使用将复制源更改为|将master更改为，添加有关如何连接到的所有信息副本1从副本2或副本3（用户，密码，港口)．在此场景中发出语句时，不需要指定的名称副本1二进制日志文件或要从中读取的日志位置，因为第一个二进制日志文件和位置4是默认的。最后,执行开始复制在副本2而且副本3．

新的复制设置就绪后，您需要告知每一个Web客户端把它的陈述指向副本1．从那时起，由发送的所有更新语句Web客户端来副本1被写入二进制对数副本1，其中包含发送到的每个更新语句副本1自源停止了。

所得到的服务器结构显示在图17.5，“源故障后使用复制进行冗余”．

图17.5源端故障后，使用复制实现冗余

当源再次可用时，您应该将其复制副本1．要做到这一点，请启动源相同的将复制源更改为|将master更改为日发表的声明副本2而且副本3之前。源然后变成复制品副本1拿起Web客户端写它在脱机时丢失。

为了使源再次对源进行处理，使用上述步骤进行处理副本1不可用并且源是新的消息来源。在此过程中，不要忘记运行重置的主人在副本1之前副本1，副本2,副本3的复制品源．如果没有做到这一点，副本可能会从Web客户端申请的日期可以追溯到源变得不可用。

您应该意识到，即使在副本共享相同的源时，副本之间也没有同步，因此一些副本可能远远领先于其他副本。这意味着在某些情况下，前面示例中概述的过程可能无法正常工作。但是，在实践中，所有副本上的中继日志应该相对靠近。

让应用程序了解源服务器位置的一种方法是为源服务器提供一个动态DNS条目。与绑定你可以使用nsupdate动态更新DNS。