06 复制高可用与备份恢复

本分册回答一个生产问题：当支付写入、库存预占和履约轨迹都不能丢时，如何让 MySQL（关系型数据库）既能扩读、又能在故障后明确“谁有写权限、数据能恢复到哪里、多久能恢复”。

1. 简历关联点与面试主线

WMS（仓储管理系统）库存预占的写路径必须以权威库为准；支付单创建、回调入账和退款对账要求写后可读、可追溯；跨境履约轨迹允许短暂最终一致，却不能倒退覆盖。复制解决副本传播，不自动解决业务幂等、切主授权、误操作恢复或对账。面试中应先声明一致性目标，再讲复制确认边界、读路由、故障切换、备份和演练闭环。

flowchart LR
  A[支付/库存/履约写请求] --> B[Source 源库]
  B --> C[binlog 二进制日志]
  C --> D[Dump Thread 二进制日志发送线程]
  D --> E[Receiver Thread 接收线程]
  E --> F[Relay Log 中继日志]
  F --> G[Applier Thread 应用线程]
  G --> H[Replica 副本库]
  H --> I[只读查询/备份/灾备]

图中提交成功的第一判定仍在 Source（源库）本地；副本链路只说明日志随后是否被接收和应用。异步复制下，C 到 H 的时间窗口就是潜在数据丢失窗口，不能把“有副本”误说成“已经双机持久化”。

2. 复制与恢复的结论先行

1. binlog（二进制日志）是复制与时间点恢复的逻辑事实来源；Relay（中继） Log（日志）是副本本地的接收队列；它们都不是备份的同义词。
2. position（位点）复制依赖文件名和偏移量，GTID（全局事务标识）复制依赖已执行事务集合；二者都必须与一致的初始数据集配套。
3. 半同步复制只把确认边界推进到“至少一个副本确认收到日志”，默认并不等于已经执行、提交或能被读到。
4. 读写分离默认会出现陈旧读。支付写后查询、库存裁决和切换窗口必须设计会话一致性、主库回读或位点/GTID（全局事务标识）等待。
5. 切主的核心不是“把流量指向新库”，而是隔离旧主写入、选定数据事实、重新建立复制并验证写入唯一性。fencing（栅栏）要落在真正能拒绝旧主写入的位置。
6. 备份有效的定义是：在隔离环境、限定 RPO（恢复点目标）/RTO（恢复时间目标）内，恢复出可启动、可校验、可接流量的数据；有备份文件不等于可恢复。

3. 基础概念与底层原理

3.1 复制链路：binlog（二进制日志） dump（转储）、I/O（输入输出）与应用线程

Source（源库，旧称 Master（主库））提交事务时写入 binlog（二进制日志）。副本连接后，源端的 Dump（转储） Thread（线程）即二进制日志发送线程，常被口头称为 binlog（二进制日志） dump（转储））按请求的位点或 GTID（全局事务标识）发送事件；副本 Receiver（接收） Thread（线程），5.7 状态中常见 I/O（输入输出） Thread（线程）名称）写入 Relay（中继） Log（日志）；SQL（结构化查询语言） Thread（线程），8.0 语境更常称 Applier（应用） Thread（线程））再重放事务。接收和应用解耦，所以“已收到”不等于“已执行”。

sequenceDiagram
  participant App as 应用
  participant S as Source 源库
  participant D as Dump Thread 发送线程
  participant R as Receiver Thread 接收线程
  participant L as Relay Log 中继日志
  participant A as Applier Thread 应用线程
  App->>S: 提交库存预占 T42
  S->>S: 写 binlog 二进制日志
  D->>R: 发送 T42 事件
  R->>L: 顺序落 Relay Log 中继日志
  A->>L: 读取并应用 T42
  A->>A: 更新已执行位点/GTID 集合

数据演绎 1：接收领先应用。 输入：mysql-bin.003 的 1200 至 1800 字节是支付 P9001；副本已接收至 1800，应用仅到 1200。步骤：Receiver（接收） Thread（线程）已将事件写入 Relay（中继） Log（日志），但 Applier（应用） Thread（线程）因大事务被阻塞。输出：副本查询仍查不到 P9001。失败分支：若路由将“支付成功页”打到该副本，用户看到未支付；结论：接收位点不是可读承诺。

热门面试题

1. 问题：为什么复制要把接收与应用拆成两段？
   • 考点：网络解耦、削峰与延迟边界。
   • 回答思路：先分职责，再说队列积压的可观测性。
   • 详细答案：Receiver（接收） Thread（线程）把网络抖动与源端读取隔离到 Relay（中继） Log（日志），Applier（应用） Thread（线程）按事务边界重放，因此副本可先持续接收再慢慢执行。代价是两段进度不同，必须同时监控接收和应用，不能只看一个延迟秒数。
   • 进阶追问：Relay（中继） Log（日志）很多是否等于网络慢？
   • 进阶回答：不等于；也可能是应用端锁等待、大事务、磁盘慢、并行度不足或副本资源被报表占用。
2. 问题：binlog（二进制日志） dump（转储） 是什么？
   • 考点：源端发送线程职责。
   • 回答思路：说明它读源端日志、按副本请求推送。
   • 详细答案：binlog（二进制日志） dump（转储） 通常指 Source（源库）的 Dump（转储） Thread（线程），即二进制日志发送线程）。它不是把数据库文件复制过去，而是读取 binlog（二进制日志）事件并经复制连接发给副本。
   • 进阶追问：它阻塞会影响业务提交吗？
   • 进阶回答：提交的主要持久化路径不等待普通异步发送；但日志保留、网络和连接资源仍会影响复制可用性与故障窗口。
3. 问题：库存副本已收到日志却查不到新库存，先查什么？
   • 考点：接收/应用进度分离。
   • 回答思路：核对读取实例、Relay（中继） Log（日志）和应用阻塞。
   • 详细答案：先确认请求确实落到目标副本，再比较已接收和已执行的位点或 GTID（全局事务标识），随后查看 Applier（应用） Thread（线程）错误、锁等待、大事务和资源饱和。
   • 进阶追问：能直接跳过错误继续吗？
   • 进阶回答：不能把跳过当修复；必须先还原事件语义、评估数据差异，再用受控补偿和校验闭环。

3.2 position 与 GTID：复制进度的两种坐标

position（位点）以 binlog（二进制日志）文件名加字节偏移作为坐标，例如 mysql-bin.003:1800。它直观但依赖具体文件，初始化、日志清理、拓扑变更都要谨慎对齐。GTID（全局事务标识）为每个已提交事务分配“源服务器 UUID（通用唯一标识）+递增事务号”，副本通过已执行集合决定缺哪些事务，切换和自动定位更自然，但前提是所有节点的 GTID（全局事务标识）纪律、日志保留和禁止项一致。

flowchart TD
  A[事务 T: UUID:501] --> B[Source 写 GTID 事件]
  B --> C{Replica 已执行集合含 T?}
  C -- 否 --> D[接收并应用 T]
  C -- 是 --> E[跳过重复事务]
  D --> F[更新 Executed GTID Set]
  E --> F

数据演绎 2：位点初始化错误。 输入：备份在 mysql-bin.010:400 一致完成，却把副本起点误设为 520。步骤：401 至 520 的订单状态变更未被重放。输出：副本少了一笔履约状态。失败分支：若切主到该副本，缺口变成权威事实。结论：位点不是“看起来接近即可”，必须来自同一一致性点。

热门面试题

1. 问题：GTID（全局事务标识）为什么便于切主？
   • 考点：事务集合与自动定位。
   • 回答思路：比较“缺什么事务”而非手工找文件偏移。
   • 详细答案：GTID（全局事务标识）把复制进度表达为集合，候选新主和其他副本可以据此补齐缺失事务并避免重复执行，减少人工位点计算；但集合相同也不替代业务数据校验。
   • 进阶追问：GTID（全局事务标识）能防止所有数据不一致吗？
   • 进阶回答：不能。错误 SQL（结构化查询语言）、跳过事件、外部副作用和错误初始数据集仍可能造成语义差异。
2. 问题：position（位点）复制何时最危险？
   • 考点：备份点和日志保留。
   • 回答思路：指出偏移必须绑定同一快照。
   • 详细答案：重建副本、切换和日志被清理时最危险。若数据快照与文件/偏移不对应，就会漏事务或重复事务，问题通常在切主或对账后才暴露。
   • 进阶追问：重复执行一定报错吗？
   • 进阶回答：不一定。无唯一约束的写入可能静默重复，故还需幂等键、约束和校验。
3. 问题：支付库切换前怎样选择候选副本？
   • 考点：GTID（全局事务标识）集合、延迟和一致性。
   • 回答思路：先围栏旧主，再比较候选进度。
   • 详细答案：先停止旧主写权限并保留证据，再比较候选的已执行集合、复制错误、校验结果和承载能力；不能只选择 Seconds_Behind_Source（落后源库秒数）最小的节点。
   • 进阶追问：候选都有差异怎么办？
   • 进阶回答：按已确认事务、业务账本和风险窗口裁定权威集合，必要时暂停写入并走对账补偿。

3.3 异步、半同步与组复制的确认边界

异步复制的应用只等 Source（源库）本地提交，副本可能尚未收到日志；半同步复制在超时策略允许的前提下，等待至少一个半同步副本确认已接收日志，缩小源库单点故障的丢失窗口，但默认确认通常停在接收/落盘边界，不能宣传为“副本已执行”。Group Replication（组复制）通过组通信和一致性协议处理成员资格与提交协调；InnoDB（事务存储引擎） Cluster（集群）在其上组合 MySQL（关系型数据库） Router（路由器）等组件。它们降低部分编排工作，不替代应用幂等、备份和业务对账。

| 方案 | 客户端成功的最小确认 | 主要故障窗口 | 适用边界 | | --- | --- | --- | | 异步复制 | Source（源库）本地提交 | 源库宕机且日志未到副本 | 读扩展、可容忍少量 RPO（恢复点目标） | | 半同步复制 | 源库提交加至少一副本接收确认 | 接收后未应用、超时退化为异步 | 支付等希望收窄丢失窗口的单主拓扑 | | Group Replication（组复制） | 组协议规定的提交/认证过程 | 网络分区、流控、运维与语义复杂度 | 需要成员管理和更强自动化的团队 | | InnoDB（事务存储引擎） Cluster（集群） | 由组复制与路由组件共同定义 | 路由、版本和运维边界 | 接受完整组件栈与演练成本的场景 |

sequenceDiagram
  participant A as 支付应用
  participant S as Source 源库
  participant R as 半同步副本
  A->>S: 提交入账
  S->>S: 本地持久化与写 binlog
  S->>R: 发送 binlog 事件
  R-->>S: 收到日志确认
  S-->>A: 返回成功
  Note over R: 后续才由 Applier Thread 应用

数据演绎 3：半同步并非读后立见。 输入：支付 P7 在 10:00:00 收到副本确认，副本应用队列积压 20 秒。步骤：源库向客户端返回成功，副本随后才应用。输出：10:00:05 副本仍可能查不到 P7。失败分支：写后读若直打副本，页面误导用户重试；结论：半同步缩小丢失窗口，不提供会话读一致性。

热门面试题

1. 问题：半同步复制解决了什么，没解决什么？
   • 考点：确认边界。
   • 回答思路：明确“至少收到”与“已经应用”的区别。
   • 详细答案：半同步复制让源库在返回成功前等待副本确认接收日志，从而减少源库单点故障丢失已确认事务的概率；它不保证副本已经执行，也不保证网络分区时永不退化。
   • 进阶追问：半同步超时后会怎样？
   • 进阶回答：具体行为受配置和版本影响，常见风险是退化为异步；必须监控退化次数、确认副本数和业务 RPO（恢复点目标）。
2. 问题：Group Replication（组复制）能否替代备份？
   • 考点：高可用与误操作恢复分工。
   • 回答思路：指出错误会被一致传播。
   • 详细答案：不能。误删、错误更新和应用逻辑缺陷可能被复制到所有成员；备份和 PITR（时间点恢复）仍用于回到错误发生前。
   • 进阶追问：为什么多副本仍要演练恢复？
   • 进阶回答：因为副本证明可用性，恢复演练证明数据、工具、权限、速度和校验链真实可用。
3. 问题：库存系统必须上组复制吗？
   • 考点：需求与复杂度权衡。
   • 回答思路：先算写一致性、故障窗口和团队能力。
   • 详细答案：不必。单主半同步复制加严格切主、库存条件更新、幂等与对账可能更匹配；组复制的收益必须覆盖其网络、流控、路由和演练复杂度。
   • 进阶追问：如何证明选择正确？
   • 进阶回答：用故障注入验证 RPO（恢复点目标）/RTO（恢复时间目标）、写后读、切换重试和库存守恒，而非只看压测吞吐。

3.4 并行复制、依赖关系与大事务

单个 SQL（结构化查询语言） Thread（线程）顺序应用时，副本吞吐常落后源端。并行复制把可并发的事务交给多个 Applier（应用） Thread（线程），但提交可见性仍要遵守源端的提交顺序或依赖关系。MySQL（关系型数据库）5.7 与 8.0 的并行复制配置、依赖跟踪与默认策略不同；面试答案应说“按实际小版本验证”，不要把某一参数名写成所有版本通用。大事务、热点行、DDL（数据定义语言）、外键和跨事务依赖都会削弱并行度。

