MySQL 复制延迟和高可用异常先查什么：拓扑、角色与切换证据清单
用一张脱敏清单核对MySQL复制拓扑、节点角色、延迟、日志连续性、路由、近期变更和切换演练，再决定继续只读核验、集群管控评估或授权修复。
无论使用传统主从、MHA、Orchestrator、Group Replication还是InnoDB Cluster，首轮都应固定时间线、拓扑、角色、复制与路由证据；清单不执行切换、重建或跳过日志。
适用对象
- SQL-MY-08已在MySQL 8.0.46与8.4.10隔离环境验证，可形成一行脱敏复制状态聚合。
- 先记录事件时间窗、影响动作、拓扑、节点角色和复制方式，不从单个状态字段推断根因。
- 复制延迟、线程/成员异常、日志连续性和应用路由需要放在同一时间线上核对。
- “存在候选新主”不等于“可以切换”，还需核对数据差异、写入口、回退和验收责任。
- 任何切换、重建、改位点、跳过日志、修改配置或写入修复都必须单独授权。
READ AND ACT
不必读到文末，现在就可以做下一步
先下载只读工作表或完成 5 分钟自查；只有需要固定范围人工判断时，再查看数据库健康体检。
这些入口不要求提交数据库、SQL、日志或公司信息；服务范围和资料边界以目标页面说明为准。
先区分接收、应用、延迟和错误状态
单行聚合卡适合首轮回答“复制通道是否就绪、接收或应用是否停止、是否配置延迟、是否出现应用错误单元”。它不返回复制身份和位点，也不能证明唯一根因。
| 场景 | 聚合卡能说明 | 仍需补充 | 禁止直接动作 |
|---|---|---|---|
| 就绪 | 接收与应用状态均可见 | 相邻快照、业务影响与延迟趋势 | 自动切换 |
| 接收线程停止 | 接收侧停止候选 | 网络、源端、账号、证书与变更时间线 | 改复制配置 |
| 应用线程停止 | 应用侧停止候选 | 受控错误证据、冲突对象与恢复方案 | 跳日志或改位点 |
| 配置延迟 | 存在已配置延迟及剩余等待候选 | 业务策略、目标延迟和当前时间线 | 取消延迟 |
| 错误与恢复 | 出现应用错误单元及后续状态变化 | 受控错误详情、数据一致性与验收责任 | 重建或写入修复 |
复制与高可用异常要放在一张时间线上
先把拓扑、复制、路由、变更和授权证据统一到同一事件时间窗，再判断哪些事实一致、哪些仍缺失；任何单点指标都不应直接触发切换。
| 范围 | 最低证据 | 常见误判 | 需要停止的动作 |
|---|---|---|---|
| 拓扑与角色 | 脱敏节点、主/副本/路由角色与采集时间 | 把旧拓扑当当前事实 | 改角色、重建节点 |
| 复制与日志 | 方式、延迟/队列、线程/成员状态、日志连续性 | 把延迟数字直接写成根因 | 改位点、跳日志、清日志 |
| 应用路由 | VIP/DNS/Proxy/Router类型与变更时间 | 数据库切换等于应用恢复 | 改路由或连接入口 |
| 变更与反证 | 发布、运维动作、未受影响范围 | 时间相关直接写成因果 | 未核验就回滚或重放 |
| 演练与授权 | 最近演练、验收、回退与授权编号 | 有工具等于可以自动切换 | 切换、隔离、写入修复 |
从异常信号到授权动作的六步
流程先完成只读核验和方案准备，最后一步才进入逐项批准；核验冲突、回退缺失或验收责任不明时必须停止。
复制与高可用处理链
- 01
01
固定时间线
记录错误、影响动作、开始时间和未受影响范围。
- 02
02
确认拓扑
只用脱敏编号核对节点、角色、复制和路由。
- 03
03
补齐日志
核对延迟、队列、成员/线程状态和日志连续性。
- 04
04
检查变更
对照发布、运维、网络和容量变化，保留反证。
- 05
05
形成方案
明确候选动作、影响、回退、验收与责任人。
- 06
06
逐项授权
切换、重建、改位点或写入修复分别批准并回读。
没有当前拓扑、回退和验收责任时，不得自动切换。
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
复制延迟多大才算故障？
没有适用于所有业务的固定数字。需要结合持续时间、积压趋势、业务读写路径、RPO、网络、IO和最近变更判断。
发现副本更“新”就可以提升为主库吗？
不可以。还需核对日志连续性、写入口、数据差异、旧主隔离、路由、回退和业务验收。
DMP可以自动切换吗？
是否具备能力要以当前已核验制品和版本为准；即使具备，也必须在拓扑、权限、演练、回退和单独授权齐全后使用。