网站索引量,高端品牌衣服排行榜前十名,wordpress 前端会员中心,wordpress目录文章目录 MySQL45讲 第二十七讲 主库故障应对#xff1a;从库切换策略与 GTID 详解一、一主多从架构与主备切换的挑战#xff08;一#xff09;一主多从基本结构#xff08;二#xff09;主备切换的复杂性 二、基于位点的主备切换#xff08;一#xff09;同步位点的概念… 文章目录 MySQL45讲 第二十七讲 主库故障应对从库切换策略与 GTID 详解一、一主多从架构与主备切换的挑战一一主多从基本结构二主备切换的复杂性 二、基于位点的主备切换一同步位点的概念与获取方法二处理同步错误的方法 三、GTID 的引入与优势一GTID 的概念与组成二GTID 的生成与分配方式三基于 GTID 的主备切换逻辑四GTID 在在线 DDL 中的应用 四、总结与思考 MySQL45讲 第二十七讲 主库故障应对从库切换策略与 GTID 详解 在 MySQL 数据库架构中一主多从结构被广泛应用于应对读多写少的业务场景以提升系统的读性能。然而当主库出现故障时如何确保从库能够顺利接管并保证数据的一致性和完整性成为了至关重要的问题。今天我们将深入探讨一主多从架构下主库故障后的主备切换问题重点介绍基于位点和基于 GTIDGlobal Transaction Identifier的两种切换方式及其原理、优缺点。 一、一主多从架构与主备切换的挑战
一一主多从基本结构
如图 1 所示一主多从结构中虚线箭头表示主备关系如 A 和 A’互为主备从库 B、C、D 指向主库 A。主库负责所有写入和部分读操作从库分担其他读请求实现读写分离。 二主备切换的复杂性
当主库发生故障时如图 2 所示主备切换后 A’成为新主库从库 B、C、D 需要改接到 A’。这一过程相较于一主一备结构更为复杂因为涉及到多个从库重新指向新主库的操作而其中关键的问题是从库如何找到与新主库的同步位点。 二、基于位点的主备切换
一同步位点的概念与获取方法 概念当把节点 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_posMASTER_HOST、MASTER_PORT、MASTER_USER和MASTER_PASSWORD四个参数分别代表了主库A’的IP、端口、用户名和密码。最后两个参数MASTER_LOG_FILE和MASTER_LOG_POS表示要从主库的 master_log_name文件的master_log_pos这个位置的日志继续同步。而这个位置就是我们所 说的同步位点也就是主库对应的文件名和日志偏移量。 获取方法及不精确性 一种常见方法是等待新主库 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导致主键冲突。
二处理同步错误的方法 主动跳过事务通过执行 set global sql_slave_skip_counter 1; start slave; 命令每次遇到主键冲突1062 错误或删除数据时找不到行1032 错误等错误时停下来执行该命令跳过可能重复的事务直到不再出现错误。设置 slave_skip_errors 参数将 slave_skip_errors 设置为 “1032,1062”直接跳过指定错误。但这种方法仅适用于主备切换时因找不到精确同步位点而创建主备关系的情况且在主备同步关系稳定后需将该参数设置为空以免掩盖后续真正的数据不一致问题。 三、GTID 的引入与优势
一GTID 的概念与组成
GTIDGlobal Transaction Identifier是事务在提交时生成的全局唯一标识由 server_uuid实例第一次启动时自动生成的全局唯一值和 gno初始值为 1每次提交事务时递增组成格式为 GTID server_uuid:gno。它在 MySQL 5.6 版本引入用于解决主备切换中找同步位点的难题。
二GTID 的生成与分配方式
默认生成方式gtid_next automaticMySQL 会将 server_uuid:gno 分配给事务。记录 binlog 时先记录一行 SET SESSION.GTID_NEXT ‘server_uuid:gno’并将该 GTID 加入本实例的 GTID 集合。指定 GTID 值gtid_next 为指定值若 gtid_next 指定为一个已存在于实例 GTID 集合中的 GTID如 current_gtid则接下来执行的事务会被系统忽略若不存在则将该 current_gtid 分配给事务事务提交后若要执行下一个事务需再次设置 gtid_next。
三基于 GTID 的主备切换逻辑
语法与优势在 GTID 模式下备库 B 设置为新主库 A’的从库语法为 CHANGE MASTER TO… master_auto_position 1无需指定 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数。切换流程 实例 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 等场景中也有很好的应用。