flowchart TD
  A[Relay Log 中继日志事务组] --> B{可并行且无依赖?}
  B -- 是 --> C1[Worker 1 应用订单]
  B -- 是 --> C2[Worker 2 应用轨迹]
  B -- 否 --> D[串行等待热点库存事务]
  C1 --> E[按提交顺序协调提交]
  C2 --> E
  D --> E

数据演绎 4：线程多但不快。 输入：一分钟内 10000 笔履约轨迹和 2000 笔都更新同一 SKU-1 库存行的事务。步骤：轨迹可并行，库存条件更新互相等待。输出：把工作线程从 4 提到 32，库存部分仍近似串行。失败分支：继续加线程只增加上下文和锁竞争；结论：先拆热点、缩短事务、按业务分流。

热门面试题

1. 问题：并行复制为什么还要保持提交顺序？
   • 考点：副本可见性与源端语义。
   • 回答思路：区分执行并行和提交可见性。
   • 详细答案：可独立事务可以并行执行，但副本向外暴露提交结果需要满足复制协议的顺序约束，否则读者可能观察到与源端不兼容的状态组合。
   • 进阶追问：并行度由什么决定？
   • 进阶回答：由事务依赖、热点、提交组、工作线程、存储与版本实现共同决定，不是单一参数。
2. 问题：复制延迟先扩机器还是拆大事务？
   • 考点：瓶颈定位。
   • 回答思路：先分接收与应用，再看事务形态。
   • 详细答案：若应用端被单个大事务、锁或热点限制，先拆批、缩短事务和修正访问路径；扩机器不能让一个逻辑串行事务并行。
   • 进阶追问：大事务为何影响恢复？
   • 进阶回答：重放时间长、Relay（中继） Log（日志）占用大，失败重试和切换追赶窗口都扩大。
3. 问题：履约轨迹适合怎样降低复制压力？
   • 考点：数据模型与写入解耦。
   • 回答思路：区分不可变事件和当前状态。
   • 详细答案：轨迹事件按唯一事件号追加并批量落库，当前状态用有序版本条件更新；读模型可异步构建，避免所有更新争抢同一订单摘要行。
   • 进阶追问：乱序轨迹怎么处理？
   • 进阶回答：以渠道序号或事件时间加版本规则拒绝倒退，并保留原始事件供补偿与审计。

3.5 复制延迟、延迟副本与主从不一致

复制延迟至少分为“源端已提交到副本已接收”和“副本已接收到已应用”两段。Seconds_Behind_Source（落后源库秒数）受时间戳、线程状态和实现限制影响，不能单独作为准确 RPO（恢复点目标）或业务陈旧度。延迟副本故意延后应用，可为误删提供缓冲，但它仍依赖源日志留存、未被错误操作污染的备份以及切换策略。主从不一致可能来自错误初始化、跳过事务、非确定性语句、未复制对象、人工写副本或应用侧双写。

| 不一致来源 | 表现 | 证据 | 正确处置 | | --- | --- | --- | | 跳过复制错误 | 位点继续但数据缺行/错行 | 错误日志、跳过记录、校验差异 | 找回原事务或重建副本，不能只掩盖 | | 人工写副本 | 单表差异 | 审计与账号记录 | 立刻收回写权限，重建或修复后校验 | | 非确定性语句 | 同语句结果不同 | binlog（二进制日志）格式、函数与环境 | 采用确定性写法或 ROW（行）格式 | | 初始快照不一致 | 长期少/多数据 | 基线校验 | 从一致备份重新搭建 |

flowchart LR
  A[源库提交] --> B[接收位点]
  B --> C[应用位点]
  C --> D[副本可读]
  E[大事务/锁/磁盘慢] -.阻塞.-> C
  F[跳过错误/人工写] -.制造差异.-> D

数据演绎 5：延迟副本不是免死金牌。 输入：延迟副本配置为 30 分钟，10:00 误删订单，10:20 运维发现，源库 binlog（二进制日志）保留仅 15 分钟。步骤：延迟副本虽尚未应用删除，但其所需上游日志已经被清理。输出：它可能无法继续形成可靠副本。失败分支：若误把它直接提升为主，后续复制链路和数据裁定失控；结论：延迟副本、日志保留与备份要一起设计。

热门面试题

1. 问题：为什么不能只看延迟秒数？
   • 考点：进度指标边界。
   • 回答思路：分接收、应用和业务可读。
   • 详细答案：秒数指标可能为空、失真或不表达具体事务缺口。应同时看接收/执行位点或 GTID（全局事务标识）集合、Relay（中继） Log（日志）增长、应用错误和关键业务样本。
   • 进阶追问：如何定义业务陈旧读？
   • 进阶回答：用写入事务标识或版本号与读取副本已执行进度比较，按订单、支付或库存场景设阈值。
2. 问题：发现副本有数据差异能跳过错误吗？
   • 考点：复制错误治理。
   • 回答思路：先止损和取证，再恢复事实。
   • 详细答案：不能默认跳过。先冻结副本读流量和人工写入口，保全错误事件、位点、行校验和业务流水，再选择补事务、重建或受控修复。
   • 进阶追问：何时必须重建副本？
   • 进阶回答：差异范围不可证明、初始基线错误、跳过历史不可追溯或多表语义不一致时，应从可信一致备份重建。
3. 问题：延迟副本适合恢复支付误删吗？
   • 考点：恢复工具边界。
   • 回答思路：说明它是缓冲，不是唯一恢复路径。
   • 详细答案：可作为发现窗口内的辅助证据，但支付还要以账务流水、对账文件和备份加 PITR（时间点恢复）为主，避免直接把延迟副本提升为权威写库。
   • 进阶追问：为什么不能直接导回误删表？
   • 进阶回答：跨表状态、外部回调和后续更新可能已发生，必须按业务主键、状态机和金额守恒受控回放。

3.6 读写分离、陈旧读与会话一致性

读写分离把写和强一致读路由到 Source（源库），把可容忍陈旧的列表、报表和轨迹查询路由到 Replica（副本库）。陈旧读不是“数据库坏了”，而是副本尚未应用所需事务。会话一致性要求同一用户在一次写成功后，后续关键读至少看到该写；可通过主库粘滞窗口、主库回读、携带 GTID（全局事务标识）/位点并等待副本追平、或返回写入结果避免立即再读实现。库存扣减裁决、支付状态和退款结果不得仅靠普通副本读决定。

sequenceDiagram
  participant U as 用户
  participant W as 写服务
  participant S as Source 源库
  participant P as 读代理
  participant R as Replica 副本库
  U->>W: 创建支付单
  W->>S: 写入并获得 GTID
  S-->>W: 成功 + GTID
  W-->>U: 返回受理结果
  U->>P: 立即查询
  P->>R: 等待已执行 GTID
  alt 超时未追平
    P->>S: 主库回读
  else 已追平
    P->>R: 副本读取
  end

数据演绎 6：支付写后读。 输入：用户提交支付单 P100，源库返回 GTID（全局事务标识）uuid:900，副本仅执行到 uuid:899。步骤：读代理等待 uuid:900 200 毫秒，仍未追平。输出：代理回源库读取并返回“处理中”。失败分支：若直接读副本，用户再次支付；结论：把一致性需求放进路由协议，不靠前端刷新碰运气。

热门面试题

1. 问题：读写分离如何保证写后读？
   • 考点：会话一致性。
   • 回答思路：写返回进度令牌，读端按令牌路由。
   • 详细答案：写成功后保存 GTID（全局事务标识）或版本号；关键读先等待目标副本达到该进度，超时则回源库或返回明确的处理中状态，不能静默读旧数据。
   • 进阶追问：一直粘主会怎样？
   • 进阶回答：一致性更强但主库读压增加，应仅用于短窗口和关键会话，并有容量监控。
2. 问题：库存展示读到旧值会导致超卖吗？
   • 考点：读模型与写裁决分离。
   • 回答思路：展示可以旧，扣减必须权威。
   • 详细答案：展示旧值本身不必然超卖；超卖发生在预占时依据旧值直接判定成功。正确做法是在源库用带 available >= qty 条件的更新和影响行数裁决。
   • 进阶追问：缓存怎样配合？
   • 进阶回答：缓存仅服务展示，扣减结果以数据库事务和库存流水为准，并用失效/消息更新缓存。
3. 问题：履约轨迹为何可容忍副本陈旧？
   • 考点：业务一致性分级。
   • 回答思路：说明它不做不可逆资金或库存裁决。
   • 详细答案：轨迹是进度展示，允许数秒陈旧但必须防止状态倒退；用事件序号、最后更新时间和补偿同步让它最终收敛。
   • 进阶追问：什么时候必须回主？
   • 进阶回答：用户刚触发关键履约动作、投诉核验或异常人工处理需要权威状态时，应回主或读权威事件源。

3.7 切主、脑裂、fencing 与代理编排边界

切主包含故障判断、隔离旧主、选择新主、提升、重建拓扑、恢复路由和数据校验。网络分区时旧主可能仍接受写，新主也被提升，便形成脑裂。fencing（栅栏）不是一句“把旧主设只读”：必须通过网络隔离、存储挂载控制、云实例关机、数据库账号/权限和代理写路由等多层手段，让旧主即使活着也不能再造成可提交业务写。代理负责连接发现和流量切换，编排器负责健康判断与状态推进；两者都不能替代业务层幂等键、唯一约束和状态机。

flowchart TD
  A[监控怀疑旧主故障] --> B{能确认旧主被隔离?}
  B -- 否 --> C[暂停写/降级，继续确认]
  B -- 是 --> D[比较候选进度与错误]
  D --> E[提升候选为新主]
  E --> F[代理仅将写流量切到新主]
  F --> G[重建旧主为副本并校验]
  C --> H[避免双主写入]

数据演绎 7：脑裂重复扣款。 输入：机房网络隔离，旧主仍可被部分支付服务访问，编排器在另一侧提升副本。步骤：同一幂等键 PAY-88 在旧主和新主分别写入；网络恢复后两边日志集合分叉。输出：仅靠复制无法安全合并。失败分支：若没有唯一键和渠道流水约束，可能双扣；结论：先围栏，再切路由，应用仍须幂等和对账。

热门面试题

1. 问题：为什么只读开关不够防脑裂？
   • 考点：旧主仍可写的路径。
   • 回答思路：指出权限、既有连接和网络分区。
   • 详细答案：只读配置可能未覆盖拥有高权限的连接、既有会话或绕过代理的直连；且配置传播本身受网络影响。必须以可验证的隔离和多层写权限收敛实现 fencing（栅栏）。
   • 进阶追问：fencing（栅栏）令牌适用于数据库吗？
   • 进阶回答：可在应用写入协议中携带单调递增任期并由权威侧拒绝旧任期，但它补强业务写，不能替代数据库节点隔离。
2. 问题：代理与编排器如何分工？
   • 考点：控制面和数据面边界。
   • 回答思路：代理快路由，编排器慢决策。
   • 详细答案：代理负责实时连接和读写路由，编排器负责健康判定、选主和拓扑修复；切换必须有共享的权威状态与审计，避免两个系统各自判断。
   • 进阶追问：代理健康检查成功就能放写吗？
   • 进阶回答：不能。健康仅说明可连，不证明该节点已被授权为唯一写主且数据满足切换策略。
3. 问题：切主后为什么还要做数据校验？
   • 考点：RPO（恢复点目标）与语义差异。
   • 回答思路：比较日志集合和业务守恒。
   • 详细答案：切换可能丢失最后窗口事务、出现未完成回放或应用侧重试；除 GTID（全局事务标识）/位点外，还要核验支付金额守恒、库存流水和订单状态。
   • 进阶追问：发现差异先补数据还是开放写？
   • 进阶回答：按业务风险决定，资金和库存裁决优先限制写或降级，保留证据后按幂等补偿与对账收敛。

3.8 全量、增量、逻辑、物理与热备一致性点

逻辑备份导出 SQL（结构化查询语言）或逻辑对象，跨版本和选择性恢复较灵活，但大库恢复慢；物理备份复制数据页、日志和元数据，恢复快却更依赖版本、文件布局和工具兼容性。全量备份提供基线，增量备份记录基线之后的变化以缩短备份窗口；快照若不能保证存储与数据库一致性，可能得到无法恢复的撕裂状态。热备的关键是得到一致性点：物理热备通常要协调 InnoDB（事务存储引擎）页和日志，逻辑一致性导出要控制事务视图与非事务表边界；无论何种方式，都要记录可用于 PITR（时间点恢复）的 binlog（二进制日志）坐标或 GTID（全局事务标识）集合。

| 类型 | 优势 | 主要限制 | 适合用途 | | --- | --- | --- | | 逻辑全量备份 | 可读、可选择对象、跨环境灵活 | 导入慢、对大库资源压力大 | 小中库、表级恢复、迁移核验 | | 物理全量热备 | 恢复快、保留页级结构 | 工具/版本/权限要求高 | 大库基线和灾备 | | 增量物理备份 | 缩短备份窗口与存储 | 恢复链更长、更依赖顺序 | 高频 RPO（恢复点目标）要求 | | 存储快照 | 创建快 | 一致性与跨卷原子性需证明 | 经数据库协调后的补充手段 |

flowchart LR
  A[一致物理全量备份] --> B[记录 GTID/位点]
  B --> C[持续归档 binlog]
  C --> D[隔离恢复环境]
  D --> E[还原备份]
  E --> F[重放至目标时间前]
  F --> G[校验并受控切流]

