mysql故障转移：如何选择slave作为新的master？答案

【问题标题】：mysql failover: how to choose slave as new master?mysql故障转移：如何选择slave作为新的master？
【发布时间】：2023-03-14 05:24:01
【问题描述】：

我是mysql新手。

当涉及到故障转移时，应该将哪个从站提升为新的主站？

比如A是master，B和C是slave，A对B和C做异步复制。

在某个时间点，B 从 A 接收的数据多于 C，A 崩溃。

如果我们将 C 提升为新的 master，并将 B 的 master 更改为 C，那么 B 会发生什么？它会截断其数据以匹配 C？

显然，B是最好的新硕士候选人，但我的问题是，如何确定这个事实？

【问题讨论】：

stackoverflow.com/questions/14116488/master-slave-configuration 属性
问题...这是一个有点棘手的问题，因为您需要先理解问题才能理解答案：您是基于 binlog 坐标还是全局事务标识符 (GTID) 进行复制？跨度>
@Michael-sqlbot 你能解释一下吗？
使用 Orchestrator 或 MHA 来“确定事实”。否则，重新发明他们的代码。
@RickJames 我想了解“如何”，而不是完成工作的工具。

标签： mysql database-replication failover

【解决方案1】：

SHOW SLAVE STATUS 中的 Relay_Master_Log_File 和 Exec_Master_Log_Pos 用于确定最佳从站作为新主站：较大的值获胜。

如果没有 GTID，我认为我们必须首先将其他从站与我们选择的最佳从站同步。明显的同步源是中继日志。在每个从站上，确定中继日志与最佳从站的差异，下载这些文件并重放 SQL 语句。一旦所有的奴隶都赶上了，奴隶就可以CHANGE MASTER TO最好的奴隶。 MASTER_LOG_FILE 和 MASTER_LOG_POS 将是最佳从属服务器上最后一个 binlog 的尾部。

使用 GTID，非常简单：只需 CHANGE MASTER TO 和 MASTER_AUTO_POSITION=1。

【讨论】：

【解决方案2】：

从MySQL documentation 开始，有两种方法可以设置主从架构。传统方式，使用日志文件复制事务，新版本（5.6+）使用 GTID（全局事务标识符）。

如果您选择使用 GTID 进行故障转移处理，您将使用 mysqlfailover 实用程序。该实用程序以数据库管理员定义的三种方式之一处理 master 失败：

auto（默认）：在首选从属列表中搜索以成为主控，如果没有可用的从属，则选择另一个从属。选择的从站首先成为所有其他从站的从站，并将其他从站的所有更改复制到它，这样新的主站将成为可能的最新版本。
elect：与上述相同，但如果列表中没有可用的从站，则返回错误并完成（无故障转移）
fail: 不发生故障转移 mysqlfailover 只会监控数据库，如果发生故障则返回错误。

传统方式需要你自己实现数据库管理脚本，更好解释here。

【讨论】：

我知道有工具（官方或非官方）可以进行自动故障转移，但我需要幕后的理论。也就是说，我需要“为什么”而不是“如何”。
你给出的官方参考并没有说明确定最新slave的方法。