MySQL45讲 第二十七讲 主库故障应对：从库切换策略与 GTID 详解——阅读总结

MySQL45讲 第二十七讲 主库故障应对：从库切换策略与 GTID 详解

在 MySQL 数据库架构中，一主多从结构被广泛应用于应对读多写少的业务场景，以提升系统的读性能。然而，当主库出现故障时，如何确保从库能够顺利接管并保证数据的一致性和完整性，成为了至关重要的问题。今天，我们将深入探讨一主多从架构下主库故障后的主备切换问题，重点介绍基于位点和基于 GTID（Global Transaction Identifier）的两种切换方式及其原理、优缺点。

一、一主多从架构与主备切换的挑战

（一）一主多从基本结构

如图 1 所示，一主多从结构中，虚线箭头表示主备关系（如 A 和 A’互为主备），从库 B、C、D 指向主库 A。主库负责所有写入和部分读操作，从库分担其他读请求，实现读写分离。

（二）主备切换的复杂性

当主库发生故障时（如图 2 所示），主备切换后 A’成为新主库，从库 B、C、D 需要改接到 A’。这一过程相较于一主一备结构更为复杂，因为涉及到多个从库重新指向新主库的操作，而其中关键的问题是从库如何找到与新主库的同步位点。

二、基于位点的主备切换

（一）同步位点的概念与获取方法

1. 概念：当把节点 B 设置为节点 A’的从库时，需要通过 CHANGE MASTER 命令指定同步位点，即主库对应的文件名和日志偏移量（MASTER_LOG_FILE 和 MASTER_LOG_POS）。

   CHANGE MASTER TO
   MASTER_HOST=$host_name
   MASTER_PORT=$port
   MASTER_USER=$user_name
   MASTER_PASSWORD=$password
   MASTER_LOG_FILE=$master_log_name
   MASTER_LOG_POS=$master_log_pos
   

   • MASTER_HOST、MASTER_PORT、MASTER_USER和MASTER_PASSWORD四个参数，分别代表了主库A’的IP、端口、用户名和密码。
   • 最后两个参数MASTER_LOG_FILE和MASTER_LOG_POS表示，要从主库的 master_log_name文件的master_log_pos这个位置的日志继续同步。而这个位置就是我们所 说的同步位点，也就是主库对应的文件名和日志偏移量。

2. 获取方法及不精确性：

   • 一种常见方法是等待新主库 A’把中转日志（relay log）全部同步完成，在 A’上执行 show master status 命令获取当前最新的 File 和 Position，取原主库 A 故障时刻 T，然后用 mysqlbinlog 工具解析 A’的 File，得到 T 时刻的位点（如 end_log_pos 的值）。但此方法并不精确，例如假设在 T 时刻主库 A 插入一行数据 R 并传 binlog 给 A’和 B 后瞬间掉电，从库 B 已存在 R，新主库 A’的日志在该位点之后，此时 B 切换指向 A’的该位点，会再次同步插入 R 的 binlog，导致主键冲突。

（二）处理同步错误的方法

1. 主动跳过事务：通过执行 set global sql_slave_skip_counter = 1; start slave; 命令，每次遇到主键冲突（1062 错误）或删除数据时找不到行（1032 错误）等错误时，停下来执行该命令跳过可能重复的事务，直到不再出现错误。
2. 设置 slave_skip_errors 参数：将 slave_skip_errors 设置为 “1032,1062”，直接跳过指定错误。但这种方法仅适用于主备切换时因找不到精确同步位点而创建主备关系的情况，且在主备同步关系稳定后，需将该参数设置为空，以免掩盖后续真正的数据不一致问题。

三、GTID 的引入与优势

（一）GTID 的概念与组成

GTID（Global Transaction Identifier）是事务在提交时生成的全局唯一标识，由 server_uuid（实例第一次启动时自动生成的全局唯一值）和 gno（初始值为 1，每次提交事务时递增）组成，格式为 GTID = server_uuid:gno。它在 MySQL 5.6 版本引入，用于解决主备切换中找同步位点的难题。

（二）GTID 的生成与分配方式

1. 默认生成方式（gtid_next = automatic）：MySQL 会将 server_uuid:gno 分配给事务。记录 binlog 时，先记录一行 SET @@SESSION.GTID_NEXT = ‘server_uuid:gno’，并将该 GTID 加入本实例的 GTID 集合。
2. 指定 GTID 值（gtid_next 为指定值）：若 gtid_next 指定为一个已存在于实例 GTID 集合中的 GTID（如 current_gtid），则接下来执行的事务会被系统忽略；若不存在，则将该 current_gtid 分配给事务，事务提交后，若要执行下一个事务，需再次设置 gtid_next。

（三）基于 GTID 的主备切换逻辑

1. 语法与优势：在 GTID 模式下，备库 B 设置为新主库 A’的从库语法为 CHANGE MASTER TO… master_auto_position = 1，无需指定 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数。
2. 切换流程：
   • 实例 B 指定主库 A’建立连接，将自己的 GTID 集合 set_b 发给 A’。
   • A’算出 set_a 与 set_b 的差集，判断本地是否包含差集所需的所有 binlog 事务，若不包含则返回错误；若包含，从自己的 binlog 文件中找出第一个不在 set_b 的事务发给 B，之后按顺序取 binlog 发给 B 执行。

（四）GTID 在在线 DDL 中的应用

以之前提到的在线加索引为例，在双 M 结构且开启 GTID 模式下，可在实例 X（主库）上执行 stop slave，在实例 Y（备库）上执行 DDL 语句（无需关闭 binlog），查出 DDL 语句对应的 GTID，然后在实例 X 上执行一系列语句（如 set GTID_NEXT = “server_uuid_of_Y:gno”; begin; commit; set gtid_next = automatic; start slave;），既保证了实例 Y 的更新有 binlog 记录，又确保实例 X 不会重复执行该更新。

四、总结与思考

在一主多从架构下，主库故障后的主备切换涉及到同步位点的确定和处理同步错误等复杂问题。基于位点的切换方法存在不精确性，而 GTID 的引入为解决这些问题提供了更简洁、可靠的方案。在 GTID 模式下，主备切换更加方便，系统能自动完成位点查找工作，且在在线 DDL 等场景中也有很好的应用。