数据演绎 8：热备一致性点。 输入：10:00 开始物理热备，备份工具在 10:08 记录 uuid:1-5000 与对应 binlog（二进制日志）坐标。步骤：数据页来自不同刷盘时刻，恢复时依靠备份包含的必要日志收敛到一致点。输出：10:08 基线可用于继续重放。失败分支：若只复制数据目录且未协调日志，可能无法启动或逻辑不一致；结论：热备不是简单拷贝目录。

热门面试题

1. 问题：逻辑备份和物理备份怎么选？
   • 考点：恢复速度与灵活性。
   • 回答思路：从数据量、RTO（恢复时间目标）和表级需求判断。
   • 详细答案：大库、严格 RTO（恢复时间目标）优先物理备份作为基线；需要表级回捞、跨环境核验或迁移时补逻辑备份。生产通常组合使用，而非二选一。
   • 进阶追问：逻辑备份是否天然一致？
   • 进阶回答：不天然；要看导出事务快照、锁策略、非事务表和导出期间 DDL（数据定义语言）变化。
2. 问题：增量备份为何不一定让恢复更快？
   • 考点：恢复链成本。
   • 回答思路：备份快与恢复快分开讨论。
   • 详细答案：增量减少单次备份量，却要求按全量加多个增量顺序合并；链条越长，恢复编排、校验和失败重试越复杂。
   • 进阶追问：如何控制链条风险？
   • 进阶回答：限制增量层数、定期重新做全量、记录校验和，并在演练中测真实恢复时间。
3. 问题：为什么存储快照不能直接当数据库备份？
   • 考点：一致性点。
   • 回答思路：说明跨卷与写入中的页面。
   • 详细答案：快照只保证存储层某种时间视图，未必协调数据库数据页、日志和多个卷的顺序；必须证明其与数据库恢复协议兼容。
   • 进阶追问：怎样让快照更可靠？
   • 进阶回答：通过数据库/备份工具协调冻结或日志点、原子快照和恢复演练证明，而非仅检查快照任务成功。

3.9 PITR、误操作恢复与恢复隔离

PITR（时间点恢复）的通用闭环是：先还原一个可信全量/物理基线，再按 binlog（二进制日志）或 GTID（全局事务标识）重放到误操作前的精确位置，最后从隔离环境提取需要回补的业务数据。不要直接把恢复实例覆盖生产：误删后的合法新订单、渠道回调和外部副作用可能已发生。目标时间须以事务边界、业务时间线和日志事件共同裁定；对支付要以账务流水与渠道记录为事实锚点，对库存要以预占/释放流水和订单状态核验。

sequenceDiagram
  participant O as 生产源库
  participant B as 备份基线
  participant X as 隔离恢复实例
  participant V as 业务校验
  O->>B: 定期全量/物理备份
  O->>O: 误删发生
  B->>X: 还原基线
  O->>X: 重放 binlog 至误删前
  X->>V: 导出待回补记录
  V->>O: 幂等、受控回补

数据演绎 9：订单表误删 PITR（时间点恢复）。 输入：02:00 全量备份，11:03:12 误删 order_id=7001，11:05 才发现。步骤：在隔离实例恢复 02:00 基线，重放至 11:03:11.999，提取订单、支付关联和库存流水。输出：按状态机判断哪些记录可回补。失败分支：直接把隔离实例提升会丢掉 11:03 后其他用户合法订单；结论：PITR（时间点恢复）常用于取数与对比，不等于整库回滚。

热门面试题

1. 问题：PITR（时间点恢复）为什么必须依赖 binlog（二进制日志）保留？
   • 考点：基线后的变化记录。
   • 回答思路：全量只覆盖过去，日志补齐之后。
   • 详细答案：备份只恢复到备份时刻；要回到更晚且早于误操作的时刻，必须有连续、可读、未被清理的 binlog（二进制日志）或等价归档。
   • 进阶追问：GTID（全局事务标识）能替代日志内容吗？
   • 进阶回答：不能。GTID（全局事务标识）标识事务身份和集合，真正重放仍需对应日志事件。
2. 问题：为什么不直接把恢复库切成生产？
   • 考点：事故后合法写入。
   • 回答思路：恢复时点与当前业务并存。
   • 详细答案：恢复库停在过去，直接切换会抹掉事故后大量正常订单、支付回调和履约更新；应在隔离环境提取差异并受控合并。
   • 进阶追问：整库勒索或全盘损坏怎么办？
   • 进阶回答：此时可能必须整库灾备切换，但仍要按 RPO（恢复点目标）声明损失窗口、冻结外部副作用并做对账补偿。
3. 问题：误删恢复怎么避免二次伤害？
   • 考点：隔离、幂等和校验。
   • 回答思路：先只读验证，再小批回补。
   • 详细答案：恢复库与生产隔离，回补使用主键、版本、状态前驱和幂等键限制覆盖范围；先灰度少量记录，再全量校验。
   • 进阶追问：回补失败可以重跑吗？
   • 进阶回答：脚本必须可重入并记录批次、输入和结果；不能用一次性无审计 SQL（结构化查询语言）。

3.10 恢复演练、RPO 与 RTO：有备份不等于可恢复

RPO（恢复点目标）回答“最多容忍丢多久的数据”，RTO（恢复时间目标）回答“多久恢复服务”。二者都不是备份任务的成功标志，而是业务承诺。恢复演练至少验证：备份可读、密钥与权限可用、版本兼容、实例可启动、日志链连续、恢复耗时达标、关键表/金额/库存校验通过、切流和回滚预案可执行。只有对象存储里有一个“备份成功”标签，无法证明恢复链中的任一环节能工作，因此有备份不等于可恢复。

flowchart TD
  A[宣布演练与冻结目标] --> B[准备隔离环境]
  B --> C[恢复全量/物理基线]
  C --> D[重放日志到目标点]
  D --> E[技术校验: 启动/复制/校验和]
  E --> F[业务校验: 金额/库存/履约]
  F --> G{RPO/RTO 达标?}
  G -- 是 --> H[记录证据与改进项]
  G -- 否 --> I[修复流程后复演]

数据演绎 10：RTO（恢复时间目标）失约。 输入：承诺 RTO（恢复时间目标）30 分钟，演练中下载备份 12 分钟、还原 35 分钟、日志重放 20 分钟。步骤：总耗时 67 分钟，即使数据正确也已违反目标。输出：备份任务“成功”不改变 RTO（恢复时间目标）失败事实。失败分支：真实故障才发现网速、磁盘和权限不足；结论：用实测分解时间并调整架构或承诺。

热门面试题

1. 问题：RPO（恢复点目标）与 RTO（恢复时间目标）如何影响方案？
   • 考点：业务目标反推技术。
   • 回答思路：RPO（恢复点目标）决定日志/副本策略，RTO（恢复时间目标）决定恢复链。
   • 详细答案：更小 RPO（恢复点目标）要求更短备份间隔、连续日志归档或更强复制确认；更小 RTO（恢复时间目标）要求更快物理基线、预置环境和演练自动化，二者都增加成本。
   • 进阶追问：支付与轨迹能用同一目标吗？
   • 进阶回答：不宜机械统一。支付资金通常更严，轨迹展示可容忍更长陈旧和恢复窗口，需按业务分级。
2. 问题：怎样证明备份可恢复？
   • 考点：演练证据。
   • 回答思路：从文件完整到业务正确逐层证明。
   • 详细答案：定期在隔离环境完成还原、PITR（时间点恢复）、启动、校验和、关键业务守恒和耗时记录，并保留命令、日志、版本和负责人证据。
   • 进阶追问：只做抽样校验够吗？
   • 进阶回答：抽样适合快速发现问题，但资金、库存等核心表还需总量守恒、关键索引和跨表关系校验。
3. 问题：恢复演练是否会影响生产？
   • 考点：隔离与资源治理。
   • 回答思路：说明备份读取和演练资源隔离。
   • 详细答案：应使用隔离计算、网络、账号和目标实例，控制从生产读取备份的带宽与时间；演练计划要有变更窗口和中止条件。
   • 进阶追问：演练失败要不要对外报告？
   • 进阶回答：至少向风险责任人和技术管理者透明报告，形成修复项和复演日期；隐瞒失败会把风险留到事故时。

3.11 MySQL（关系型数据库）5.7、8.0、8.4 的迁移与验证边界

复制与备份最容易因“版本名相同但行为不同”产生事故。MySQL（关系型数据库）5.7 存量环境要尤其核对旧术语、复制状态字段、并行复制配置、默认字符集和工具版本；8.0 适合作为主学习基线，但具体 Clone（克隆）、复制管理语法与并行行为仍需查小版本；8.4 是 LTS（长期支持）演进基线，升级前要核验废弃参数、认证、备份工具、监控解析和代理兼容。任何跨版本复制、恢复或切换都要先在同等数据量的隔离环境验证。

flowchart LR
  A[版本升级设计] --> B[隔离全量恢复]
  B --> C[建立复制与压测]
  C --> D[故障切换/回切演练]
  D --> E[核验备份与 PITR]
  E --> F[灰度生产变更]

热门面试题

1. 问题：为什么版本边界要精确到小版本？
   • 考点：参数和行为演进。
   • 回答思路：配置、命令和实现都可能变化。
   • 详细答案：复制并行、管理命令、备份工具和废弃参数可能在小版本演进；把“8.0 支持”写成统一结论会让升级脚本和故障操作失效。
   • 进阶追问：面试时不记得小版本怎么办？
   • 进阶回答：明确说需以目标小版本官方手册和预发演练核验，给出验证路径而不是编造绝对参数。
2. 问题：跨版本复制最先验证什么？
   • 考点：可恢复性与回滚。
   • 回答思路：从备份恢复、复制、应用回归到故障演练。
   • 详细答案：先验证物理/逻辑备份能恢复，再建立复制验证日志与 DDL（数据定义语言），随后压测读写、切换和回切；没有回滚路径不进入生产。
   • 进阶追问：能先升级副本再升级主库吗？
   • 进阶回答：必须遵循目标版本官方支持矩阵和升级路径，不能只依据经验倒推；先做隔离验证。
3. 问题：如何避免监控在升级后误报？
   • 考点：状态字段与脚本兼容。
   • 回答思路：把监控当作依赖一起演练。
   • 详细答案：升级前清点复制状态解析、备份脚本、代理健康检查和告警阈值，在预发执行同一套任务并比对字段语义。
   • 进阶追问：监控绿灯能证明升级安全吗？
   • 进阶回答：不能；还要通过写后读、切换、恢复和业务守恒验证真实失败路径。

4. 线上排查与实战 SOP（标准操作流程）

5. 项目落地话术

我会把数据库高可用分成三件事：第一，支付、库存等权威写只走 Source（源库），副本用于可降级读；写后查询用会话粘滞、主库回读或 GTID（全局事务标识）等待，避免用户因陈旧读重复操作。第二，切主前先做 fencing（栅栏）隔离旧主，再由编排器选择进度和校验都合格的候选，代理只在授权后切流；应用继续依赖幂等键、状态机和对账，不能把数据库切换当作重复写保护。第三，恢复上采用物理全量基线加连续 binlog（二进制日志）归档，按 RPO（恢复点目标）/RTO（恢复时间目标）定期在隔离环境做 PITR（时间点恢复）演练。对 WMS（仓储管理系统）我校验库存流水守恒；对支付我校验账务金额、渠道流水与订单状态；对履约我校验事件序号和状态不倒退。这样高可用不是“有从库”，而是可证明的故障闭环。

6. 图表索引与数据演绎索引

本分册包含 12 张 Mermaid（图表语法）图：复制链路、复制时序、GTID（全局事务标识）去重、半同步确认、并行应用、延迟分段、写后读、切主围栏、备份链路、PITR（时间点恢复）、恢复演练和版本升级验证。包含 10 组数据演绎，分别覆盖接收/应用脱节、位点错配、半同步、并行热点、延迟副本、写后读、脑裂、热备一致性点、误删恢复和 RTO（恢复时间目标）失约。

非知识型题库过渡

这一节不新增复制机制结论。你先用前面知识小节完成判断，再在题库中训练“确认边界、日志位点、故障边界、证据、恢复与验证”的连续表达；所有场景均为教学演绎，不把未验证的项目数据包装成事实。

1. 问题（综合题）：请完整解释 MySQL（关系型数据库）主从复制从提交到副本可读的链路。

   • 口述答案：我会先界定“提交成功”和“副本可读”是两个边界。业务在 Source（源库，旧称 Master（主库））提交时，事务先按本地持久化协议完成，并写入 binlog（二进制日志）；普通异步复制到这里就可能向应用返回成功。随后源端的 Dump（转储） Thread（线程），即二进制日志发送线程）按副本请求的 position（位点）或 GTID（全局事务标识）读取日志事件并发送。Replica（副本库，旧称 Slave（从库））的 Receiver（接收） Thread（线程），旧状态中常叫 I/O（输入输出） Thread（线程））先把事件落入 Relay（中继） Log（日志），这解决网络接收与执行解耦，却也引入队列。最后 SQL（结构化查询语言） Thread（线程）或 Applier（应用） Thread（线程）按事务边界重放，并推进已执行位点或 GTID（全局事务标识）集合，事务才可能被该。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：收到 Relay（中继） Log（日志）后能否认为不会丢？直接答案：不能；它只证明该副本本地收到事件，仍要考虑副本磁盘、应用失败、整体故障和切换裁定。
   • 追问 2：为什么复制不是备份？直接答案：误删和错误更新会被复制，备份加 PITR（时间点恢复）才能回到错误前。
   • 追问 3：详见复制链路。

