CoderPath

GTID 复制、故障切换与扩展边界 ​

← 本站索引 ｜ 9.x 升级支线 ｜ 练习答案

可运行检查 SQL ​

sql
SELECT @@server_uuid, @@server_id, @@gtid_mode,
       @@enforce_gtid_consistency, @@log_bin, @@binlog_format;

SHOW BINARY LOG STATUS;
SHOW REPLICA STATUS;

SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_worker;

配置副本时使用 8.4 的 SOURCE/REPLICA 术语；以下语句需替换实验地址与账户：

sql
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'source.example',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'replicator',
  SOURCE_PASSWORD = 'load-from-secret-store',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

机制解释 ​

源库提交事务并写 binlog，副本接收后写 relay log，再由 applier 重放。GTID 标识已执行事务，使重新定位和故障切换不再依赖手工文件位置，但不会自动解决错误事务、延迟或脑裂。

读写分离带来读己之写、一致性路由和副本过载问题。高可用控制面必须实施 fencing，防止旧主仍可写。复制拓扑仍会复制误删除，因此必须保留独立备份。

真实边界 ​

  • 提升副本前确认事务集合、延迟、只读、客户端路由和旧主隔离。
  • 故障切换要记录数据缺口、RTO、恢复旧主和重新接入副本步骤。
  • 分区管理单表数据，不等于跨实例分片。
  • 分片只在单实例优化、归档、容量和业务边界仍不足时考虑，并接受跨片事务和查询成本。

练习 ​

  1. 画出 source → binlog → relay log → applier → replica 的失败点。
  2. 设计一次旧主隔离、提升副本、客户端切换和旧主重建演练。
  3. 解释为什么副本正常不证明能够恢复误删除。

验收清单 ​

  • 拓扑图标出 binlog、relay log、接收和应用线程的失败点。
  • 切换演练包含 fencing、事务集合校验、路由和旧主重建。
  • RPO/RTO 由故障演练测得，不只来自配置推断。

完成后核对答案

深度加餐：高可用不是多一台机器 ​

复制延迟、切换语义、客户端重连和数据一致性共同决定高可用；拓扑图只是起点。

先做一个可观察实验 ​

sql
SHOW MASTER STATUS;
SHOW REPLICA STATUS\G

SELECT @@gtid_mode, @@enforce_gtid_consistency,
       @@read_only, @@super_read_only;

预期：能看到源端位置、复制线程、延迟与 GTID 设置；只读副本不会被应用误写。

原理下潜与工程边界 ​

GTID 让事务以全局标识复制，故障切换时减少手工定位；半同步降低丢失窗口但增加提交延迟。读写路由要处理切换期间的旧连接与缓存。

Seconds_Behind_Source 可能为 NULL 或不代表真实业务延迟；自动切换可能重复执行非幂等写入；跨区域网络分区会让“多数派”判断复杂。

反例排错路线 ​

同时看复制错误、队列长度、心跳延迟和应用重试；演练必须验证写入、读一致性、旧主隔离和回切，而不是只看进程存活。

练习加码（仍不提供答案） ​

加码：设计单主 GTID 拓扑的故障切换 runbook，列出侦测、隔离、提升、路由、回切五阶段证据。

验收时请补充：一份可复现的环境/数据前提、正常结果、失败结果以及可回滚或清理动作。

继续查阅：MySQL 8.4 参考手册（外部资料已收录于证据账本） · InnoDB 文档（外部资料已收录于证据账本）

用心记录每一步成长

Copyright © 2026-present Twiink