2. 问题（综合题）：position（位点）复制与 GTID（全局事务标识）复制如何选择和切换？

   • 口述答案：position（位点）复制把进度记为 binlog（二进制日志）文件与字节偏移，优点是概念直观、存量 MySQL（关系型数据库）5.7 环境常见，缺点是初始化数据集必须严格对应同一个文件和偏移，日志滚动、清理和拓扑变更都增加人工风险。GTID（全局事务标识）复制把每个提交事务表达为服务器 UUID（通用唯一标识）和事务序号，副本维护已执行集合，切主时可先比较集合、补齐缺失事务，再让其他副本自动定位，因而更适合可演进拓扑。我的选择不是“GTID（全局事务标识）一定更安全”，而是先确认版本、全链路参数、日志保留、备份工具与历史数据是否满足 GTID（全局事务标识）纪律。两种方式都必须从一致备份点起步：快照若对应 binlog（二进制日志）位置 400，却配置成 520，。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：GTID（全局事务标识）会自动修复数据差异吗？直接答案：不会；它防重复与标识缺失事务，不修复错误业务语义。
   • 追问 2：位点错了能否只跳过报错？直接答案：不应；应回到可信一致基线重建或受控补偿，并做校验。
   • 追问 3：详见位点与 GTID。

3. 问题（综合题）：异步复制与半同步复制的确认边界和数据丢失窗口是什么？

   • 口述答案：异步复制的确认边界在 Source（源库）本地事务提交，应用拿到成功时，副本可能还没收到 binlog（二进制日志），所以若源库立刻不可恢复，最后一段已确认写可能丢失。半同步复制把确认边界向后推进：源库通常等待至少一个半同步 Replica（副本库）确认接收日志后再返回成功，从而缩小“已确认但其他节点无日志”的窗口。关键是不能把它说成副本已执行或已提供读服务：确认通常发生在 Receiver（接收） Thread（线程）接收/落盘路径，Applier（应用） Thread（线程）可能仍因锁等待、大事务或资源不足而落后。半同步还受超时、可用确认副本数和版本/配置影响，在异常下可能退化为异步；因此必须监控退化、确认等待和副本健康。支付入账这类业务可使用半同步以降低主机单点丢失。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：半同步超时后一定拒绝写吗？直接答案：不一定，行为取决于版本和配置；必须将退化策略纳入业务风险评估。
   • 追问 2：半同步可替代备份吗？直接答案：不可，逻辑误操作会被同步传播。
   • 追问 3：详见复制模式。

4. 问题（综合题）：如何解释并行复制没有把所有延迟问题都解决？

   • 口述答案：并行复制解决的是副本应用阶段中“彼此独立事务被单线程顺序重放”的吞吐限制。它会把无依赖的事务分派给多个 Applier（应用） Thread（线程），再按复制语义协调提交，因此订单轨迹追加、不同用户订单更新通常有机会并行。但它不能突破真实依赖：同一库存行的条件扣减、同一账户余额更新、长事务、DDL（数据定义语言）、外键检查和热点索引页都会形成等待；即使把工作线程从 4 调到 32，热点事务仍近似串行，并会增加调度和资源竞争。排障要先区分接收滞后还是应用滞后，再查看 Relay（中继） Log（日志）增长、事务大小、锁等待、工作线程忙闲、磁盘 I/O（输入输出）和源端提交组。对于 WMS（仓储管理系统），不能靠并行复制掩盖单 SKU（库存单位）热点，应按仓库或货。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：加线程前先看什么？直接答案：先看大事务、锁等待、热点和 I/O（输入输出）瓶颈，确认有可并行工作。
   • 追问 2：并行复制能改变源端事务顺序吗？直接答案：不能任意改变对外可见的复制语义，执行并行仍受提交协调约束。
   • 追问 3：详见并行复制。

5. 问题（综合题）：副本延迟时，你如何定位并治理，而不是只盯延迟秒数？

   • 口述答案：我先把延迟拆成两段：源端提交到副本接收，以及副本接收到应用完成。Seconds_Behind_Source（落后源库秒数）只能做告警线索，受线程状态、时间戳和实现影响，不能等同于精确事务缺口或业务陈旧度。第一步确认读流量是否受影响，对支付写后查询和库存裁决立即回 Source（源库），对履约展示则标识更新时间并设陈旧阈值。第二步比较源端日志、接收位点、执行位点或 GTID（全局事务标识）集合，判断是网络/发送问题还是应用问题。若是应用落后，继续查 Relay（中继） Log（日志）积压速度、错误日志、大事务、锁等待、DDL（数据定义语言）、磁盘 I/O（输入输出）和 CPU（中央处理器）资源；若是热点依赖，拆事务和数据模型比盲目加线程更有效。第三步严禁无证据跳过复制错。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：延迟副本能直接接读流量吗？直接答案：通常不适合，它故意陈旧，只应承担恢复缓冲或特定查询。
   • 追问 2：复制报错是否可跳过？直接答案：先定位事件语义和影响，受控修复或重建，不能以跳过换绿灯。
   • 追问 3：详见延迟与不一致。

6. 问题（综合题）：怎样为支付写后读设计会话一致性？

   • 口述答案：支付的核心风险不是“页面慢”，而是用户刚创建支付单或收到渠道回调后读到副本旧值，把处理中误判为失败并重复支付。因此我把写和关键读协议化：支付写入只进入 Source（源库），成功响应携带订单版本或 GTID（全局事务标识）；同一会话的关键查询优先主库粘滞短窗口，或由读代理等待目标 Replica（副本库）已执行该 GTID（全局事务标识），超时则主库回读，仍无法确认就返回明确的处理中状态并引导轮询权威接口。普通账单列表、历史履约轨迹可读副本，但要显示更新时间和陈旧阈值。绝不能把“半同步复制已确认”当作写后读保证，因为副本收到日志并不意味着 Applier（应用） Thread（线程）已执行。应用侧还需用 Idempotency Key（幂等键）、渠道交易号唯一约束、状态。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：主库粘滞越长越好吗？直接答案：不是；它提高主库读负载，应只覆盖关键短窗口。
   • 追问 2：库存展示能复制这套吗？直接答案：展示可降级读副本，真正扣减必须用源库条件更新裁决。
   • 追问 3：详见读写分离。

7. 问题（综合题）：如何设计一次安全的 MySQL（关系型数据库）切主，防止脑裂？

   • 口述答案：切主不是健康检查失败后立即改一个地址，而是先确立唯一写权。发现旧主不可达时，先判断是节点故障还是网络分区；若无法证明旧主被隔离，就宁可暂停高风险写并降级，也不能提升副本。确认后实施 fencing（栅栏）：通过网络隔离、云主机关机或存储围栏、数据库账号权限和代理写路由多层阻断旧主，让它即使仍运行也无法产生被当作权威的写。随后比较候选副本的 GTID（全局事务标识）集合或 position（位点）、复制错误、关键表校验和容量，选择满足策略的节点提升；代理只在编排器记录授权后把写流量切到新主。应用必须继续带幂等键和状态机，因为切换期间的超时重试可能让同一请求重复到达。旧主恢复后不能直接接回流量，应作为待处置节点，通过重建复制。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：只设置 read_only（只读）能围栏吗？直接答案：不够，高权限会话、直连和网络分区都可能绕过或延迟生效。
   • 追问 2：候选副本都落后怎么办？直接答案：按 RPO（恢复点目标）和业务账本裁定，必要时限制写并做补偿，不可盲目选最快节点。
   • 追问 3：详见切主与脑裂。

8. 问题（综合题）：代理、编排器、fencing（栅栏）和应用幂等的职责边界是什么？

   • 口述答案：我会把这四层明确分开，避免把“自动切换”夸大成一致性保证。代理处于数据面，职责是按已授权拓扑做连接、读写路由、摘除和会话策略；它看见节点可连，不代表该节点拥有唯一写权或数据完整。编排器处于控制面，负责健康判定、候选选择、提升、重建复制和状态审计，但它的判断可能被网络分区误导，因此必须配合 fencing（栅栏）。fencing（栅栏）的职责是从网络、主机、存储、账号和写入口真正拒绝旧主继续影响权威数据，重点是“旧主活着也写不进去”，而不只是设置一个标志。应用层承担请求幂等、唯一约束、状态机、补偿和对账：同一支付回调或库存预占在切换前后重试时，数据库角色变化不能替它判断是否已完成。边界清楚后，故障流程就可审计：编排。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：代理的健康检查为何不足以授权写？直接答案：可连只说明网络和进程，不说明任期、围栏和数据进度。
   • 追问 2：fencing（栅栏）后还需幂等吗？直接答案：需要，超时与重复投递即使没有脑裂也会发生。
   • 追问 3：详见职责边界。

9. 问题（综合题）：逻辑备份、物理备份、全量、增量和快照分别怎样选？

   • 口述答案：这些维度不能混在一起。逻辑备份按对象导出 SQL（结构化查询语言）或逻辑行，优点是可读、易选择表级数据和跨环境迁移，缺点是大库导出导入慢、资源消耗高；物理备份保存数据页、日志和元数据，通常恢复更快，更适合作为大库灾备基线，但依赖版本、文件布局、工具和权限兼容。全量备份提供一个完整起点；增量备份只记录基线后的变化，减少单次窗口和存储，却拉长恢复链，必须按顺序合并并校验。存储快照创建很快，但不天然等于数据库一致备份，必须证明数据页、日志和多卷快照与 InnoDB（事务存储引擎）恢复协议协调。我的常见组合是物理全量基线加连续 binlog（二进制日志）归档满足 RTO（恢复时间目标）与 PITR（时间点恢复），再为关键表准备逻辑导出以。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
   • 追问 1：增量越多越省吗？直接答案：备份时更省，但恢复链更长、故障点更多，必须限制层数。
   • 追问 2：快照能否直接复制数据目录？直接答案：需先证明数据库一致性和跨卷原子性，否则可能得到不可启动状态。
   • 追问 3：详见备份类型。

10. 问题（综合题）：什么是热备一致性点，为什么“拷贝数据目录”不可靠？

• 口述答案：热备期间数据库仍在写，数据页、索引页和日志页在不同时间刷盘；如果只是任意时刻复制目录，可能拿到相互不匹配的数据页和日志，恢复时既无法启动，也可能产生不可证明的逻辑状态。热备一致性点的含义是：备份工具或数据库协调数据文件与必要日志，使恢复过程能把这些不同物理时刻的页收敛到一个确定事务边界，并记录对应 binlog（二进制日志）坐标或 GTID（全局事务标识）集合。物理热备通常依赖 InnoDB（事务存储引擎）恢复能力和工具协议；逻辑一致性导出则依赖事务快照、锁策略以及对非事务表和 DDL（数据定义语言）变更的约束。对业务而言，一致性点不是只写在备份元数据里的数字，而是 PITR（时间点恢复）和副本重建的起点：从该点之后的连续 binlog（二进制日志）。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：备份完成时记录什么最关键？直接答案：一致性坐标、GTID（全局事务标识）集合或位点、工具/版本、校验和和日志保留信息。
• 追问 2：逻辑导出是否不需要一致性点？直接答案：仍需要，尤其要处理快照、非事务表和导出期间 DDL（数据定义语言）。
• 追问 3：详见热备一致性点。

11. 问题（综合题）：请描述一次订单误删后的 PITR（时间点恢复）方案。

• 口述答案：误删后第一原则是停止扩大影响而不是立刻在生产执行反向 SQL（结构化查询语言）。我先固定事故时间线：谁、在哪个库、哪张表、什么条件执行，精确到可能的事务边界，并保全审计、binlog（二进制日志）、当前业务写入和备份清单。然后在隔离环境还原最近可信全量或物理基线，按连续 binlog（二进制日志）重放到误删事务之前，必要时结合 GTID（全局事务标识）和事件内容校对停止点。恢复实例只用于取证和产生候选回补集，不能直接覆盖生产，因为误删后已经有其他用户的合法订单、支付回调和履约更新。回补时按订单主键、状态前驱、版本号和 Idempotency Key（幂等键）做小批、可重入的合并；支付关联需用渠道交易、账务分录和金额守恒复核，库存关联需检查预占/。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：为什么不能直接把恢复实例切主？直接答案：它停在过去，会丢失误删后正常写入。
• 追问 2：停止点怎么选？直接答案：结合日志事务边界、审计和业务时间线，不能只按发现时间估计。
• 追问 3：详见PITR。

12. 问题（综合题）：为什么有备份不等于可恢复？如何设计恢复演练？

• 口述答案：备份文件存在只验证了生成环节，恢复还依赖对象存储可读、网络带宽、密钥、权限、工具版本、数据库版本、磁盘容量、日志连续性和人工操作；其中任一环失败，事故时都无法达成恢复目标。尤其是大库，下载、解密、解压、准备、还原、日志重放和业务校验的总时长可能远超承诺的 RTO（恢复时间目标）。因此恢复演练必须在隔离环境按真实流程完成：选择一个明确的恢复点，恢复全量/物理基线，验证实例启动，再做 PITR（时间点恢复）到指定事务前，检查关键表、索引、复制重建和应用读写，最后计算从宣布到可服务的实测时间。技术校验至少包括日志、校验和、权限和监控；业务校验至少包括支付金额守恒、库存可用量与流水守恒、履约状态和事件序号。演练结。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：演练多久做一次？直接答案：按业务等级和变更频率设周期，重大版本/工具变更后必须追加演练。
• 追问 2：只恢复能启动是否足够？直接答案：不够，还要验证业务守恒、关键查询和实际 RTO（恢复时间目标）。
• 追问 3：详见恢复演练。

13. 问题（综合题）：支付资金一致性在复制、切换和恢复场景下怎样保证？

• 口述答案：支付资金一致性不能依赖“数据库复制没有延迟”这一条假设，而要把数据库可靠性放入完整账务协议。写入路径中，支付单、渠道交易号、账务分录和状态变更在 Source（源库）以唯一约束、状态前驱和金额校验完成；客户端超时或回调重投时，Idempotency Key（幂等键）和渠道流水保证不会重复入账。读路径中，刚提交后的支付状态使用主库回读、会话粘滞或 GTID（全局事务标识）等待，不能读到 Replica（副本库）陈旧状态后再次发起扣款。切换时先 fencing（栅栏）旧主，再以 GTID（全局事务标识）集合、复制错误和账务守恒选择候选，切换窗口的请求可以受理为处理中并延迟最终展示，绝不因为读不到就重放扣款。恢复时不把 PITR（时间点恢复）实例直接覆盖生产，而是以渠。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：半同步能保证资金绝不丢吗？直接答案：不能，它只缩小节点故障丢失窗口，外部渠道与业务语义仍需对账。
• 追问 2：切换期间支付请求怎么处理？直接答案：用幂等受理、明确处理中和主动查单，避免盲目重复扣款。
• 追问 3：详见写后读。

14. 问题（综合题）：WMS（仓储管理系统）库存防超卖如何处理副本陈旧与切主？

• 口述答案：库存防超卖的关键判定不能放在读副本，因为副本陈旧可能让展示库存和真实可用量不同。正确做法是把库存预占放在 Source（源库），以 available >= quantity 的条件更新、受影响行数、库存流水和业务幂等键共同裁决；副本和缓存只承担商品页、报表或近实时看板。用户刚下单后若要展示结果，可回主或携带写入版本/GTID（全局事务标识）等待副本追平，但不能把副本旧值作为再次预占依据。切主时最怕脑裂导致两个主库各自扣减，因此先做 fencing（栅栏）隔离旧主，再选择进度合格的新主，代理只把写流量切给唯一授权节点；应用重试仍依据预占单号和唯一约束保证同一请求最多生效一次。若存在最后窗口未复制事务，必须通过订单、预占流水、支付状态和仓库操作记录裁。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：库存展示为零但主库仍有货怎么办？直接答案：可按陈旧阈值回源刷新，但不能让展示异常改变写入裁决。
• 追问 2：切换后库存差异怎么补？直接答案：用预占/释放流水和订单状态重算，避免直接手改余额。
• 追问 3：详见切主边界。

15. 问题（综合题）：履约轨迹为何能用副本读，但仍要防状态倒退？

• 口述答案：履约轨迹与资金、库存不同，它主要是用户和运营的进度展示，通常可以容忍几秒到数分钟的最终一致，所以可把查询压力放在 Replica（副本库）或异步读模型上。但“允许陈旧”不等于“允许错误”：渠道事件可能乱序、重复到达或因切换重放，若简单按到达顺序更新订单当前状态，晚到的旧事件会把“已签收”改回“运输中”。我的做法是保留不可变原始 Tracking Event（轨迹事件），以渠道事件 ID（事件标识）做唯一去重，以渠道序号、业务版本或可比较时间规则更新当前状态；副本读时返回事件时间和最后同步时间。关键人工处理、投诉举证或刚触发的面单操作则回 Source（源库）或权威事件表，不依赖可能落后的副本。复制延迟扩大时，读代理可降级到主库、限制高频。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：轨迹事件为什么要保留原文？直接答案：用于审计、乱序重算和第三方争议处理，当前状态不能覆盖事实。
• 追问 2：副本延迟时是否必须回主？直接答案：按场景，展示可提示陈旧；关键操作和人工裁定应读权威源。
• 追问 3：详见会话一致性。

16. 问题（综合题）：大事务如何同时伤害复制、切换和恢复？

• 口述答案：大事务的伤害贯穿整个链路。源端一次生成大量 binlog（二进制日志）事件，会占用日志和网络；副本 Receiver（接收） Thread（线程）即使持续接收，Applier（应用） Thread（线程）仍可能长时间执行该事务，期间并行复制难以把事务内部任意拆开，Relay（中继） Log（日志）继续增长，关键读副本陈旧度扩大。切换时，候选副本若正在重放或缺少这段大事务，追赶时间不可预测；贸然提升可能扩大 RPO（恢复点目标）窗口。恢复时，大事务又会拉长日志重放时间，直接侵蚀 RTO（恢复时间目标），并让误操作的精确停止点和回补范围更难判断。治理不能只调大线程或缓存，而要回到业务写模型：批处理按可验证边界分批提交；导入、归档和 Runner（执行器）任务限速并记录检查点；库存和支付核。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：能否把一个大事务拆成任意小事务？直接答案：不能，需保留业务原子边界；跨批用状态机、检查点和补偿。
• 追问 2：大事务遇到复制错误如何处理？直接答案：先保全日志和影响范围，不能跳过；常需受控重建或补偿。
• 追问 3：详见并行复制。

17. 问题（综合题）：如何给一个新系统制定数据库 RPO（恢复点目标）和 RTO（恢复时间目标）？

• 口述答案：我不会先问“多久备份一次”，而是先按业务事实分级。支付入账、余额和库存预占若丢失会导致资金或库存账实不符，RPO（恢复点目标）通常要更小，并要求连续 binlog（二进制日志）归档、合适的复制确认、幂等与对账；履约轨迹展示、报表和历史搜索可容忍更大的 RPO（恢复点目标）与陈旧窗口。RTO（恢复时间目标）则从事故影响反推：要在 30 分钟恢复，就把下载、解密、准备、物理还原、日志重放、校验、扩容和切流逐段测量，任一阶段超时都要修改技术方案或业务承诺。方案可能是物理全量基线加连续日志、跨可用区副本、预置恢复计算资源和自动化脚本；但成本、复杂度和演练频率随目标变严。还要明确“恢复服务”是只读可查、可继续下单，还是对账完成后的。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：RPO（恢复点目标）为零是否等于零成本？直接答案：不是，接近零会显著提高同步确认、跨域和运维成本。
• 追问 2：RTO（恢复时间目标）只算数据库启动吗？直接答案：不只，必须包含可验证地恢复关键业务服务。
• 追问 3：详见RPO/RTO。

18. 问题（综合题）：复制拓扑中如何处理报表、备份与业务读相互争抢？

• 口述答案：复制副本不是无限资源池，把报表、备份、分析和关键业务读同时压在同一副本，常导致磁盘 I/O（输入输出）、Buffer Pool（缓冲池）和锁资源争抢，最终 Applier（应用） Thread（线程）落后，业务读又出现陈旧。我的做法是先分级：支付写后查询和库存裁决不走普通副本；履约展示和常规列表可以走业务读副本；重报表、离线导出和备份尽量用专用副本或隔离资源，并限制并发、设置超时和流量窗口。备份副本也要监控自身复制健康，不能因备份压力长期落后到无法重建；如果从副本做备份，必须明确备份时点、已执行 GTID（全局事务标识）和上游日志保留。对于 Runner（执行器）批任务，采用检查点、限速和分片，避免一个查询或大导出拖垮所有副本。观察指标包括接收/执行差。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：能在延迟副本做备份吗？直接答案：可作为特定恢复策略的一部分，但要清楚其时间点和日志链，不能混同最新基线。
• 追问 2：报表副本延迟会影响主库吗？直接答案：可能通过资源、日志保留和运维操作间接影响，应隔离并监控。
• 追问 3：详见延迟治理。

19. 问题（综合题）：跨 MySQL（关系型数据库）5.7、8.0、8.4 升级时，复制和备份如何控风险？

• 口述答案：版本升级的风险在于复制、备份、认证、参数和监控脚本会一起变化，不能因为数据库能启动就判断完成。MySQL（关系型数据库）5.7 存量系统常使用 Master（主库）/Slave（从库）旧术语、旧状态字段和旧参数；迁到 8.0 时要核对 GTID（全局事务标识）、日志格式、字符集、账号认证、备份工具、应用驱动和 DDL（数据定义语言）行为。8.4 作为 LTS（长期支持）演进基线仍需审查废弃配置、代理健康检查、监控解析和自动化恢复脚本。我的流程是先在隔离环境从真实备份恢复，按官方支持路径建立跨版本复制或升级链，压测业务读写和大事务，再演练切主、回切、备份恢复与 PITR（时间点恢复）；只有数据校验、业务守恒和 RPO（恢复点目标）/RTO（恢复时间目标）都通过，才灰度进。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：可否先升级副本再升级源库？直接答案：须严格按官方支持矩阵和验证结果，不能凭经验一概而论。
• 追问 2：升级成功后为什么还做 PITR（时间点恢复）？直接答案：它验证备份工具、日志与恢复链没有被版本变化破坏。
• 追问 3：详见版本边界。

20. 问题（综合题）：复制不一致发生后，如何决定补数据、重建副本还是业务补偿？

• 口述答案：发现不一致后首先停止把问题扩大：摘除有风险副本的关键读流量，禁止人工继续写副本，保全复制错误、binlog（二进制日志）、GTID（全局事务标识）集合、表校验和和业务流水。然后判断差异性质。若只是明确的一笔幂等事件未应用，且能从源端日志或权威流水重放，可用受控脚本补事务并记录前后校验；若初始快照错配、历史跳过事件不可追溯、多个表关联损坏或差异范围不可信，应从可信一致备份重建副本，避免在错误基线上“缝补”。对于支付和库存，即使技术层数据可补，也要做业务补偿：支付以渠道交易和账务分录裁定，必要时冲正或人工处理；库存以预占、释放、发货和盘点流水重算，不能直接把主表数值改成看起来正确。修复后比较 GTID（全局事务标识）。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：何时可以直接补一条 SQL（结构化查询语言）？直接答案：仅在影响和语义可证明、脚本可审计可回滚并完成校验时。
• 追问 2：重建副本会丢业务吗？直接答案：不会直接改源库，但要确认重建期间读流量和恢复窗口有替代方案。
• 追问 3：详见不一致治理。

21. 问题（综合题）：如何设计一次不影响生产的恢复演练，并让结果可信？

• 口述答案：可信演练的前提是环境和目标隔离：使用独立账号、网络、计算和存储，避免恢复实例误连生产，也限制从生产读取备份时的带宽冲击。开始前明确演练数据规模、目标恢复时间、目标事务点和业务校验规则，并冻结演练所需备份、binlog（二进制日志）、密钥和工具版本。执行中完整模拟真实链路：下载或挂载备份、校验完整性、还原物理或逻辑基线、启动 MySQL（关系型数据库）、执行 PITR（时间点恢复）到目标事务前、创建必要账号和应用配置，再由自动检查与人工抽样验证。支付校验借贷分录、订单金额和渠道流水差异；库存校验可用量、预占/释放流水和负数约束；履约校验事件总量、序号连续和状态单调。时间统计从故障宣告开始，到关键服务可安全接受流量结束，。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：可以用脱敏小数据演练吗？直接答案：可做流程烟囱，但还需等量级演练验证真实 RTO（恢复时间目标）。
• 追问 2：演练是否需要模拟应用流量？直接答案：关键场景需要，至少验证读写、校验与切流后行为。
• 追问 3：详见恢复演练。

22. 问题（综合题）：如何回答“线上页面看到旧数据，是 MVCC（多版本并发控制）还是复制延迟”？

• 口述答案：两者表象相似，但证据与处理完全不同。MVCC（多版本并发控制）发生在同一 MySQL（关系型数据库）实例和事务内：重点看隔离级别、事务开始时间、Read View（读视图）创建时机、是否在长事务中复用快照；此时源库最新已提交值存在，但当前会话为了保证一致视图仍读旧版本。复制延迟发生在不同节点：重点看请求路由到哪个 Replica（副本库）、该节点已接收/已执行位点或 GTID（全局事务标识）集合、Relay（中继） Log（日志）积压和 Applier（应用） Thread（线程）状态；此时副本尚未执行所需事务。排查时我先用连接标识确认实例，再记录写入事务 ID（标识）或 GTID（全局事务标识），在源库和副本分别查询；若是 MVCC（多版本并发控制），通过结束不合理长事务、调整读类型或回到。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：如何快速确认请求在哪个实例？直接答案：记录连接、主机、路由日志和实例标识，不能凭域名猜测。
• 追问 2：Read View（读视图）旧值能靠刷新副本解决吗？直接答案：不能，它是事务可见性问题，应检查事务边界。
• 追问 3：详见读写分离。

23. 问题（综合题）：请给出“误删 + 副本延迟 + 切主失败”的事故处置优先级。

• 口述答案：这种组合事故最危险的地方在于多个“看似修复”的动作会互相覆盖事实，所以我先停止扩大：冻结误删脚本和高风险写，禁止把延迟副本提升为主，限制代理切换，保全源库/副本状态、binlog（二进制日志）、GTID（全局事务标识）集合、备份点和业务时间线。第二步处理写权：如果切主失败且旧主状态不明，先做 fencing（栅栏）或暂停关键写，不能让两个节点继续接受支付和库存请求。第三步区分恢复与可用性：选择已知最完整且已围栏的权威节点承接最低限度写，读服务对关键路径回主；误删恢复在隔离环境进行，不直接从延迟副本或恢复库覆盖生产。第四步通过备份加 PITR（时间点恢复）构建误删前视图，结合渠道账务、库存流水和订单状态生成可重入回补；同时评估。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：延迟副本能否作为误删恢复源？直接答案：可作辅助证据，但须验证其日志链与数据状态，不能直接提升。
• 追问 2：什么时候允许恢复写流量？直接答案：唯一写权已确认、关键数据风险受控且重试幂等策略生效后。
• 追问 3：详见PITR 与切主。

24. 问题（综合题）：请给出复制高可用与备份恢复的三分钟面试总结。

• 口述答案：我的总结先从边界开始：复制解决日志传播和读扩展，高可用解决故障时唯一写权与服务切换，备份恢复解决误操作、逻辑损坏和跨节点灾难，三者必须组合但不能互相替代。复制链路是 Source（源库）提交写 binlog（二进制日志），Dump（转储） Thread（线程），即二进制日志发送线程）发送，Replica（副本库）的 Receiver（接收） Thread（线程）写 Relay（中继） Log（日志），Applier（应用） Thread（线程）重放；接收和应用进度分离，所以异步复制有已确认写丢失窗口，半同步只把确认推进到至少一个副本收到日志，通常不保证已应用。读写分离必须按业务分级：库存裁决和支付写后读用主库回读、会话粘滞或 GTID（全局事务标识）等待，履约展示可容忍陈旧但要展示更新时间和防止状态倒退。切主先 fencing（栅栏。工程上不能只依据单一状态或监控绿灯下结论，而要同时保存日志进度、路由记录、错误日志、变更时间线和关键业务样本；支付以渠道流水、账务分录与金额守恒收口，库存以预占、释放和可用量守恒收口，履约以事件序号、状态单调和最后同步时间收口。处理期间先限制会继续放大差异的流量和人工操作，再在隔离环境复现、校验并按幂等规则回补；恢复后还要把阈值、权限、容量与演练证据纳入监控和复盘，避免同类故障只被临时掩盖。
• 追问 1：最常见的错误认知是什么？直接答案：把副本、半同步或备份成功误当作数据可恢复和业务一致。
• 追问 2：最重要的验证是什么？直接答案：围栏切换与隔离 PITR（时间点恢复）演练，并以业务守恒收口。
• 追问 3：详见全章复习。

—>

7. 高频面试题与追问

1. 问题（综合题）：请完整解释 MySQL（关系型数据库）主从复制从提交到副本可读的链路。
   • 口述答案：我先区分提交、接收、应用和可读四个状态。支付或库存事务在 Source（源库）完成本地提交并写入 binlog（二进制日志）后，异步模式就可能向应用返回成功；Dump（转储） Thread（线程），即二进制日志发送线程）再按 position（位点）或 GTID（全局事务标识）把事件送给 Replica（副本库）。副本的 Receiver（接收） Thread（线程）写入 Relay（中继） Log（日志），Applier（应用） Thread（线程）按事务边界重放并推进已执行集合，查询只有命中已应用的数据才可能看到新值。因此“副本已连通”“已收到日志”都不是写后读承诺。支付回调、库存预占这类关键读应回源库、做短时会话粘滞，或等待目标副本执行指定 GTID（全局事务标识）；履约列表才可以接受带更新时间的陈旧读。

故障时我会先保全源端 binlog（二进制日志）坐标、接收位点、执行位点、路由日志和线程错误，再判断缺口在网络发送还是应用重放。若应用被大事务或锁等待阻塞，先摘除关键读并限制继续堆积的批任务，而不是把“收到”误报为完成。恢复验证要用一笔带唯一业务号的样本，确认它在源库、Relay（中继） Log（日志）、副本表和读路由日志中的顺序一致；支付还核对渠道流水与账务分录，库存核对预占、释放和可用量守恒。这样证明的是端到端可读，不是单一复制状态。

最后还要把提交时间、发送时间、应用时间和页面读到时间放入同一条追踪链，遇到缺项就先按不可信处理；这能把“副本可读”从口头判断变成可复查的时间证据。

补充验收看端到端时序而非线程单点。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

2. 问题（综合题）：position（位点）复制与 GTID（全局事务标识）复制如何选择和切换？
   • 口述答案：position（位点）用 binlog（二进制日志）文件名和偏移量描述进度，直观但必须与同一时刻生成的一致备份绑定；文件轮转、清理或人工重建时，任何一个偏移写错都可能漏放或重放事务。GTID（全局事务标识）用服务器 UUID（通用唯一标识）和事务序号表示已执行集合，候选节点可比较集合、补齐缺失事务并让其他副本自动定位，拓扑切换更易自动化，但前提是版本、参数、日志保留和历史数据都满足 GTID（全局事务标识）规则。我不会把它说成自动修复数据差异的工具：错误初始化、跳过事件和错误 SQL（结构化查询语言）仍会把错误语义复制下去。

切换前先围栏旧写入口，保存每个候选的 Executed GTID Set（集合接口），即已执行全局事务集合）或文件位点、复制错误和关键表校验结果。若快照起点是 mysql-bin.010:400 却配置为 520，缺掉的 120 字节事件不能靠“延迟为零”发现；应从可信备份重建或按权威流水受控补偿。完成切换后，用订单、支付和库存样本核验新主的写入、其他副本追平和备份起点一致，再恢复读流量。选择标准始终是可证明的数据集合与恢复路径，而不是谁的延迟秒数更小。

上线前还要做一次“备份点与起始坐标故意错开”的演练，确认监控能发现集合缺口且重建流程可回退；这比只验证自动定位成功更能暴露初始化纪律问题。

补充验收看备份坐标与事务集合是否同源。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

3. 问题（综合题）：异步复制与半同步复制的确认边界和数据丢失窗口是什么？
   • 口述答案：异步复制只要求 Source（源库）本地提交完成，客户端成功时最后一段 binlog（二进制日志）可能尚未离开源机；源库随即不可恢复时，这些已确认写就是 RPO（恢复点目标）窗口。半同步复制把确认推进到至少一个 Replica（副本库）确认收到日志，能缩小“只有源端持有”的窗口，但默认确认通常仍在 Receiver（接收） Thread（线程）的接收或落盘阶段，不代表 Applier（应用） Thread（线程）已执行，更不代表副本可读。半同步还可能因超时、确认副本不足或配置策略退化为异步，所以它是风险收敛措施，不是零丢失承诺。

支付入账可以用半同步降低单机故障损失，但写后查询仍需主库回读或 GTID（全局事务标识）等待；库存裁决仍必须以源库条件更新为准。事故证据至少包括提交时间、binlog（二进制日志）事件、半同步确认状态、候选副本已执行集合和退化告警。若确认链断裂，先冻结高风险写或把请求置为处理中，避免重试制造双扣；再依据渠道交易号、账务分录和库存流水裁定最后窗口。恢复后通过断开确认副本的演练，验证应用降级、告警和对账能否识别边界，而不是只验证复制线程重新绿色。

对于跨可用区链路，还要记录确认副本实际分布，避免确认仍落在同一故障域；恢复验证应断开该故障域并确认业务能按既定降级策略收敛。

补充验收看确认副本是否跨故障域。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

4. 问题（综合题）：如何解释并行复制没有把所有延迟问题都解决？
   • 口述答案：并行复制只提升副本应用阶段中彼此独立事务的重放吞吐。多个 Applier（应用） Thread（线程）可并行处理不同订单或不同用户的提交组，但同一库存行的条件扣减、同一账户余额、大事务、DDL（数据定义语言）和热点索引页仍存在真实依赖；即使把线程从 4 增到 32，也不能把一个大事务任意切开，更可能增加调度和磁盘 I/O（输入输出）竞争。因而延迟治理先看能否并行，而不是先改线程数。

我会比较 Receiver（接收） Thread（线程）进度与执行进度：接收也落后时查网络、源端发送和日志保留；接收领先而执行落后时查 Relay（中继） Log（日志）增长、事务大小、锁等待、工作线程忙闲和磁盘队列。WMS（仓储管理系统）的单 SKU（库存单位）热点，要通过按仓库或货品分片、缩短事务和批任务检查点降低依赖，而不是用副本线程掩盖。修改前后记录同一批压测的执行位点差、锁等待和业务陈旧时间；恢复验证以库存预占流水、负库存约束和副本读到指定事务为准。若并行参数导致错误或资源饱和，应回退参数、保留 Relay（中继） Log（日志）证据并从一致基线重放。

参数调整后以相同数据分布回放，比较事务依赖数、队列增长率和尾部延迟；若收益只来自低并发样本，就不能把它作为生产容量结论。

补充验收看热点事务是否仍阻塞提交。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

5. 问题（综合题）：副本延迟时，你如何定位并治理，而不是只盯延迟秒数？
   • 口述答案：我先把延迟拆为“源端提交到副本接收”和“副本接收到应用完成”两段。Seconds_Behind_Source（落后源库秒数）只能提示异常，受线程状态和时间戳影响，不能代表精确事务缺口或用户看到的陈旧度。第一步按业务止血：支付写后查询、库存裁决回 Source（源库），履约展示返回最后同步时间并限制陈旧阈值。第二步比较源端 binlog（二进制日志）坐标、已接收位点、已执行位点或 GTID（全局事务标识）集合，判断是发送链路还是应用链路。

应用落后时继续查 Relay（中继） Log（日志）积压斜率、复制错误、大事务、锁等待、DDL（数据定义语言）、磁盘 I/O（输入输出）和 CPU（中央处理器）；网络落后时查连接重连、带宽和日志清理风险。绝不为了告警消失直接跳过错误事件，因为这会把技术延迟变成静默数据差异。治理动作应有证据：拆分大批导入、限速 Runner（执行器）任务、隔离报表副本或重建不可信副本。恢复后选择一组订单、支付和库存样本，验证执行集合追平、路由恢复后陈旧度达标、业务流水守恒；告警阈值也要从实测积压速率重设。

每次处置还应记录延迟开始、止血、追平和恢复读的四个时间点，用实际陈旧分钟数校准告警；这样下一次能按业务影响而非单一秒数升级。

补充验收看延迟斜率是否在止血后收敛。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

6. 问题（综合题）：怎样为支付写后读设计会话一致性？
   • 口述答案：支付写后读的风险不是页面慢，而是用户把副本旧状态当作失败后再次支付。写入只进入 Source（源库），成功响应记录订单版本或 GTID（全局事务标识）；同一会话的关键查询先短时粘滞源库，或让读代理等待目标 Replica（副本库）已执行该 GTID（全局事务标识），等待超时则回源库，并明确返回“处理中”而非伪造失败。普通账单列表和历史履约可读副本，但要携带更新时间与陈旧上限。半同步确认也不能替代该协议，因为副本收到 binlog（二进制日志）并不表示已应用。

数据库之外还要用 Idempotency Key（幂等键）、渠道交易号唯一约束、金额校验和状态机防住超时与重复回调。排查时取一笔请求的网关时间、源库提交 GTID（全局事务标识）、代理路由、等待结果和副本执行集合，才能区分复制延迟、路由错误与事务可见性。故障边界是等待超时后绝不向用户承诺失败并重扣：先查询权威流水，必要时异步对账。恢复验证要注入副本应用阻塞、代理切换和重复回调，确认关键路径始终回源或等待、渠道金额与账务分录守恒、恢复后才逐步释放副本读。

对于等待失败的请求，接口必须返回可查询的请求标识而不是要求用户再次提交；恢复后以该标识回查权威状态，确保没有因页面超时产生第二笔支付。

补充验收看超时请求能否查回权威流水。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

7. 问题（综合题）：如何设计一次安全的 MySQL（关系型数据库）切主，防止脑裂？
   • 口述答案：切主的第一目标是唯一写权，不是尽快改连接地址。发现旧主不可达后先区分节点故障和网络分区；只要不能证明旧主已被隔离，就暂停支付和库存等高风险写，不能提升副本。确认后执行 fencing（栅栏）：网络隔离、主机关机或存储围栏、撤销数据库写账号和代理写路由共同保证旧主即使仍运行也无法产生权威写。然后比较候选的 GTID（全局事务标识）集合或 position（位点）、复制错误、关键表校验、容量和 RPO（恢复点目标），再由编排器记录授权并切流。

切换窗口的超时重试仍可能重复到达，因此应用必须保留幂等键、唯一约束和合法状态迁移。旧主恢复后只能作为待处置节点：导出其残留写证据，与新主 binlog（二进制日志）和业务流水比对，确认策略后重建复制，不能直接接回流量。验证不是 ping（网络连通测试）成功，而是故障注入后旧主写被拒、新主只接受一次库存预占或支付回调、各副本从新主追平，并用账务金额和库存流水做守恒检查。每一步保留时间线、围栏命令、候选比较和路由变更，才能复盘脑裂边界。

切主完成后保留旧主隔离至少覆盖最大客户端重试窗口，再检查是否仍有直连写尝试；这是验证围栏真正覆盖所有入口，而不是只覆盖代理的一步。

补充验收看旧主恢复后是否仍有直连写。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

8. 问题（综合题）：代理、编排器、fencing（栅栏）和应用幂等的职责边界是什么？
   • 口述答案：代理在数据面按已授权拓扑做连接、读写路由、摘除和会话策略；它发现节点可连，并不能证明该节点拥有唯一写权。编排器在控制面负责健康判定、候选选择、提升、重建复制和审计，但它也可能被网络分区误导。fencing（栅栏）才负责在网络、主机、账号、存储和写入口拒绝旧主继续影响权威数据，核心是“旧主活着也写不进去”。应用层则承担幂等键、唯一约束、状态机、补偿和对账；数据库角色切换不能替应用判断支付回调或库存预占是否已经完成。

我会把这些职责写成可审计的状态机：编排器先取得围栏成功证据，再授予代理新主写路由，最后放开应用写流量；任一环失败则保持降级或只读。事故中保存健康探测原始结果、围栏执行记录、代理配置版本、GTID（全局事务标识）比较与应用请求标识。恢复验证通过模拟旧主网络孤岛、代理缓存旧拓扑和重复请求，检查旧主写拒绝、新主只产生一条业务流水、失败请求可幂等重试。这样避免把自动切换包装成“自动一致”，并能明确是谁负责补偿和谁负责恢复副本。

职责边界还要落实到权限：代理账号无提升权限，编排账号无业务写权限，补偿脚本需审批；用最小权限降低单个自动化组件越权扩大事故的概率。

补充验收看控制面权限是否可越权写库。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

9. 问题（综合题）：逻辑备份、物理备份、全量、增量和快照分别怎样选？
   • 口述答案：逻辑与物理描述备份形态，全量与增量描述覆盖范围，快照描述存储实现，不能混成一种能力。逻辑备份导出 SQL（结构化查询语言）或逻辑行，适合表级恢复和跨环境迁移，但大库导入慢；物理备份保存数据页、日志和元数据，恢复通常更快，适合作为灾备基线，却受版本、工具、文件布局和权限约束。全量提供完整起点；增量节省窗口与存储，但恢复要按链条合并，层数越多故障点越多。存储快照很快，但若未与 InnoDB（事务存储引擎）一致性协议协同，并不天然可恢复。

生产组合应从 RPO（恢复点目标）和 RTO（恢复时间目标）反推：常见是物理全量基线加连续 binlog（二进制日志）归档做 PITR（时间点恢复），关键表再做逻辑导出。每份备份记录备份开始结束时间、binlog（二进制日志）坐标或 GTID（全局事务标识）集合、校验和、加密密钥版本和所需工具版本。恢复时先在隔离环境验证链条完整和实例能启动，再抽样核对支付金额、库存流水和履约状态；不能因为对象存储里有文件就宣布达标。

备份策略变更后要抽取不同表规模和不同恢复点测试，避免只在小库上通过；恢复报告应能反查每一份基线对应的日志链和密钥，防止事故时临时猜测。

补充验收看恢复链是否能定位到每份密钥。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

10. 问题（综合题）：什么是热备一致性点，为什么“拷贝数据目录”不可靠？

• 口述答案：热备期间数据库持续写入，数据页、索引页和日志页在不同时间刷盘；任意时刻拷贝目录可能得到互不匹配的页面与日志，恢复后要么无法启动，要么无法证明逻辑状态。热备一致性点是备份工具或数据库协调数据文件与必要日志，使恢复过程能把不同物理时刻的页收敛到确定事务边界，同时记录对应 binlog（二进制日志）坐标或 GTID（全局事务标识）集合。物理热备依赖 InnoDB（事务存储引擎）恢复协议；逻辑一致导出依赖事务快照、锁策略，并要明确非事务表和 DDL（数据定义语言）变更边界。

它不仅是备份元数据里的数字，也是副本重建和 PITR（时间点恢复）的起点。发现目录拷贝或快照来源不可信时，先禁止把它用于切主或覆盖生产，保全工具日志、文件清单、校验和和当时的日志坐标；再从可信基线恢复，按连续 binlog（二进制日志）重放到目标点。验证要包括实例启动、页校验、关键表行数、支付账务守恒和库存可用量，再尝试建立复制并确认执行集合衔接。这样证明的是可恢复的一致状态，而不是文件复制成功。

如果使用存储快照，还要验证跨卷顺序、冻结接口和恢复后的日志重放；任何依赖人工记忆的步骤都应固化为脚本和演练清单，避免夜间事故遗漏。

补充验收看跨卷快照能否正确重放日志。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

11. 问题（综合题）：请描述一次订单误删后的 PITR（时间点恢复）方案。

• 口述答案：订单误删后第一原则是停止扩大，而不是在生产立刻执行猜测性的反向 SQL（结构化查询语言）。我先固定事故时间线：操作者、库表、条件、事务边界和受影响业务号，并保全审计记录、binlog（二进制日志）、当前写入和备份清单。随后在隔离环境恢复最近可信物理或全量基线，按连续 binlog（二进制日志）重放到误删事务之前；必要时用 GTID（全局事务标识）与事件内容校对停止点。恢复实例只用于取证和生成候选回补集，绝不能直接覆盖仍有合法新写入的生产库。

回补按主键、状态前驱、版本号和 Idempotency Key（幂等键）小批且可重入地合并。支付关联订单要对渠道交易、账务分录和金额守恒，库存要对预占、释放、发货和盘点流水，履约要防止旧状态覆盖新状态。证据包括恢复日志、停止位点、差异清单、回补前后校验和人工审批。回补后重新检查副本 GTID（全局事务标识）追平、关键读路由和对账差异为零；若日志缺失或停止点不确定，宁可扩大隔离调查，不把不确定恢复写回权威库。

回补前把候选记录按金额、状态和更新时间分级，先处理会造成资金或库存错误的记录；回补后再次跑差异查询，确保恢复过程没有覆盖事故后新增的合法订单。

补充验收看回补是否保留事故后的新订单。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

12. 问题（综合题）：为什么有备份不等于可恢复？如何设计恢复演练？

• 口述答案：备份任务成功只证明生成环节跑完；真正恢复还依赖对象存储可读、网络带宽、密钥、权限、工具与数据库版本、磁盘容量、日志连续性和操作流程。大库的下载、解密、解压、准备、还原、binlog（二进制日志）重放、校验和切流总时长，常常远大于数据库启动时间，所以“文件存在”不能证明满足 RTO（恢复时间目标）。演练要在隔离环境按真实规模和真实链路完成：选择明确恢复点，恢复基线，启动 MySQL（关系型数据库），做 PITR（时间点恢复），重建必要账号与复制，再验证应用读写。

验收同时覆盖技术和业务：技术上检查校验和、权限、日志连续、监控与告警；支付检查订单金额、借贷分录和渠道流水差异，库存检查可用量、预占释放流水和负数约束，履约检查事件序号与状态单调。计时从宣布故障到关键服务安全接流量，输出每阶段耗时、失败原因和改进负责人。演练还应故意注入密钥失效、日志缺段或容量不足，确认告警和回退路径有效。只有多轮实测都落在 RPO（恢复点目标）与 RTO（恢复时间目标）内，备份策略才是可用能力。

演练结论必须量化为“哪个恢复点、多少数据、耗时多少、校验差异多少”，并与承诺阈值比较；没有量化结果的演练只能证明流程被走过，不能证明目标可达。

补充验收看实测耗时是否覆盖完整校验阶段。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

13. 问题（综合题）：支付资金一致性在复制、切换和恢复场景下怎样保证？

• 口述答案：支付资金一致性不能建立在“复制一定无延迟”上，而要把数据库可靠性放入账务协议。写路径中，支付单、渠道交易号、账务分录和状态变更在 Source（源库）用唯一约束、状态前驱和金额校验提交；超时或回调重投由 Idempotency Key（幂等键）和渠道流水去重。读路径中，刚提交的状态走主库回读、会话粘滞或 GTID（全局事务标识）等待，不能因 Replica（副本库）旧值再次发起扣款。半同步复制只缩小源端丢失窗口，并不替代账务校验。

切换先 fencing（栅栏）旧主，再用 GTID（全局事务标识）集合、复制错误、账务守恒和候选容量裁定新主；窗口请求可显示处理中，但不重放扣款。恢复时从 PITR（时间点恢复）实例提取差异，而非覆盖生产，再以渠道对账单、账务分录和订单状态生成可审计补偿或冲正。证据链要能关联渠道回调时间、源库 binlog（二进制日志）、路由记录和账务凭证。验证包含重复回调、主库故障、读副本落后和误删恢复：每种情况下都应最多一笔入账，借贷平衡、渠道金额一致，差异进入明确的人工处置队列。

支付场景还要把渠道查询作为独立证据源，防止本地复制链同错时自证正确；对账差异必须进入可追踪的补偿状态，而不是在切换后静默忽略。

补充验收看渠道对账是否独立于本地复制。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

14. 问题（综合题）：WMS（仓储管理系统）库存防超卖如何处理副本陈旧与切主？

• 口述答案：库存防超卖的裁决不能放在读副本，因为 Replica（副本库）陈旧会把展示数量误当成可售数量。预占必须进入 Source（源库），通过 available >= quantity 的条件更新、受影响行数、库存流水和业务幂等键共同决定成功；副本和缓存只服务商品页、报表或近实时看板。下单后的展示可回源库或等待该笔 GTID（全局事务标识）在副本执行，但不能据旧值再次预占。切主时最危险的是脑裂导致两个节点分别扣减，所以先 fencing（栅栏）旧主，代理只向唯一授权的新主放行写。

最后窗口未复制的事务不能靠修改库存主表“凑数”，要以订单、预占、释放、支付、发货和仓库操作记录裁定并生成补偿。排障证据包括条件更新影响行数、库存版本、binlog（二进制日志）坐标、候选副本已执行集合和路由时间线。恢复后以 SKU（库存单位）和仓库维度重算“期初+入库-出库-冻结=可用”，并注入主库断连、重复下单、延迟副本读和切换重试验证：库存不得为负、同一预占单只能生效一次、差异必须可对账。这样复制只承担传播，业务守恒才承担防超卖结论。

库存恢复后除数据库校验外，还要与仓库实际作业和出入库消息核对；若物理作业已发生，补偿必须经过业务状态机，不能把数据库数字回滚到历史值。

补充验收看仓库作业记录是否与库存流水一致。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

15. 问题（综合题）：履约轨迹为何能用副本读，但仍要防状态倒退？

• 口述答案：履约轨迹主要服务用户和运营展示，通常可容忍数秒到数分钟最终一致，因此查询可放在 Replica（副本库）或异步读模型；但允许陈旧不等于允许错误。渠道事件可能乱序、重复到达或在切换后重放，若按到达顺序直接覆盖当前状态，晚到的“运输中”会把“已签收”倒退。我的做法是保存不可变 Tracking Event（轨迹事件），用渠道事件 ID（事件标识）去重，用渠道序号、业务版本或可比较时间规则更新当前状态；副本响应携带事件时间和最后同步时间。

投诉举证、人工改派和刚触发面单操作仍回 Source（源库）或权威事件表，不依赖可能落后的读副本。复制延迟扩大时，代理按陈旧阈值摘除副本或降级回主，先保护正确性。证据链包括原始事件、去重键、状态迁移记录、源端 binlog（二进制日志）和副本执行位点。恢复或切主后重放事件时，验证总事件数、唯一事件数、序号连续性和状态单调性；发现差异时从原始事件重建读模型，不直接手改当前状态。这让副本读承担性能，事件规则承担语义正确。

当渠道无法提供严格序号时，状态迁移要明确不可逆规则和人工例外队列；恢复时优先重建事件事实，再投影当前状态，避免依据副本快照猜测事件先后。

补充验收看乱序事件能否从原始事实重建。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

16. 问题（综合题）：大事务如何同时伤害复制、切换和恢复？

• 口述答案：大事务会同时放大三个窗口。源端一次产生大量 binlog（二进制日志）事件，占用日志、网络和磁盘；副本即使持续接收，Applier（应用） Thread（线程）也要长时间执行该事务，事务内部难以任意并行，Relay（中继） Log（日志）随之增长，关键读陈旧度扩大。切换时若候选正在重放或缺少这段事务，追赶时间不可预测，贸然提升会扩大 RPO（恢复点目标）风险。恢复时日志重放同样被大事务拉长，直接侵蚀 RTO（恢复时间目标），误删场景的停止点和回补范围也更难裁定。

治理要回到业务边界：导入、归档和 Runner（执行器）任务按可验证检查点分批提交并限速；库存、支付等必须保持原子性的核心操作不机械拆分，而用状态机和补偿处理跨批。排障记录事务大小、执行时长、锁等待、Relay（中继） Log（日志）斜率和候选 GTID（全局事务标识）差。若复制报错，不可跳过大事务换取绿灯，应先隔离读流量、保全日志并在副本或恢复环境复现。恢复验证按批检查行数、账务守恒和库存流水，确认大事务后各副本追平，才能解除限流。

批处理设计还应记录每批业务范围和提交标识，发生中断时能够精确续跑；只有可定位的检查点，才不会在复制追赶或恢复重放时重复整批业务。

补充验收看检查点是否支持中断后精确续跑。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

17. 问题（综合题）：如何给一个新系统制定数据库 RPO（恢复点目标）和 RTO（恢复时间目标）？

• 口述答案：我先按业务事实分级，而不是先问多久备份一次。支付入账、余额和库存预占丢失会造成账实不符，RPO（恢复点目标）要更小，需要连续 binlog（二进制日志）归档、合适的复制确认、幂等和对账；履约展示、报表和历史搜索可接受更大陈旧窗口。RTO（恢复时间目标）则从可承受停机反推：若承诺 30 分钟恢复，就把下载、解密、准备、物理还原、日志重放、校验、扩容和切流逐段测量，任何一段超时都要调整技术方案或业务承诺。

方案可以是物理全量基线加连续日志、跨可用区副本、预置恢复资源和自动化脚本，但成本与演练频率会随目标变严。还要明确“恢复”是只读可查、可继续下单，还是完成对账后全面接流量；不同定义的验收不同。制定时保留数据量、日志增速、带宽、恢复时长和校验结果证据，定期用真实规模演练。若演练发现 PITR（时间点恢复）无法在目标内完成，就缩短备份链、增配资源或降低业务范围，不能靠一句高可用承诺掩盖缺口。

目标评审应由业务、运维和研发共同签字，明确哪些数据允许丢失、哪些功能可降级；否则技术团队无法在故障中判断是继续恢复还是先恢复只读服务。

补充验收看只读、下单和完全恢复三种口径。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

18. 问题（综合题）：复制拓扑中如何处理报表、备份与业务读相互争抢？

• 口述答案：副本不是无限资源池。报表、备份、离线导出和关键业务读混在同一 Replica（副本库）上，会争抢 Buffer Pool（缓冲池）、磁盘 I/O（输入输出）和 CPU（中央处理器），导致 Applier（应用） Thread（线程）落后，业务读再出现陈旧。我的分级是：支付写后查询和库存裁决不走普通副本；履约展示和常规列表走业务读副本；重报表、备份和分析尽量使用专用副本或隔离资源，并设置并发、超时和流量窗口。备份副本也必须维持健康复制，不能因备份压力落后到失去重建价值。

若从副本备份，要记录其已执行 GTID（全局事务标识）、一致性点和上游日志保留，避免恢复链无法衔接。Runner（执行器）批任务采用检查点、限速和分片，避免一条长查询拖垮所有副本。监控同时看接收/执行差、慢查询、磁盘队列、备份耗时和业务陈旧时间。发生争抢先把关键读回源库、暂停低优先级作业，再依据证据扩容、拆分或调度。恢复验证在备份窗口压测业务读，确认指定事务仍能在副本可见、备份能独立恢复、支付与库存校验不受影响。

资源隔离也要用压测证明：备份、报表和业务读同时运行时，副本应用延迟仍在阈值内；若不达标，优先拆资源而不是把风险转嫁给关键读路径。

补充验收看备份窗口是否压垮副本应用。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

19. 问题（综合题）：跨 MySQL（关系型数据库）5.7、8.0、8.4 升级时，复制和备份如何控风险？

• 口述答案：跨版本升级不能因为实例启动成功就宣布完成，因为复制、备份、认证、参数、监控解析和运维脚本会一起变化。MySQL（关系型数据库）5.7 常见旧状态字段和 Master（主库）/Slave（从库）术语；迁到 8.0 或 8.4 LTS（长期支持）要逐项核对 GTID（全局事务标识）、日志格式、字符集、账号认证、备份工具、驱动和 DDL（数据定义语言）行为。小版本的废弃参数与支持矩阵也不能凭经验推断，必须以目标版本文档和预发验证为准。

流程从真实备份的隔离恢复开始，再按支持路径建立复制或升级链，压测业务读写、大事务和备份，随后演练切主、回切与 PITR（时间点恢复）。证据包含升级前后参数清单、复制位点或 GTID（全局事务标识）集合、备份恢复日志、代理健康检查和业务对账结果。任何一项失败都有可执行回滚：停止灰度、切回已验证节点或从基线恢复。最终不只看监控绿灯，还要验证支付金额守恒、库存防超卖条件和履约状态单调；这些通过后才逐批放量。

升级窗口必须保留升级前备份、可启动的旧版本节点和明确回切判据；一旦复制语义或恢复链验证失败，立即停止扩散，不在生产边排错边继续升级。

补充验收看升级回退是否能使用旧备份恢复。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

20. 问题（综合题）：复制不一致发生后，如何决定补数据、重建副本还是业务补偿？

• 口述答案：发现不一致先阻止扩大：摘除有风险副本的关键读、禁止人工写副本，保全复制错误、binlog（二进制日志）、GTID（全局事务标识）集合、表校验和和业务流水。随后判断差异性质。若是一笔语义明确、幂等且能由源端日志或权威流水证明缺失的事件，可用受控脚本补事务，记录前后校验；若初始快照错配、历史跳过事件不可追溯、多表关联破坏或范围不可信，应从一致备份重建副本，不能在错误基线上持续缝补。技术修复不等于业务修复。

支付以渠道交易和账务分录裁定，必要时冲正或人工处理；库存以预占、释放、发货和盘点流水重算，不能把主表改到“看起来正确”。选择动作前要明确权威来源、回滚方式、审批人与影响范围。修复后比较 GTID（全局事务标识）衔接、关键表校验、路由日志和业务守恒，并让新副本经历追平、只读灰度和故障切换验证。若补偿脚本无法幂等或证据不足，则保留隔离和对账队列，不能为了缩短事故时间牺牲可证明性。

补偿结束后安排独立复核人检查脚本输入、输出和差异归零证据；这样可防止同一操作者同时定义权威数据和验证结果，降低误补的隐蔽风险。

补充验收看补偿脚本是否可审计且可回滚。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

21. 问题（综合题）：如何设计一次不影响生产的恢复演练，并让结果可信？

• 口述答案：可信恢复演练首先隔离环境与目标：使用独立账号、网络、计算和存储，防止恢复实例误连生产，也限制读取备份对生产带宽的冲击。开始前冻结演练所需备份、连续 binlog（二进制日志）、密钥、工具版本和目标事务点，并明确数据规模、RTO（恢复时间目标）与业务校验规则。执行时完整模拟下载或挂载、完整性校验、物理或逻辑基线还原、启动 MySQL（关系型数据库）、PITR（时间点恢复）、创建账号配置和应用读写，而不是只测试某个命令成功。

验证既要自动也要人工抽样：支付核对借贷分录、订单金额与渠道流水，库存核对可用量、预占释放和负数约束，履约核对事件总量、序号连续和状态单调。时间从故障宣告到关键服务安全接流量计量，分段记录下载、准备、重放、校验与切流耗时。演练中故意注入密钥不可用、binlog（二进制日志）缺段和磁盘不足，验证告警、停止条件和回退方案。结果以可复跑报告、校验差异和改进期限归档；未达标时调整资源、链条或承诺，不能把一次空库恢复当作生产证明。

演练过程中产生的恢复实例、临时账号和日志副本都要按清单销毁或隔离，避免测试环境成为新的数据泄漏与误连接入口；清理结果也应纳入报告。

补充验收看临时恢复资源是否完成隔离清理。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

22. 问题（综合题）：如何回答“线上页面看到旧数据，是 MVCC（多版本并发控制）还是复制延迟”？

• 口述答案：两者表象相似，证据与处理却不同。MVCC（多版本并发控制）发生在同一 MySQL（关系型数据库）实例和事务内：应查看隔离级别、事务开始时间、Read View（读视图）创建时机和是否复用长事务快照；源库可能已有新提交值，但当前会话为保持一致视图仍读旧版本。复制延迟发生在不同节点：先确认请求路由到哪个 Replica（副本库），再比较该节点接收/执行位点、GTID（全局事务标识）集合、Relay（中继） Log（日志）积压和 Applier（应用） Thread（线程）状态；此时副本尚未执行目标事务。

排查先保存连接标识、实例地址、写入事务标识或 GTID（全局事务标识）以及请求时间，在源库与副本分别核验。若是 MVCC（多版本并发控制），结束不合理长事务、调整读类型或回到权威会话；若是复制延迟，关键读回源库并定位网络、锁或大事务。不能靠刷新页面或切换副本猜测根因。验证时构造一笔可追踪写入：同一事务内读旧值应符合 Read View（读视图）规则，另一个副本的旧值必须能由执行位点解释；修复后再检查路由、延迟告警和支付库存等业务守恒。

对于同一页面请求，还要检查连接复用和事务边界，避免把一个长事务的旧视图误判成路由到旧副本；两类问题的修复路径不同，证据不能混用。

补充验收看连接事务是否误复用旧读视图。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

23. 问题（综合题）：请给出“误删 + 副本延迟 + 切主失败”的事故处置优先级。

• 口述答案：这种组合事故的危险在于多个“修复”动作会覆盖事实，所以第一步是停止扩大：冻结误删脚本和高风险写，禁止提升延迟副本，限制代理切换，保全源库、副本、binlog（二进制日志）、GTID（全局事务标识）集合、备份点和业务时间线。第二步处理写权：旧主状态不明时先 fencing（栅栏）或暂停支付与库存写，绝不能让两个节点继续接单。第三步分离可用性与恢复：选择已知最完整且围栏完成的权威节点承接最低限度写，关键读回主；误删恢复只在隔离环境进行，不能让恢复库覆盖已有合法新写入。

第四步从可信备份加 PITR（时间点恢复）构建误删前视图，以渠道账务、库存流水和订单状态生成可重入回补集，同时评估延迟副本缺失的最后窗口。证据包括围栏结果、候选集合比较、恢复停止点、差异清单和路由变更。恢复写流量前验证唯一写权、支付最多一次入账、库存不为负、回补可重复执行且副本重新建立复制；任何条件未满足就维持降级并扩大对账，而不是以服务恢复速度替代数据正确性。

事故结束后把误删权限、延迟告警和切主审批一起复盘，因为任一单点改进都不能覆盖这种组合故障；下一次演练应按同样组合验证改进是否有效。

补充验收看组合故障下审批与围栏次序。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

24. 问题（综合题）：请给出复制高可用与备份恢复的三分钟面试总结。

• 口述答案：我的总结从边界开始：复制负责日志传播和读扩展，高可用负责故障时唯一写权与切流，备份恢复负责误操作、逻辑损坏和跨节点灾难，三者必须组合但不能互相替代。链路是 Source（源库）提交写 binlog（二进制日志），Dump（转储） Thread（线程），即二进制日志发送线程）发送，Replica（副本库）的 Receiver（接收） Thread（线程）写 Relay（中继） Log（日志），Applier（应用） Thread（线程）重放；接收与应用分离，所以异步复制存在已确认写丢失窗口，半同步通常只把确认推进到至少一个副本收到日志，并不保证可读。

读写分离按风险分级：库存裁决和支付写后读走主库回读、会话粘滞或 GTID（全局事务标识）等待，履约展示可容忍陈旧但必须给更新时间并防状态倒退。切主先 fencing（栅栏）旧主，再基于进度、校验和容量选择候选，应用继续靠幂等、状态机与对账防重复。恢复采用可信全量或物理基线加连续 binlog（二进制日志）做 PITR（时间点恢复），在隔离环境验证启动、校验、业务守恒和 RPO（恢复点目标）/RTO（恢复时间目标）。最后用故障演练证明旧主不能写、指定事务可追平、支付账务和库存流水可对账；这才是可证明的高可用闭环。

这套总结落地为季度演练：一次断主围栏、一次指定点恢复、一次副本延迟与写后读验证；每次都保存证据和改进项，才能让能力随数据规模增长而持续有效。

补充验收看季度演练证据能否持续复用。 结果必须由独立校验人复核，并在不满足时保持降级而不是提前放量。

上述处理以保存的位点、日志和业务校验结果为准；证据不足时继续隔离并完成复核。

• 对应机制详解

8. 本模块复习清单

• 能画出 Source（源库）→ Dump（转储） Thread（线程），即二进制日志发送线程）→ Receiver（接收） Thread（线程）→ Relay（中继） Log（日志）→ Applier（应用） Thread（线程）的链路，并说清接收不等于可读。
• 能区分 position（位点）与 GTID（全局事务标识），知道二者都必须绑定一致初始数据集。
• 能说明异步、半同步复制、Group Replication（组复制）和 InnoDB（事务存储引擎） Cluster（集群）的确认边界与成本。
• 能把复制延迟拆成接收和应用两段，且不把延迟秒数当作唯一事实。
• 能设计支付写后读、库存权威写和履约陈旧读的不同路由策略。
• 能复述切主必须先 fencing（栅栏），代理、编排器和应用幂等各有边界。
• 能比较逻辑/物理、全量/增量、快照与热备一致性点，并说明有备份不等于可恢复。
• 能执行“隔离恢复 → PITR（时间点恢复）→ 校验 → 受控回补”的误删恢复思路。
• 能用 RPO（恢复点目标）/RTO（恢复时间目标）解释技术选型，并拿出实测恢复演练证据。
• 能说出 MySQL（关系型数据库）5.7、8.0、8.4 需按小版本验证复制、备份、脚本和升级路径。

9. 官方手册核对入口

• MySQL（关系型数据库）5.7 Reference Manual（参考手册）：Replication（复制）、Binary Logging（二进制日志）与 Backup and Recovery（备份与恢复）章节。
• MySQL（关系型数据库）8.0 Reference Manual（参考手册）：Replication（复制）、Group Replication（组复制）、InnoDB（事务存储引擎） Cluster（集群）与 Point-in-Time Recovery（时间点恢复）章节。
• MySQL（关系型数据库）8.4 Reference Manual（参考手册）：Replication（复制）配置、废弃项、Backup and Recovery（备份与恢复）及升级章节。

版本、参数和管理命令必须以目标 MySQL（关系型数据库）小版本官方手册和隔离演练为准；本分册不把未核验行为写成跨版本绝对结论。