3.2.7 集群复制、分片、备份恢复与数据迁移

项目版本：待现场核对。本文只固化跨版本稳定的机制边界；默认值、命令、确认级别、选举条件、快照兼容性和升级路径一律进入文末核对卡。

1. 四类产品的确认、复制与恢复事实

1.1 PostgreSQL（关系型数据库）：WAL（预写日志）位置贯穿确认、复制与恢复

PostgreSQL（关系型数据库）的物理流复制发送 WAL（预写日志）字节，主库提交先受本地持久化配置约束；若配置同步复制，还要等待被选同步副本达到约定的接收、写入、刷新或应用位置。异步复制只保证主库本地确认，副本可能落后。逻辑复制从发布端变化中形成逻辑变更，适合选择表、异构消费和版本演进，但对象定义、序列、未发布表及大对象等边界必须按现场版本核对。复制进度不能只看“连接正常”，应比较发送、接收、刷新和重放 LSN（日志序列号），并把字节差换算为随负载变化的时间差。故障提升把可用副本变成新主库，旧主复活后必须隔离、重绕或重建，不能凭原角色继续写。

表 1：PostgreSQL（关系型数据库）复制语义

sequenceDiagram
    participant C as 客户端
    participant P as PostgreSQL 主库
    participant W as WAL 与 LSN
    participant R as 流复制副本
    participant F as 提升与重建
    C->>P: 提交库存或支付事务
    P->>W: 生成并刷新提交 WAL
    alt 同步确认
        W->>R: 发送 WAL
        R-->>P: 返回约定阶段位置
        P-->>C: 满足同步条件后确认
    else 异步确认
        P-->>C: 本地持久化后确认
        W-->>R: 异步发送并重放
    end
    R--xP: 主库故障
    R->>F: 以已接收位置提升
    F-->>C: 新主库恢复服务
    P--xF: 旧主复活先隔离再重绕

图 1 说明：节点分别是客户端、主库、WAL（预写日志）位置、副本和提升控制面；箭头表示提交日志、确认和提升顺序。前提是持久化、同步副本集合与故障域已核对。正常路径按配置等待本地或副本位置；失败路径是副本落后时提升造成 RPO（恢复点目标）缺口、旧主复活继续写或日志已回收无法追赶。业务结论是复制把单点失败转成“确认到哪个位置、提升丢多少、旧主怎样栅栏”的问题。

数据演绎 1：20 分钟复制落后。 高峰 WAL（预写日志）生成 80 MiB（兆字节）/s（每秒），副本重放 50 MiB（兆字节）/s（每秒），净落后 30 MiB（兆字节）/s（每秒）；20 分钟累计约 35.2 GiB（吉字节）。此时连接仍正常，但提升最多可能缺少这段异步确认的数据；若源端保留不足，副本还会失去连续追赶条件。先限制报表长查询和低优先级批量，保护日志保留，再比较发送、接收、刷新、重放四个位置；支付与库存读回主库，修复后以业务版本和对账证明追平，不能只看字节差归零。

热门面试题

1. 问题（基础题）：流复制与逻辑复制最核心的差异是什么？
   • 考点：复制单位与使用边界。
   • 回答思路：从物理日志、逻辑变更和完整性回答。
   • 详细答案：流复制以 WAL（预写日志）物理变化维持近似主库副本，适合高可用与只读；逻辑复制按发布对象传递逻辑变更，适合选择表和异构投影，但不天然覆盖所有对象与集群元数据。
   • 进阶追问：逻辑复制能否直接替代备份？
   • 进阶回答：不能，它可能传播误删，且未必覆盖对象定义、历史版本、密钥与恢复一致性点。
2. 问题（原理题）：为什么 LSN（日志序列号）差不能直接等同时间差？
   • 考点：进度坐标与速率。
   • 回答思路：比较日志生成和重放速率。
   • 详细答案：相同字节差在低峰可能数分钟，在高峰可能数秒；还要看当前生成速率、网络、刷新和重放能力，用位置差、时间戳与吞吐联合估算。
   • 进阶追问：连接正常是否说明可提升？
   • 进阶回答：不说明，还要验证目标 RPO（恢复点目标）、日志连续性、回放状态和提升后的业务不变量。
3. 问题（场景题）：旧主复活为什么不能直接加入集群？
   • 考点：时间线分叉与脑裂。
   • 回答思路：先隔离写入，再重绕或重建。
   • 详细答案：新主提升后已经形成新历史，旧主可能缺少新提交却保留旧客户端连接；直接开放会产生双写。必须先网络和账号栅栏，再依据共同位置重绕或从新主重建。
   • 进阶追问：业务层还需什么保护？
   • 进阶回答：关键写携带领导任期或版本条件，旧任期即使绕过路由也不能覆盖新状态。

1.2 MongoDB（文档数据库）：oplog（操作日志）、多数提交点与任期共同界定安全窗口

MongoDB（文档数据库）副本集由主节点接受写入并把可复制操作写入 oplog（操作日志），从节点持续拉取和应用。写关注决定客户端等待多少成员确认及是否要求持久化；多数确认与多数提交点相关，但它只约束副本集内写入，不证明搜索投影、对象存储或外部通知完成。读取是否陈旧还取决于读关注、读偏好、会话因果约束和从节点应用进度。选举产生新任期，新主从已提交历史继续服务；旧主发现无法维持主角色后降级，未进入安全提交历史的写可能回滚。故障恢复必须保留回滚证据，并用业务幂等键处理“客户端超时但写是否成功未知”。

表 2：MongoDB（文档数据库）副本集语义

sequenceDiagram
    participant C as 客户端
    participant P as MongoDB 主节点
    participant O as oplog 与多数提交点
    participant S1 as 从节点一
    participant S2 as 从节点二
    C->>P: 写入物流轨迹文档
    P->>O: 追加可复制操作
    O-->>S1: 拉取并应用
    O-->>S2: 拉取并应用
    alt 多数确认满足
        S1-->>P: 确认约定阶段
        P-->>C: 返回写成功
    else 主节点孤立
        P--xC: 结果未知或拒绝
        S1->>S2: 选举形成新任期
        S1-->>C: 新主继续服务
        P--xS1: 旧主降级并处理分叉操作
    end

图 2 说明：节点是客户端、主节点、oplog（操作日志）与两个从节点，箭头体现复制、确认和选举。前提是成员投票、故障域和写关注已现场核对。正常路径在约定确认后响应；失败路径包括主节点孤立、少数写未进入多数提交点、从节点应用落后和旧主回滚。业务结论是多数确认缩小已确认写丢失窗口，却不能替代业务幂等、外部同步和删除对账。

数据演绎 2：多数确认与未知结果。 三成员副本集中，主节点和从节点一已持久化轨迹版本 108，从节点二落后到 104；客户端在收到响应前断线。随后原主隔离，从节点一当选，新历史保留 108。客户端若换随机标识重试会生成重复轨迹；若以运单号、渠道事件号和版本 108 查询并重试，同一事件只返回既有结果。反例是该写只在旧主本地存在且未达到多数提交点，提升后可能回滚，必须从回滚证据、上游事件日志和业务对账恢复。

热门面试题

1. 问题（基础题）：多数确认是否等于所有副本都已应用？
   • 考点：确认集合与全体成员差异。
   • 回答思路：区分多数提交点和落后从节点。
   • 详细答案：不是。多数确认表示满足配置的法定成员已达到约定阶段，其他从节点仍可落后；从落后节点读取仍可能陈旧。
   • 进阶追问：怎样做读己之写？
   • 进阶回答：按现场版本核对会话、读关注与路由约束，或回权威主节点读取，不能只指定任意从节点。
2. 问题（原理题）：oplog（操作日志）为何既是复制源又不是备份？
   • 考点：滚动窗口与错误传播。
   • 回答思路：说明容量覆盖和历史恢复差异。
   • 详细答案：oplog（操作日志）提供近期有序变更供副本追赶，但会滚动覆盖，也会复制误删；备份还要保存一致基线、元数据、密钥和长期日志链并经过恢复演练。
   • 进阶追问：窗口太短会怎样？
   • 进阶回答：离线从节点或迁移消费者来不及追赶，只能从新快照重新建立基线。
3. 问题（场景题）：选举后发现少量轨迹消失怎么处理？
   • 考点：回滚、权威源与补偿。
   • 回答思路：保留现场并从事件身份恢复。
   • 详细答案：先冻结受影响运单写入，检查任期、提交点、回滚记录和上游事件日志；按稳定事件键补写可回放事实，再重建派生状态，禁止直接手改当前状态掩盖缺口。
   • 进阶追问：只比较文档数够吗？
   • 进阶回答：不够，还要比较版本连续性、最终状态、关键字段摘要和删除集合。

1.3 ClickHouse（列式数据库）：复制的是数据部件，Keeper（协调服务）保存协调事实

ClickHouse（列式数据库）的复制表以数据部件为核心：写入到某个副本后形成不可变数据部件，复制任务与元数据由 Keeper（协调服务）协调，其他副本拉取或在符合机制时生成相同数据部件。写入是否等待更多副本、何时算成功以及去重窗口都属于设置与版本敏感事实，必须现场核对。Keeper（协调服务）不是业务数据备份，保存协调状态也不等于数据部件安全；本地表、分布式路由和复制表是三层不同责任。副本恢复关注队列、数据部件校验、丢失数据部件和只读状态，分析查询从落后副本读取会出现数据新鲜度窗口，不能把“最终会同步”当成报表口径。

表 3：ClickHouse（列式数据库）复制语义

sequenceDiagram
    participant C as 客户端
    participant R1 as ClickHouse 副本一
    participant K as Keeper
    participant R2 as ClickHouse 副本二
    participant Q as 分布式查询
    C->>R1: 批量插入分析数据
    R1->>R1: 排序压缩并提交数据部件
    R1->>K: 登记部件与复制任务
    alt 等待副本策略满足
        K-->>R2: 通知复制任务
        R2->>R1: 拉取并校验数据部件
        R2-->>R1: 副本已具备部件
        R1-->>C: 返回成功
    else 异步复制
        R1-->>C: 本地部件成功
        K-->>R2: 后台追赶
    end
    Q->>R2: 从落后副本查询
    R2-->>Q: 返回带数据水位的陈旧结果

图 3 说明：节点包括写客户端、两个数据副本、Keeper（协调服务）和查询端；箭头表示部件提交、协调登记、拉取与读取。前提是表引擎、写入路由、等待策略和去重条件已核对。正常路径由健康副本传播数据部件；失败路径是 Keeper（协调服务）正常但部件磁盘损坏、队列积压或查询命中落后副本。业务结论是分析副本延迟必须以部件水位进入报表口径和切流门禁。

数据演绎 3：小部件与追赶。 日增 500 GiB（吉字节）若平均每个部件只有 10 MiB（兆字节），每天约产生 51200 个部件；若批量后平均 500 MiB（兆字节），约 1024 个。副本离线 20 分钟且高峰写入 100 MiB（兆字节）/s（每秒），需追赶约 117 GiB（吉字节），同时还有前台新写与合并。恢复网络有效 250 MiB（兆字节）/s（每秒）并给复制 150 MiB（兆字节）/s（每秒）时，净追赶仅 50 MiB（兆字节）/s（每秒），约需 40 分钟；临时磁盘还要承载拉取、校验和合并，不能只预留 117 GiB（吉字节）。

热门面试题

1. 问题（基础题）：Keeper（协调服务）保存了什么，没保存什么？
   • 考点：协调元数据与业务数据边界。
   • 回答思路：按复制任务和数据部件拆分。
   • 详细答案：Keeper（协调服务）保存复制协调所需元数据、队列和成员状态，不是所有业务列文件的备份；恢复仍依赖健康数据部件或独立备份。
   • 进阶追问：只备份 Keeper（协调服务）够吗？
   • 进阶回答：不够，还要保存数据、表定义、权限、词典、密钥和恢复顺序。
2. 问题（原理题）：为什么分析副本延迟不能只看时间？
   • 考点：部件、分区与业务水位。
   • 回答思路：比较队列年龄、缺失字节和最大业务时间。
   • 详细答案：20 分钟可能是少量冷分区，也可能缺失高峰全部新部件；应同时看队列数、字节、分区、最大事件时间和查询聚合差异。
   • 进阶追问：队列归零就能切流吗？
   • 进阶回答：还要做部件校验、关键聚合和查询回归，排除错误数据已经被一致复制。
3. 问题（场景题）：副本恢复时磁盘为何可能翻倍？
   • 考点：临时拉取、合并与旧部件共存。
   • 回答思路：沿下载、校验、发布和清理解释。
   • 详细答案：新部件先下载到临时位置，校验后与旧部件并存，后台合并还生成新输出，旧输入直到提交后才删除；恢复窗口必须按峰值而非净数据量预留。
   • 进阶追问：磁盘不足如何止血？
   • 进阶回答：暂停低优先级合并与回填、限速恢复、扩容空间并保护健康副本，不能直接删除未知部件。

1.4 Elasticsearch（搜索引擎）：主副分片、序列号与恢复共同定义搜索副本边界

Elasticsearch（搜索引擎）写请求经协调节点路由到主分片，主分片校验后分配 seq_no（序列号），写入 Lucene（全文检索库）内存结构与 translog（事务日志），再复制到分配中的副本分片；确认条件、活动分片要求和持久化行为属于版本敏感配置。primary_term（主分片任期）与 seq_no（序列号）用于拒绝旧任期写、乐观并发和恢复排序。写成功不等于立即可被搜索：refresh（刷新）建立可搜索分段，故“复制确认”“持久化”“搜索可见”是三个时点。主分片故障后由有效副本提升，恢复依据分片历史、保留操作和文件复制等机制按现场版本核对；旧主必须接受新任期，不能继续主写。

表 4：Elasticsearch（搜索引擎）主副分片语义

sequenceDiagram
    participant C as 客户端
    participant P as 主分片
    participant T as translog 与序列号
    participant R as 副本分片
    participant S as 搜索请求
    C->>P: 索引运单文档
    P->>T: 分配序列号并追加事务日志
    P->>R: 复制同一操作
    R-->>P: 副本阶段确认
    P-->>C: 写入确认
    S->>R: 确认后立即搜索
    R-->>S: refresh 前可能仍不可见
    R->>R: refresh 生成可搜索分段
    S->>R: 再次搜索并命中新版本
    P--xR: 主分片故障
    R->>R: 提升并增加主分片任期

图 4 说明：节点为客户端、主分片、事务日志与序列号、副本和搜索端；箭头分别表示写入、复制、刷新与提升。前提是分片路由、活动副本和刷新策略已核对。正常路径先确认复制再由 refresh（刷新）暴露搜索；失败路径包括写已确认但暂不可搜、恢复中缺分片及旧任期重试。业务结论是搜索索引适合作为可重建投影，库存和支付裁决仍回权威库。

数据演绎 4：确认与搜索可见分离。 10:00:00.100 主副分片均确认运单版本 520，10:00:00.120 客户端收到成功，但刷新间隔使 10:00:00.300 的搜索仍返回 519；10:00:01.150 刷新后才可见 520。若主分片在 10:00:00.500 故障，已具备该操作的副本可提升，搜索可见仍受刷新边界控制。调用方不能因短暂搜不到就重复创建运单，应按稳定文档标识查实时获取接口或回源权威数据库，并记录源版本与索引水位。

热门面试题

1. 问题（基础题）：写成功为什么可能搜不到？
   • 考点：确认与 refresh（刷新）边界。
   • 回答思路：区分事务日志、副本和可搜索分段。
   • 详细答案：写成功表示操作达到约定主副分片阶段，搜索依赖 refresh（刷新）后生成的可搜索分段；两者由不同时间边界控制。
   • 进阶追问：能否每次写后强制刷新？
   • 进阶回答：会增加小分段、合并和吞吐成本，应只在明确交互需求下评估，而非全局默认。
2. 问题（原理题）：主分片任期如何防旧主？
   • 考点：任期与序列号。
   • 回答思路：说明新任期和旧请求拒绝。
   • 详细答案：提升后主分片任期增加，写入与并发控制携带任期和序列号；旧任期操作不能覆盖新历史，从而限制旧主或旧客户端结果污染。
   • 进阶追问：业务还需要版本吗？
   • 进阶回答：需要，产品内部任期防分片历史冲突，业务版本防乱序事件覆盖运单、库存等领域状态。
3. 问题（场景题）：重建索引时如何避免切到缺数据的新索引？
   • 考点：全量、增量、校验与别名切换。
   • 回答思路：按源版本水位和影子查询设门禁。
   • 详细答案：冻结映射契约，装载全量后持续消费增量，比较文档数、删除集合、版本高水位和查询聚合，再做影子读；任何差异未解释前禁止切换读别名。
   • 进阶追问：切换后能立即删旧索引吗？
   • 进阶回答：不能，要保留观察和回滚窗口，并确认新写只进入目标、回滚增量路径可用。

1.5 横向复制坐标：确认、提升、旧主防护与陈旧读必须同口径比较

四类系统都能复制，但不能用一个“主写从读”模型概括。PostgreSQL（关系型数据库）用 WAL（预写日志）与 LSN（日志序列号）描述物理位置，逻辑复制还多一层解码和应用；MongoDB（文档数据库）用 oplog（操作日志）位置、多数提交点与选举任期；ClickHouse（列式数据库）以数据部件、复制队列和 Keeper（协调服务）协调记录为主，查询新鲜度还要看最大业务时间；Elasticsearch（搜索引擎）以 seq_no（序列号）、primary_term（主分片任期）、分片历史与 refresh（刷新）可见性描述。同步或多数确认提高客户端确认门槛，但不能消除异构投影、分析副本和搜索刷新延迟。故障提升必须同时回答：哪些已确认写能保留、旧主如何拒写、客户端未知结果如何查证、读副本最多陈旧多久。

表 5：四类系统复制横向比较

flowchart TB
    A["客户端确认"] --> P["产品专属复制坐标"]
    P --> PG["PostgreSQL：LSN 阶段"]
    P --> MG["MongoDB：多数提交点"]
    P --> CH["ClickHouse：部件与队列"]
    P --> ES["Elasticsearch：任期与序列号"]
    PG --> G{"允许故障提升？"}
    MG --> G
    CH --> G
    ES --> G
    G -->|"达到业务 RPO"| F["提升并栅栏旧主"]
    G -->|"未达到"| B["保持只读、恢复或人工决策"]
    F --> V["业务版本、删除集合与对账验证"]

图 5 说明：节点从客户端确认分流到四种产品专属坐标，再汇聚到提升门禁和业务验证；箭头只表达判断关系，不表示机制相同。前提是每种产品的确认配置与实际版本已核对。正常路径在满足业务 RPO（恢复点目标）后提升并栅栏旧主；失败路径是拿通用“副本在线”代替位置、提升落后副本或忽略删除集合。业务结论是复制方案必须同时交付确认契约、提升判据、陈旧窗口和旧主防护。

数据演绎 5：同为 20 分钟落后，影响不同。 PostgreSQL（关系型数据库）落后 20 分钟且净缺 35.2 GiB（吉字节） WAL（预写日志），可能影响全部事务；MongoDB（文档数据库）若多数提交点仅落后 2 秒而某只读从节点落后 20 分钟，提升与陈旧读风险不同；ClickHouse（列式数据库）落后 20 分钟可能只缺晚到分析部件，但报表口径不完整；Elasticsearch（搜索引擎）复制已追平而 refresh（刷新）落后 1 秒，写安全与搜索可见又分离。事故看板必须同时展示内部坐标、业务最大版本和受影响查询，不能只放一个“延迟分钟数”。

热门面试题

1. 问题（基础题）：为什么不能用一张主从图解释四种产品？
   • 考点：复制单位和确认语义。
   • 回答思路：逐项指出日志、操作、部件和分片历史差异。
   • 详细答案：四者复制单位、确认条件、进度坐标、选举和可见性边界不同；通用图会掩盖搜索刷新、分析部件和多数提交点等关键事实。
   • 进阶追问：还能保留什么共性？
   • 进阶回答：可统一问确认、复制、提升、旧主、陈旧窗口和验证六个问题，但答案必须回到产品事实。
2. 问题（原理题）：同步确认为什么仍不能保证业务端到端一致？
   • 考点：系统边界。
   • 回答思路：区分数据库副本和外部副作用。
   • 详细答案：同步确认只覆盖配置内副本阶段，搜索、分析、消息、短信和支付渠道不在同一确认链；后者仍需事件、幂等、对账与补偿。
   • 进阶追问：是否应把所有系统放进同步链？
   • 进阶回答：通常会放大延迟和可用性耦合，应保住权威事务，再用可回放异步链证明收敛。
3. 问题（场景题）：只有一个副本最新但校验失败，能否提升？
   • 考点：位置新旧与内容正确性。
   • 回答思路：先隔离并以两类证据判断。
   • 详细答案：不能仅因位置最新就提升；先核对日志连续性和介质校验，再用关键业务版本、金额或库存守恒验证。内容错误可能已被完整复制。
   • 进阶追问：业务必须恢复怎么办？
   • 进阶回答：按风险进入只读或受限写，明确缺口和人工审批，不把未知错误伪装成高可用。

1.6 分片键、路由键与排序键：分治只有在剪枝成立时才提速

分片键决定数据落在哪个容量单元，路由键决定请求应访问哪些单元，排序键决定单个单元内的数据局部性与剪枝；三者可能取同一字段，也可能完全不同。单调递增时间或编号若直接取模前缀或范围分片，会把新写集中到尾部分片；低基数状态字段会造成大块倾斜；只按租户路由会让大租户独占热点。分治提速的前提是查询能根据等值或范围条件裁剪到少量分片，并在分片内利用排序或索引。缺少路由条件时发生广播，跨分片 Join（连接）、全局排序和高基数聚合还要在协调端合并，网络、内存与尾延迟可能超过单机。扩容不是加节点即完成，还要迁移、追赶增量、重建索引或部件并承担临时双份磁盘。

表 6：键选择与失败形态

flowchart LR
    Q["查询条件"] --> R{"能推导路由键？"}
    R -->|"是"| S["命中少量分片"]
    R -->|"否"| B["广播全部分片"]
    S --> O{"排序键或索引可剪枝？"}
    O -->|"是"| P["局部并行提速"]
    O -->|"否"| L["分片内大扫描"]
    B --> A["各分片局部结果"]
    A --> M["协调端 Join、聚合、排序归并"]
    M --> T["网络与尾延迟放大"]

图 6 说明：节点是查询、路由推导、分片内剪枝和协调归并；箭头展示从局部命中或广播到不同成本。前提是统计真实查询形状和租户分布。正常路径由路由键缩小分片，再由排序键或索引减少扫描；失败路径是缺路由条件、低基数倾斜和全局归并。业务结论是分片把容量问题转成路由、倾斜和再平衡问题，不会自动提升所有查询。

sequenceDiagram
    participant W as 写入端
    participant O as 旧分片集合
    participant C as 变更日志
    participant N as 新分片集合
    participant V as 校验与路由
    W->>O: 继续权威写入
    O->>N: 复制全量快照
    O->>C: 记录快照后增量
    C->>N: 按新路由幂等追赶
    N->>N: 重建索引、部件与排序
    V->>O: 计算旧分片摘要
    V->>N: 计算新分片摘要
    alt 校验通过且水位追平
        V->>W: 灰度发布新路由
        W->>N: 新写进入新分片
    else 倾斜或磁盘不足
        V--xW: 阻断切换并保留旧路由
    end

图 7 说明：节点包括写入端、旧分片、增量日志、新分片和校验路由；箭头表示全量与增量并行迁移。前提是新旧路由函数可版本化且删除可传播。正常路径追平、校验后灰度；失败路径是新键仍倾斜、追赶慢或临时磁盘不足。业务结论是重新分片是在线迁移，不是元数据瞬时修改。

数据演绎 6：大租户、广播与临时翻倍。 8 个分片共 2 TiB（太字节），平均 256 GiB（吉字节），但租户 A 占 35% 即约 716.8 GiB（吉字节）；纯租户路由会让其单分片接近平均值 2.8 倍。一次无路由聚合在 8 个分片各返回 100 万分组、每组状态 64 B（字节），协调前原始状态约 488 MiB（兆字节），还未计序列化和哈希开销。扩到 16 分片时旧、新数据及中间索引并存，2 TiB（太字节）净数据可能需要接近 4 TiB（太字节）加恢复余量；若只留 20% 空间，迁移中途会因磁盘水位失败。

热门面试题

1. 问题（基础题）：分片键、路由键和排序键能否混为一谈？
   • 考点：职责边界。
   • 回答思路：分别回答落点、访问范围和局部剪枝。
   • 详细答案：不能。分片键决定容量分布，路由键决定访问哪些分片，排序键改善分片内局部性；同字段只是设计结果，不是定义相同。
   • 进阶追问：为什么常组合时间和散列桶？
   • 进阶回答：时间支持生命周期与范围裁剪，散列桶摊开最新写热点，但查询需知道桶集合成本。
2. 问题（原理题）：分治何时反而更慢？
   • 考点：扇出与归并。
   • 回答思路：从广播、跨分片状态和最慢分片回答。
   • 详细答案：当请求无法裁剪、每片产生大量中间结果或必须全局排序、去重、Join（连接）时，协调网络、内存与最慢分片决定尾延迟，可能超过单节点。
   • 进阶追问：增加分片是否总能提高并行度？
   • 进阶回答：并行度提高同时增加调度、元数据、小文件和归并成本，需用端到端负载验证。
3. 问题（场景题）：发现大租户热点怎么迁移？
   • 考点：确定性分桶与兼容路由。
   • 回答思路：先限流，再版本化新路由并在线迁移。
   • 详细答案：为大租户引入稳定子桶，保留旧路由版本，按全量、增量、校验和灰度顺序迁移；查询在过渡期按版本访问，不能临时随机分散破坏定位。
   • 进阶追问：如何证明不漏数据？
   • 进阶回答：比较每租户每桶计数、主键摘要、删除集合和业务聚合，并回放迁移水位后的增量。

1.7 备份目录：副本、高可用、备份和可恢复性是四个不同命题

副本用于在线冗余，可能同步传播误删；高可用关注故障检测、提升、路由和服务连续；备份是在独立故障域保存可回到历史一致点的材料；可恢复性则要求这些材料能在目标时间内重建业务。完整目录包括逻辑导出、物理基线、文件系统或对象存储快照、连续日志归档、集群元数据、账号权限、密钥、证书、插件、分词词典、外部词典、对象清单与校验和。还要定义保留、不可变或防篡改、加密、跨地域副本、删除与合规证明。快照若依赖存储冻结、一致性协议或仓库注册，必须按产品与版本核对；复制三份但共享同一账号和密钥并不构成独立故障域。

表 7：四个概念的责任边界

表 8：备份目录与验证方式

flowchart TB
    D["在线数据与副本"] --> B["一致性基线"]
    D --> L["连续增量日志"]
    D --> M["集群元数据与权限"]
    D --> K["密钥、证书、插件、词典"]
    B --> O["独立对象存储与跨地域副本"]
    L --> O
    M --> O
    K --> O
    O --> R["隔离环境恢复"]
    R --> C["校验和与业务查询"]
    C --> E["RPO、RTO 与合规证据"]

图 8 说明：节点覆盖在线数据、基线、增量、元数据、密钥依赖、独立存储和恢复证据；箭头表示备份集合必须共同进入恢复。前提是备份账号、加密和跨地域权限独立。正常路径从一致点恢复并做业务查询；失败路径是只备数据不备密钥、日志断档或对象存储权限丢失。业务结论是“任务成功”只证明上传流程运行过，不能证明数据可解密、日志连续和业务可用。

数据演绎 7：保留与跨地域容量。 2 TiB（太字节）全量基线、日增 500 GiB（吉字节），保留 7 天增量至少 3.42 TiB（太字节）；保留两份全量约 4 TiB（太字节），单地域合计约 7.42 TiB（太字节），再做跨地域一份约 14.84 TiB（太字节），尚未计对象版本、索引和校验清单。若日增中 30% 可压缩，必须用真实备份样本测量，不能直接套数据库压缩比。删除合规还要在保留到期后清理对象版本、跨地域副本和密钥引用并留下证明。

热门面试题

1. 问题（基础题）：副本为什么不是备份？
   • 考点：错误传播与历史点。
   • 回答思路：用误删和共享故障域解释。
   • 详细答案：副本通常快速传播当前状态和误删，且共享账号、软件缺陷或故障域；备份要能回到独立历史一致点并受独立权限保护。
   • 进阶追问：多地域副本是否足够？
   • 进阶回答：仍可能同步逻辑错误，必须另有历史保留、不可变策略和恢复演练。
2. 问题（原理题）：逻辑备份和物理备份如何选择？
   • 考点：可移植性、速度和完整性。
   • 回答思路：按规模、版本、对象和恢复时间权衡。
   • 详细答案：逻辑备份便于选择对象和跨版本迁移但恢复慢；物理备份更快且保留存储结构，但兼容与一致性要求更严格，常与连续日志结合。
   • 进阶追问：能否只保留一种？
   • 进阶回答：取决于威胁和目标，关键系统常用物理快速恢复加逻辑抽取和异地独立副本形成互补。
3. 问题（场景题）：对象存储快照存在却无权限怎么办？
   • 考点：控制面灾难。
   • 回答思路：先保留证据并启用独立应急身份。
   • 详细答案：确认是账号、策略、网络还是密钥问题，使用预演过的最小权限应急身份只读恢复；若没有独立身份，备份在事故时等同不可用，应计入 RTO（恢复时间目标）违约。
   • 进阶追问：恢复后如何修复？
   • 进阶回答：重建跨账号权限、轮换凭据、验证审计，并把权限丢失纳入定期演练。

1.8 RPO（恢复点目标）、RTO（恢复时间目标）与恢复一致性点必须由证据证明

RPO（恢复点目标）描述最多可丢失多长时间或多少业务变更，RTO（恢复时间目标）描述从灾难确认到关键业务恢复所允许的时间。恢复一致性点是数据基线与连续日志能共同重放到的明确位置；PITR（时间点恢复）是在连续日志和一致基线之上选择目标时间，而不是任意输入时间就能成功。恢复演练必须在隔离环境校验介质、解密、版本、插件、元数据、日志连续性、校验和、行数、业务聚合和关键查询；还要验证删除已按合规范围生效。技术恢复完成不等于业务恢复：WMS（仓储管理系统）要验证库存守恒，支付要验证借贷与渠道对账，物流要验证轨迹版本，搜索和分析派生层可在权威源后重建。

表 9：恢复目标与证据

sequenceDiagram
    participant I as 事故指挥
    participant B as 基线备份
    participant L as 连续日志
    participant R as 隔离恢复环境
    participant V as 技术与业务校验
    I->>B: 选择灾难前一致基线
    B->>R: 恢复数据、元数据与配置
    I->>L: 选择目标时间或位置
    L->>R: 连续重放到停止点
    R->>V: 提交校验和、行数与日志
    V->>V: 执行库存、账务、轨迹查询
    alt 全部证据通过
        V-->>I: 宣布达到 RPO 与 RTO
    else 日志断档或业务不变量失败
        V--xI: 禁止切换并定位缺口
    end

图 9 说明：节点是事故指挥、基线、连续日志、隔离环境和校验；箭头表示选择一致点、恢复与验证顺序。前提是时间同步、日志保留和停止条件明确。正常路径重放到目标点后通过技术与业务证据；失败路径是日志断档、基线损坏或恢复后金额与库存不守恒。业务结论是 PITR（时间点恢复）恢复的是可证明状态，不是一个看起来接近的时间戳。

flowchart LR
    S["备份任务成功"] --> M{"介质可读且校验和正确？"}
    M -->|"否"| F["备份不可用"]
    M -->|"是"| K{"密钥、插件、元数据齐全？"}
    K -->|"否"| F
    K -->|"是"| L{"日志连续并能停止到目标点？"}
    L -->|"否"| F
    L -->|"是"| Q{"业务查询和不变量通过？"}
    Q -->|"否"| F
    Q -->|"是"| R["形成可恢复证据"]

图 10 说明：节点把任务成功依次送入介质、依赖、日志和业务门禁；箭头表示任一失败都不能声称可恢复。前提是验证在独立环境执行。正常路径形成带耗时和结果的证据；失败路径包括快照损坏、密钥缺失、日志断档和查询校验失败。业务结论是恢复能力是一条链，最弱环节决定结果。

数据演绎 8：1 Gbit/s（吉比特每秒）链路与演练超时。 2 TiB（太字节）全量在理想 1 Gbit/s（吉比特每秒）链路上，按 125 MB/s（兆字节每秒）计算至少约 4.66 小时；若有效利用率 70%，约 6.65 小时。再加解密 1 小时、日志重放 2 小时、索引重建 3 小时和业务校验 1.5 小时，总计约 14.15 小时，无法满足 8 小时 RTO（恢复时间目标）。止血不是删掉校验，而是提高并行恢复能力、准备近线基线、缩短日志链、把派生索引延后并将关键业务分级恢复；下一次演练必须记录每阶段实际耗时。

热门面试题

1. 问题（基础题）：RPO（恢复点目标）与 RTO（恢复时间目标）分别回答什么？
   • 考点：数据损失与恢复时长。
   • 回答思路：用最后位置和恢复计时边界说明。
   • 详细答案：RPO（恢复点目标）限制灾难后最多丢失的变更，RTO（恢复时间目标）限制关键业务恢复耗时；一个看数据位置，一个看服务时间线。
   • 进阶追问：零 RPO（恢复点目标）是否必然零 RTO（恢复时间目标）？
   • 进阶回答：不是，数据无丢失仍可能因提升、校验、路由和依赖恢复耗时很长。
2. 问题（原理题）：为什么恢复要做业务查询？
   • 考点：物理完整与业务正确差异。
   • 回答思路：举库存和账务不变量。
   • 详细答案：校验和只证明字节或对象一致，无法证明跨表库存守恒、借贷平衡、删除范围和状态版本正确；业务查询是第二类独立证据。
   • 进阶追问：抽样够不够？
   • 进阶回答：抽样用于快速发现问题，关键总量和业务聚合应全量校验；高风险对象还需定向逐笔核对。
3. 问题（场景题）：恢复演练超过 RTO（恢复时间目标）如何改进？
   • 考点：阶段耗时与分级恢复。
   • 回答思路：定位瓶颈并保护验证门禁。
   • 详细答案：拆分下载、解密、重放、重建和校验耗时，优化最大瓶颈；先恢复权威写与关键查，搜索分析后置，预热自动化和近线基线，但不能省略一致性验证。
   • 进阶追问：是否应直接提高目标？
   • 进阶回答：只有业务确认成本可接受才调整；否则目标不是文档数字，而是必须投入资源兑现的承诺。

2. 迁移状态机、灾难路径与项目边界

1.9 在线迁移状态机：两个状态机要在有限窗口内证明等价

在线迁移先冻结模型、事件身份、删除语义和业务不变量，再取得有明确增量起点的全量快照；快照装载期间持续保留日志或 CDC（变更数据捕获），目标端以稳定业务键和版本幂等应用新增、更新与删除。水位追平不是只看时间，还要比较源位置、目标已应用位置、毒数据队列与重试。校验分三层：行数和主键集合发现缺失，校验和发现字段差异，库存、金额、轨迹状态等全量业务聚合证明领域等价；抽样用于快速反馈但不能代替关键全量聚合。之后影子读比较真实查询，灰度切流控制爆炸半径，观察通过才停旧写并应用最终增量。回滚窗口内保留旧库、反向增量和外部副作用对账能力，最后才下线。

表 10：在线迁移状态与门禁

stateDiagram-v2
    [*] --> 模型与不变量冻结
    模型与不变量冻结 --> 全量快照
    全量快照 --> 增量追平
    增量追平 --> 校验
    校验 --> 增量追平: 差异或毒数据
    校验 --> 影子读: 行数 校验和 业务聚合通过
    影子读 --> 灰度切流
    灰度切流 --> 回滚: 指标或不变量失败
    回滚 --> 增量追平
    灰度切流 --> 停旧写: 观察通过
    停旧写 --> 回滚窗口
    回滚窗口 --> 旧系统下线: 最终证据通过
    旧系统下线 --> [*]

图 11 说明：节点是迁移各状态，箭头表示门禁通过、失败回退和最终下线。前提是每个状态都有可重入检查点。正常路径从冻结到下线单向推进；失败路径在校验、灰度或观察阶段返回追平或回滚。业务结论是迁移不是一次复制命令，而是可暂停、可验证、可逆的状态机。

sequenceDiagram
    participant S as 源系统
    participant F as 全量快照
    participant C as CDC 增量
    participant T as 目标系统
    participant V as 校验平台
    participant R as 影子读与路由
    S->>F: 在位置 L0 取得一致全量
    S->>C: 从 L0 持续记录变更
    F->>T: 幂等装载全量
    C->>T: 应用新增 更新 删除
    T-->>V: 报告目标水位与失败批次
    V->>S: 计算源摘要和业务聚合
    V->>T: 计算目标摘要和业务聚合
    alt 水位与校验通过
        R->>S: 生产读
        R->>T: 同查询影子读
        R->>T: 灰度切换
        R->>S: 停旧写并取最终位置
        C->>T: 应用最终增量
    else 复制落后或校验失败
        V--xR: 阻断切流
        V->>T: 定向回放并重新校验
    end

图 12 说明：节点分别承担源、全量、增量、目标、校验和路由；箭头强调全量与增量从同一位置衔接。前提是源日志覆盖整个迁移窗口。正常路径校验后影子读、灰度和停旧；失败路径是落后、日志断档或校验失败时阻断切流。业务结论是水位追平和业务等价必须同时满足，任何一项都不能被“行数相同”替代。

数据演绎 9：2 TiB（太字节）全量与日增 500 GiB（吉字节）。 1 Gbit/s（吉比特每秒）链路有效 70% 时，全量约 6.65 小时；日增 500 GiB（吉字节）约等于平均 5.93 MiB（兆字节）/s（每秒），但高峰按平均 5 倍约 29.65 MiB（兆字节）/s（每秒）。若全量导入占用 80 MiB（兆字节）/s（每秒），增量应用只有 20 MiB（兆字节）/s（每秒），高峰会持续落后；应给增量优先级、全量限速并按剩余位置估算追平。校验先抽样 1% 快速暴露字段问题，再对主键集合、删除集合、每日金额和库存守恒做全量聚合；抽样全过仍不能替代全量门禁。

热门面试题

1. 问题（基础题）：为什么全量快照必须绑定增量起点？
   • 考点：一致性接缝。
   • 回答思路：解释快照期间仍有写入。
   • 详细答案：没有明确起点就无法判断快照之后哪些新增、更新和删除应重放，可能漏变更或重复应用；基线与日志必须在同一一致性位置接合。
   • 进阶追问：能否先全量结束再开增量？
   • 进阶回答：在线写入期间会形成不可恢复空窗，除非业务接受停写并明确记录边界。
2. 问题（原理题）：为何行数一致仍不能切流？
   • 考点：内容与业务语义。
   • 回答思路：举字段错位、删除遗漏和聚合抵消。
   • 详细答案：一行缺失与一行重复可抵消计数，字段映射错误也不改行数；必须比较主键集合、校验和、删除集合和业务不变量。
   • 进阶追问：全量逐行比较是否最好？
   • 进阶回答：成本常过高，可按稳定分桶做摘要与关键字段全量聚合，对差异桶再逐行定位。
3. 问题（场景题）：切流后发现目标写错误如何回滚？
   • 考点：反向增量与外部副作用。
   • 回答思路：先停新写、固定水位，再分类可逆性。
   • 详细答案：取得目标最终水位，暂停入口，把切流后可逆业务变更按幂等键反向补回旧库并校验，再恢复旧路由；支付通知等外部副作用只能对账或冲正。
   • 进阶追问：为何保留旧库只读不够？
   • 进阶回答：没有反向同步，旧库缺切流后新写，直接回切会丢数据。

1.10 双写与异构同步：成功两次不等于一个原子事实

应用双写通常是先后调用两个独立系统，没有共同原子提交：第一边成功、第二边失败会分叉；第二边成功但响应丢失会产生未知结果；重试可能重复，跨线程和网络可能乱序。更稳妥的入口是先在权威事务中写业务状态与 Outbox（发件箱）事件，或从数据库日志产生 CDC（变更数据捕获），再把稳定事件身份、业务版本和删除墓碑投影到目标。同步器必须定义分区顺序、幂等键、断点、字段模式版本、旧新字段兼容、毒数据隔离、限次重试、回放、校验、补偿和对账。删除最容易被遗漏：只同步当前行会让目标残留已删除对象；外部支付、短信和仓库操作不可凭日志简单回放，必须用渠道查询、冲正或人工审核。

表 11：异构同步契约

sequenceDiagram
    participant A as 应用
    participant S as 权威数据库
    participant O as Outbox 或 CDC
    participant T as 搜索或分析目标
    participant V as 校验与对账
    A->>S: 写业务状态与稳定事件身份
    S->>O: 同一事务记录待投影事实
    S-->>A: 权威提交确认
    O->>T: 按实体顺序幂等应用
    alt 目标成功但响应丢失
        T--xO: 返回未知
        O->>T: 用同事件键查证或重试
        T-->>O: 返回既有版本
    else 字段不兼容或毒数据
        T--xO: 拒绝并记录原因
        O->>O: 隔离毒数据并推进其他分区
        O->>T: 修复后从断点回放
    end
    V->>S: 读取权威摘要与删除集合
    V->>T: 对账目标版本与聚合

图 13 说明：节点为应用、权威库、事件来源、异构目标和校验；箭头展示权威提交后异步投影。前提是事件与业务状态同事务或可证明关联。正常路径按版本幂等应用；失败路径覆盖未知结果、字段演进、毒数据和删除遗漏。业务结论是应用双写没有天然无丢失、无重复保证，可回放权威事件和持续对账才构成闭环。

数据演绎 10：双写分叉、字段变更与删除。 10000 次库存更新中，先写权威库全部成功，直接写搜索有 0.2% 超时，即 20 次未知；若全部换新事件键重试且其中 15 次实际已成功，会制造 15 次重复。当天新增字段 warehouse_zone，旧目标映射拒绝 200 条；同时删除 50 个商品若未传墓碑，目标总数可能看似只差 235 条，却混有重复、缺失和残留。正确做法是同事件键查证，隔离 200 条待兼容映射后回放，全量比较版本与删除集合，并用可售库存聚合对账。

热门面试题

1. 问题（基础题）：应用双写为何不是天然可靠？
   • 考点：独立提交与未知结果。
   • 回答思路：列出一边成功、超时和重试重复。
   • 详细答案：两个系统没有共同事务，任一调用之间崩溃都会分叉；超时无法判断目标是否已提交，换新键重试又会重复，所以必须有权威源、稳定事件和对账。
   • 进阶追问：把调用顺序反过来有用吗？
   • 进阶回答：只会改变哪一边更容易残留，不能消除原子性缺口。
2. 问题（原理题）：删除为什么比新增更难同步？
   • 考点：事实消失与历史保留。
   • 回答思路：说明快照看不到已删对象。
   • 详细答案：新增可从当前状态发现，删除后源行已消失，若无墓碑或日志，目标残留无法从普通快照识别；合规删除还涉及备份与对象版本。
   • 进阶追问：软删除是否解决一切？
   • 进阶回答：只保留传播线索，仍要定义何时物理清理、备份到期和删除证明。
3. 问题（场景题）：一条毒数据堵住分区怎么办？
   • 考点：顺序与可用性权衡。
   • 回答思路：隔离但保留同实体顺序边界。
   • 详细答案：记录原事件、模式、错误和断点，把毒数据及依赖它的同实体后续隔离，允许无关分区推进；修复转换后按原顺序定向回放并对账。
   • 进阶追问：能直接跳过吗？
   • 进阶回答：不能静默跳过，必须形成缺口告警、负责人和截止时间，否则最终一致永远不收敛。

1.11 灾难路径：两类独立证据、止血、修复与演练缺一不可

灾难处置先确认业务影响和权威源，再用至少两类独立证据定性：产品内部位置、任期、队列、校验和是一类，主机存储、对象审计、业务版本、渠道对账是另一类。复制延迟先保护日志与权威写；旧主复活先网络、账号和业务任期三层栅栏；快照损坏切换到独立副本并保留坏样本；日志断档停止声称 PITR（时间点恢复）；对象存储权限丢失启用独立应急身份；密钥缺失意味着备份不可解密；校验失败阻断切流；切流后回滚先固定双边水位；外部副作用不可回放时必须查渠道、冲正和人工对账。演练要注入真实失败，而不是只验证正常脚本。

表 12：八类灾难闭环

表 13：演练通过门槛

flowchart TB
    I["发现灾难"] --> A["确认影响与权威源"]
    A --> E1["产品证据：位置 任期 队列 校验"]
    A --> E2["独立证据：主机 对象审计 业务对账"]
    E1 --> J{"两类证据是否一致？"}
    E2 --> J
    J -->|"是"| S["执行可回滚止血"]
    J -->|"否"| Q["隔离写入并扩大取证"]
    S --> R["修复根因"]
    R --> V["恢复校验与业务回归"]
    V --> D["复盘并转为故障注入演练"]

图 14 说明：节点从事故影响进入两类证据、判断、止血、修复和演练；箭头体现证据冲突时先隔离。前提是权威源和事故指挥角色明确。正常路径证据一致后止血并回归；失败路径是单指标误判或边修边破坏现场。业务结论是高可用动作必须由证据驱动，恢复验证必须回到业务不变量。

sequenceDiagram
    participant C as 客户端
    participant O as 旧主
    participant N as 新主
    participant F as 栅栏与路由
    participant V as 业务校验
    O--xN: 网络分区导致旧主失联
    N->>N: 满足提升条件并增加任期
    F->>C: 路由新写到新主
    C->>N: 携带新任期写入
    O->>F: 旧主复活请求恢复入口
    F--xO: 网络与账号拒绝
    C->>O: 缓存旧地址的请求
    O--xC: 业务版本或任期拒写
    O->>N: 隔离后重绕或重建
    V->>N: 校验缺口与重复副作用

图 15 说明：节点覆盖客户端、旧主、新主、栅栏和业务校验；箭头展示提升后旧主复活。前提是控制面与业务写均携带可比较任期。正常路径新主服务、旧主被隔离后重建；失败路径是客户端缓存旧地址或账号仍有效形成双写。业务结论是旧主防护必须有基础设施和业务条件更新两道门。

数据演绎 11：快照损坏、密钥缺失与回滚。 三份 2 TiB（太字节）快照中同账号两份可读但其中一份校验失败，跨账号第三份权限被撤销；恢复到 40% 时又发现加密密钥版本缺失。此时不是“还有三份备份”，而是零份已证明可恢复材料。立即冻结生命周期删除、保留对象与审计，恢复跨账号只读权限并找回受双控制保护的密钥；若仍失败，按最后有效基线和日志端点声明真实 RPO（恢复点目标）。迁移切流后回滚则先停目标写，反向补 2300 条可逆订单状态，支付通知 17 条通过渠道查询和人工对账，禁止日志重放再次扣款。

热门面试题

1. 问题（基础题）：为什么事故需要两类独立证据？
   • 考点：相关失真与误判。
   • 回答思路：产品指标和业务结果互证。
   • 详细答案：同一监控链可能同时失真，产品位置正常也可能复制了错误；用对象审计、主机或业务聚合交叉，才能区分观测故障、介质故障和逻辑污染。
   • 进阶追问：两类证据冲突怎么办？
   • 进阶回答：先限制写和爆炸半径，保留现场并增加第三类证据，不仓促提升或覆盖备份。
2. 问题（原理题）：旧主防护为什么需要业务版本？
   • 考点：控制面绕过。
   • 回答思路：说明旧连接和缓存路由。
   • 详细答案：网络和服务发现可能短时陈旧，旧客户端仍能触达旧主；关键条件更新携带任期或版本，可在最后一道写路径拒绝旧历史。
   • 进阶追问：只靠业务版本够吗？
   • 进阶回答：不够，仍要网络、账号和存储隔离，避免旧主消耗资源或写入不受版本保护的数据。
3. 问题（场景题）：密钥缺失时能否重新加密现有备份？
   • 考点：解密前提。
   • 回答思路：先说明没有旧密钥无法读取明文。
   • 详细答案：不能凭新密钥直接转换无法解密的密文；应从受控密钥备份、托管审计或其他可恢复数据副本找回，再恢复后轮换，且保留取证。
   • 进阶追问：如何预防？
   • 进阶回答：密钥独立备份、双控制、轮换兼容、恢复演练和生命周期联动，删除数据时再按策略销毁密钥。

1.12 四类产品迁移案例：可回放状态与不可回放副作用必须分开

PostgreSQL（关系型数据库）到搜索或分析投影，应以事务日志或 Outbox（发件箱）为权威事件，先全量再从 LSN（日志序列号）追增量，搜索文档和分析行可重建，支付、短信、仓库动作不可重放。MongoDB（文档数据库）分片扩容要版本化分片键和路由，处理大租户、数据块迁移、孤儿数据与路由缓存，文档状态可按 oplog（操作日志）重放，已调用第三方轨迹接口需对账。ClickHouse（列式数据库）集群换代要冻结表定义、排序键、分区与字典，复制或导入数据部件并重放增量，聚合可重算，已导出的客户文件需核对版本。Elasticsearch（搜索引擎）重建索引用新索引全量装载、持续增量、查询校验和原子别名切换，索引可重建，用户已看到并据此执行的业务动作不能撤回。

表 14：产品迁移案例与回放边界

flowchart LR
    PG["PostgreSQL 权威事务"] -->|"LSN 后事件"| SE["搜索投影"]
    PG -->|"同源事件"| AN["分析投影"]
    MG["MongoDB 原分片"] -->|"快照加 oplog"| MN["新分片路由"]
    CH["ClickHouse 旧集群"] -->|"部件加增量"| CN["新集群"]
    ES["Elasticsearch 旧索引"] -->|"全量加投影事件"| EN["新索引"]
    SE --> V["版本 删除 聚合 查询校验"]
    AN --> V
    MN --> V
    CN --> V
    EN --> V
    V --> X["外部副作用进入人工或渠道对账"]

图 16 说明：节点分别表示四类迁移源、目标、统一校验和外部副作用；箭头标出各自全量与增量来源。前提是每个目标都不是新的未定义权威源。正常路径可回放数据通过版本、删除和查询校验；失败路径是把短信、支付或已交付文件当普通事件重复播放。业务结论是迁移恢复数据状态，外部世界的既成事实必须单独对账。

数据演绎 12：四种迁移的共同门禁。 PostgreSQL（关系型数据库）源 1 亿订单投影到搜索时，抽样 100 万条全过，但全量按日聚合发现某天少 20000 条删除墓碑；MongoDB（文档数据库）扩到 16 分片后大租户仍占一个分片 38%；ClickHouse（列式数据库）新集群总行数一致但金额聚合差 0.03%；Elasticsearch（搜索引擎）新索引文档数一致却有 1200 条旧版本覆盖。四者都不能切流。分别补墓碑、重设大租户子桶、定位精度或重复口径、按业务版本重放后，再做影子读和故障回滚演练。

热门面试题

1. 问题（基础题）：数据库到搜索投影谁是权威源？
   • 考点：可重建边界。
   • 回答思路：用库存与运单裁决解释。
   • 详细答案：承担事务约束和业务版本的数据库或事件日志是权威源，搜索索引用于召回和排序，可从权威事件重建，不能反向裁决库存或资金。
   • 进阶追问：搜索特有字段怎么办？
   • 进阶回答：记录生成规则与版本，把可计算字段重建；人工运营字段要另设权威存储和同步契约。
2. 问题（原理题）：重建索引为何常比原地修改安全？
   • 考点：隔离、校验与回滚。
   • 回答思路：说明新旧索引并存和别名切换。
   • 详细答案：新索引可使用新映射独立全量与增量，在不影响生产读的情况下影子校验；切换只是路由动作，旧索引保留回滚窗口。
   • 进阶追问：代价是什么？
   • 进阶回答：需要双份磁盘、全量读取、增量追平和切换后双边水位治理。
3. 问题（场景题）：ClickHouse（列式数据库）换代后报表金额差 0.03% 怎么办？
   • 考点：口径、精度与重复。
   • 回答思路：按分区和维度缩小差异桶。
   • 详细答案：阻断切流，比较表定义、数值类型、时区、去重、物化规则和迟到水位；按日期租户分桶定位，再从权威明细重算，不能用“分析允许误差”直接豁免。
   • 进阶追问：何时可接受误差？
   • 进阶回答：只有业务预先定义近似算法、误差预算和展示口径，且差异来源可解释时才接受。

1.13 项目恢复顺序、业务不变量、设计思想与版本核对卡

项目先恢复权威事实，再恢复可回放派生层。WMS（仓储管理系统）库存以库存流水、预占与条件更新为权威，不变量是可用、占用和实物口径守恒；跨境物流以运单与轨迹事件版本为权威，搜索和分析可重建；支付以不可变账务流水、渠道单号和对账为权威，任何回放不得再次扣款；异步导出以任务状态、分片清单和源查询水位为权威，文件可重建但已发送链接需核对；Runner（执行器）以任务、租约、任期和执行结果为权威，恢复后拒绝旧租约；IoT（物联网）以可回放遥测和报警状态迁移为权威，聚合与搜索可重算，已发通知需去重。设计上，复制、分片、备份和迁移分别把原问题转成确认提升、路由再平衡、验证恢复和有限窗口等价证明。

表 15：项目权威源与恢复顺序

flowchart TB
    A["灾难后恢复入口"] --> W["第一层：库存、账务、运单、任务、遥测权威事实"]
    W --> I{"业务不变量通过？"}
    I -->|"否"| H["保持只读或受限写并人工对账"]
    I -->|"是"| D["第二层：当前状态、余额、租约与报警状态"]
    D --> P["第三层：搜索、分析、聚合、导出文件"]
    P --> E["第四层：通知与外部副作用核对"]
    E --> O["灰度开放完整业务"]

图 17 说明：节点按权威事实、业务状态、派生层和外部副作用分层；箭头表示恢复依赖顺序。前提是每个项目已声明权威源和不变量。正常路径先验证账本再重建搜索分析；失败路径是不变量未通过仍开放写，或重放通知造成二次副作用。业务结论是恢复优先级由不可替代性和资损风险决定，不由产品启动速度决定。

数据演绎 13：六项目联合恢复。 灾难点后库存有 1200 条预占、支付有 17 笔渠道结果待对账、物流有 8000 条轨迹增量、Runner（执行器）有 36 个租约未过期、IoT（物联网）有 200 万条遥测待重算、异步导出有 48 个文件未完成。先恢复库存与支付权威流水并冻结 17 笔重复扣款风险，再恢复运单事件和任务任期；旧 Runner（执行器）任期全部拒绝提交。遥测以批次重算聚合，搜索与导出最后重建。若先开放搜索和通知，用户会看到陈旧库存且可能收到重复支付或报警消息。

产品版本敏感实现核对卡

版本卡必须记录核对日期、准确版本、官方章节、最小复现实验、适用边界、升级与回退条件；本文不把任何默认值写成跨版本永久事实。

热门面试题

1. 问题（基础题）：灾难后为什么先恢复权威源？
   • 考点：依赖与可重建性。
   • 回答思路：区分不可替代账本和派生视图。
   • 详细答案：搜索、分析、缓存和文件能从权威事实重建，反过来通常不能恢复事务约束、完整版本和资金证据；先恢复派生层会放大陈旧和错误。
   • 进阶追问：搜索先启动更快怎么办？
   • 进阶回答：可用于受限浏览但必须标注水位并禁止业务裁决，直到权威源和不变量通过。
2. 问题（原理题）：迁移为何是两个状态机证明等价？
   • 考点：并发变化与有限窗口。
   • 回答思路：从全量基线、增量和切流说明。
   • 详细答案：源和目标在迁移中都持续变化，只有把同一业务事件、版本、删除和不变量映射到共同水位，才能证明某个窗口内状态等价并安全切换。
   • 进阶追问：完全字节相同才等价吗？
   • 进阶回答：异构系统物理结构不同，等价应由业务键、字段语义、查询结果和不变量定义。
3. 问题（场景题）：恢复 IoT（物联网）报警时如何避免通知风暴？
   • 考点：状态重算与外部副作用。
   • 回答思路：先重建状态，再按通知身份去重。
   • 详细答案：回放遥测只重算报警状态和窗口，不直接重发通知；以规则版本、报警实例和状态迁移查既有发送记录，仅对仍有效且未通知的严重报警补发。
   • 进阶追问：历史普通报警怎么办？
   • 进阶回答：保留在审计和查询中，通常不补发过期通知，具体按业务时效和合规策略决定。

题库边界

以上 13 个知识型三级标题对应 39 道六字段题；本标题只终止章节题扫描范围，不属于知识型三级标题。以下综合题独立计数。

3. 综合口述题库

1. 问题：请横向解释四类系统从客户端确认到故障恢复的差异。

   • 口述答案：我不会用一张通用主从图概括，而是逐一回答确认、复制单位、进度坐标、提升和可见性。PostgreSQL（关系型数据库）让提交 WAL（预写日志）达到本地要求；同步复制还等待指定副本的接收、写入、刷新或应用阶段，用 LSN（日志序列号）比较，提升后旧主必须隔离并重绕。MongoDB（文档数据库）由主节点写 oplog（操作日志），写关注决定等待成员，多数提交点与选举任期约束安全历史，少数写可能回滚。ClickHouse（列式数据库）形成不可变数据部件，由 Keeper（协调服务）登记复制任务，其他副本拉取，分析新鲜度看部件队列和业务时间。Elasticsearch（搜索引擎）由主分片分配序列号、写事务日志并复制，主分片任期防旧主，但写确认后仍需 refresh（刷新）才可搜索。共同点只是复制把单点失败转为确认和提升问题；同步或多数确认不覆盖搜索投影、分析副本与外部通知。事故时我会同时取内部位置和业务最大版本两类证据，再按 RPO（恢复点目标）决定提升、只读或恢复，最后以删除集合和业务不变量验收。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：哪个确认最强？
   • 直接回答：不能脱离配置和故障假设排名，要先说明等待阶段与系统边界。
   • 追问：写成功都能立即读到吗？
   • 直接回答：不能，副本应用、读路由和搜索刷新都有独立窗口。
   • 追问：旧主防护原则是什么？
   • 直接回答：隔离旧入口，并以新任期或业务版本拒绝旧历史。
   • 详情：复制横向比较

2. 问题：PostgreSQL（关系型数据库）复制延迟 20 分钟怎样判断能否提升？

   • 口述答案：先比较主库当前、发送、备库接收、刷新和重放 LSN（日志序列号），再看位置时间戳，区分网络、刷新、重放或长查询阻塞。若 WAL（预写日志）生成 80 MiB（兆字节）/s（每秒）、重放 50 MiB（兆字节）/s（每秒），20 分钟净缺约 35.2 GiB（吉字节）；异步确认下贸然提升可能丢这段已确认事务。第二类证据看库存最后预占号、支付最后渠道单号和运单最后事件版本，确认真实业务缺口。还要核查日志保留是否覆盖、备库能否连续追赶、介质校验是否通过。止血先保护 WAL（预写日志），暂停副本报表与低优先级批量，支付查单和库存裁决回主库；主库不可用时，由事故负责人按 RPO（恢复点目标）选择等待、只读或带已知损失提升。提升后增加历史任期，隔离旧主网络与账号，客户端以业务幂等键查证未知结果，再以账务、库存守恒和日志位置验证。旧主只能隔离重绕或重建，不能凭原角色恢复服务；追平后也要灰度放回读流量，避免缓存回暖和长查询让副本再次落后。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：位置差归零就能恢复读吗？
   • 直接回答：还要验证业务版本、重放稳定和查询负载。
   • 追问：日志被回收怎么办？
   • 直接回答：连续追赶已破坏，应从新物理基线重建。
   • 追问：同步复制还会延迟吗？
   • 直接回答：会，接收、应用和读可见阶段仍可能落后。
   • 详情：PostgreSQL（关系型数据库）复制

3. 问题：MongoDB（文档数据库）多数确认后为什么还要处理未知结果和回滚？

   • 口述答案：多数确认只约束副本集内约定成员，不替客户端保存响应，也不包含外部系统。主节点可能已把版本 108 推进多数提交点，但客户端在响应前断线；若把超时当失败并换新事件标识重试，就会重复轨迹或库存动作。正确方式是用租户、对象、渠道事件号和版本组成稳定幂等键，先查权威状态：存在则返回既有结果，不存在才重试，仍未知则进入补偿。回滚是另一边界：旧主孤立期间未进入安全历史的少数写，在新任期后可能移出主历史。事故要保存任期、oplog（操作日志）位置、多数提交点与回滚记录，并从上游事件日志、渠道回执或业务流水取第二类证据。恢复按稳定事件身份补写权威事实，再重建当前状态、搜索和分析，不能只手改最终文档。读取也不能因使用从节点就称强一致；读关注、读偏好、会话约束和应用进度共同决定陈旧窗口。最终比较事件唯一数、版本连续性、删除墓碑、终态与聚合，而非只看文档总数。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：多数确认是否绝不丢写？
   • 直接回答：只在明确配置和故障假设内提供保证，跨系统仍无保证。
   • 追问：回滚记录可直接重放吗？
   • 直接回答：先与业务幂等键和上游权威事件核对。
   • 追问：从节点落后影响什么？
   • 直接回答：影响陈旧读和候选安全性，两者要分别判断。
   • 详情：MongoDB（文档数据库）副本集

4. 问题：ClickHouse（列式数据库）副本恢复为什么放大网络、磁盘和查询延迟？

   • 口述答案：复制表恢复以补齐数据部件和复制任务为核心。副本离线 20 分钟、高峰写入 100 MiB（兆字节）/s（每秒）时约缺 117 GiB（吉字节），恢复还与持续新写和后台合并竞争。网络有效 250 MiB（兆字节）/s（每秒）、复制得到 150 MiB（兆字节）/s（每秒），新数据仍以 100 MiB（兆字节）/s（每秒）进入，净追赶仅 50 MiB（兆字节）/s（每秒），约 40 分钟才追平。磁盘不只增加 117 GiB（吉字节）：下载临时文件、正式部件、旧部件与合并输出可能共存，空间短时接近净数据两倍。若日增 500 GiB（吉字节）却以 10 MiB（兆字节）小部件写入，每天约 51200 个任务，队列与元数据压力更大。止血暂停低优先级回填和大查询，协调合并与复制配额，保留健康副本并扩容临时空间；查询返回最大业务时间，对财务报表暂停或回源。修复后不仅看队列归零，还比较部件校验和、分区行数、金额聚合和真实查询，防止错误部件被一致复制。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：Keeper（协调服务）正常代表数据安全吗？
   • 直接回答：不代表，它保存协调事实，不保存全部业务列文件。
   • 追问：能删旧部件腾空间吗？
   • 直接回答：所有权和合并状态不明时不能直接删除。
   • 追问：何时恢复报表？
   • 直接回答：水位、聚合与查询回归通过后灰度恢复。
   • 详情：ClickHouse（列式数据库）复制

5. 问题：Elasticsearch（搜索引擎）写确认、持久化和搜索可见如何区分？

   • 口述答案：一次索引写至少有三个时点。第一是写确认：主分片分配 seq_no（序列号），写内存与 translog（事务日志），按活动副本策略复制后响应。第二是故障恢复边界：事务日志、分片历史和副本状态决定节点故障后能否恢复，具体持久化行为按现场版本核对。第三是搜索可见：refresh（刷新）把变化形成新的可搜索 Lucene（全文检索库）分段后，普通搜索才命中新版本。因此 10:00:00.120 写成功、10:00:00.300 仍见旧版、10:00:01.150 刷新后可见，是合理近实时窗口，不应误判丢失。主分片故障后，有效副本提升并增加 primary_term（主分片任期），旧任期写被拒绝，但提升不消除刷新延迟。项目中搜索只做商品、运单和报警投影，库存与支付裁决回权威数据库。读己之写要用明确实时获取或回源，并携带源业务版本；重建索引用全量、增量、删除集合、影子查询和别名切换，旧索引保留回滚窗口。这样把产品内部恢复与业务正确性分开，不让“搜不到”触发重复业务动作。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：强制刷新解决一致性吗？
   • 直接回答：只缩短搜索可见窗口，并增加小分段与合并成本。
   • 追问：主分片任期等于业务版本吗？
   • 直接回答：不等于，二者分别保护分片历史和领域状态。
   • 追问：搜索能裁决库存吗？
   • 直接回答：不能，必须查询权威事务状态。
   • 详情：Elasticsearch（搜索引擎）复制

6. 问题：如何选择不会制造热点的分片键？

   • 口述答案：先收集写入分布、查询形状、租户大小、增长和生命周期，再区分分片键、路由键与排序键。单调时间或订单号做范围分片会把新写集中尾片；状态字段低基数会形成大块倾斜；只按租户虽能局部查询，却会让占 35% 数据的大租户独占热点。常用租户加稳定子桶，或时间分区加散列桶：前者控制大租户，后者兼顾时间裁剪与写入摊平，但查询必须推导桶集合。题设 2 TiB（太字节）分 8 片平均 256 GiB（吉字节），租户 A 约 716.8 GiB（吉字节），是平均 2.8 倍，应独立分桶并版本化路由。迁移按一致快照、增量日志、幂等应用、每桶主键摘要和业务聚合、灰度路由进行，过渡查询按路由版本访问。还要注入节点故障和临时磁盘不足，证明扩容时新旧数据、索引与合并输出共存仍有余量。最终标准不是单一均匀度，而是关键查询可裁剪、热点受控、删除能传播且重新分片可执行。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：随机散列最均匀吗？
   • 直接回答：可能更均匀，但范围和租户查询会广播。
   • 追问：分片键能直接修改吗？
   • 直接回答：通常等价于重新分片迁移。
   • 追问：如何提前发现大租户？
   • 直接回答：监控字节、写率、查询率和增长斜率并做准入。
   • 详情：分片设计

7. 问题：为什么分片后查询可能比单机更慢？

   • 口述答案：分片提速依赖路由裁剪和片内剪枝。缺少租户、主键或时间条件时，协调节点广播所有分片；每片局部过滤、聚合和排序，再通过网络返回中间结果。跨分片 Join（连接）、全局去重、深分页和高基数聚合更昂贵，因为局部结果不是最终答案，协调端要维护大哈希表或优先队列，尾延迟由最慢分片决定。8 个分片各返回 100 万个状态、每个 64 B（字节），仅原始状态约 488 MiB（兆字节），序列化和哈希开销还会放大；某片因大租户慢 3 倍，其他片完成也不能提前返回。解决顺序是先改查询契约，要求路由或时间范围；再做片内预聚合、限制分组基数、把小维表广播或将 Join（连接）前置；必须全局的任务改异步并资源隔离。继续加分片不能治本，因为扇出、元数据、小文件与归并成本同步增加。验收比较单片扫描量、扇出数、中间字节、协调内存和高分位延迟，证明分治确实减少总工作量，而不是只把一次扫描拆成更多远程扫描。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：只看平均延迟够吗？
   • 直接回答：不够，广播由最慢分片决定，要看高分位和倾斜。
   • 追问：预聚合会丢精度吗？
   • 直接回答：取决于算法和口径，精确指标要保留重算路径。
   • 追问：跨分片 Join（连接）应禁止吗？
   • 直接回答：不必绝对禁止，但必须有数据量和资源预算。
   • 详情：分治与扇出

8. 问题：重新分片和扩容追赶应如何设计？

   • 口述答案：我把重新分片视为在线迁移。先冻结新旧路由、业务键、删除语义和兼容窗口，在旧分片一致位置取全量，同时保留增量日志。全量按新路由幂等装载，新分片重建索引、排序或部件；增量按实体顺序应用新增、更新和删除并记录水位。迁移时旧、新数据及中间索引共存，2 TiB（太字节）净数据可能需要接近 4 TiB（太字节）再加日志与恢复余量。追赶要算净值：目标应用 60 MiB（兆字节）/s（每秒）、源高峰新增 45 MiB（兆字节）/s（每秒），实际只以 15 MiB（兆字节）/s（每秒）缩小差距；应限速全量、优先增量。校验按租户和新桶比较主键、字段摘要、删除、行数和业务聚合，影子查询验证路由与剪枝。灰度发布时客户端携带路由版本，失败可回旧版本；切换后保留反向增量和旧分片只读窗口。确认无旧流量、日志覆盖、回滚窗口与合规归档通过后才清理旧数据，不能因节点已加入就宣布扩容完成。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：能双写新旧分片吗？
   • 直接回答：可受控使用，但需权威顺序、未知结果补偿和对账。
   • 追问：何时暂停全量？
   • 直接回答：增量差扩大、前台超预算或磁盘高水位时。
   • 追问：旧分片何时删除？
   • 直接回答：观察和回滚窗口结束且最终证据通过后。
   • 详情：重新分片

9. 问题：如何建立一份真正可用的备份目录？

   • 口述答案：我从威胁和恢复顺序反推目录，而不只登记快照任务。数据层保存逻辑导出或物理一致基线，记录起点、对象清单和校验和；增量层保存连续 WAL（预写日志）、oplog（操作日志）或变更日志，验证起止无断档；控制层保存表、索引、映射、路由、权限和账号；运行层保存密钥、证书、插件、分词词典和外部字典版本。对象使用独立账号、最小权限、加密、保留和跨地域副本，关键基线防篡改；三份对象若共享同一账号和密钥，仍可能被一次事故击穿。容量上 2 TiB（太字节）全量加日增 500 GiB（吉字节），7 天增量约 3.42 TiB（太字节），两份全量与单地域日志约 7.42 TiB（太字节），跨地域约 14.84 TiB（太字节），还要计对象版本。每次演练随机选日期，在隔离环境完成解密、元数据装载、日志重放、校验和、业务查询与删除验证，并记录耗时。材料、权限、人员和流程共同通过，才叫可恢复。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
   • 追问：逻辑与物理备份谁更好？
   • 直接回答：按可移植性、规模和 RTO（恢复时间目标）权衡，常组合使用。
   • 追问：为何备份词典和插件？
   • 直接回答：它们决定启动兼容和查询语义。
   • 追问：密钥放哪里？
   • 直接回答：独立托管、双控制、审计并演练历史版本恢复。
   • 详情：备份目录

10. 问题：为什么“备份任务成功”不能等于“可恢复”？

• 口述答案：任务成功通常只证明程序写过对象，不能证明完整、可解密、日志一致、版本兼容或业务正确。验证至少五道门：读取清单并复算校验和，随机损坏应被发现；用独立身份取得历史密钥、证书、插件和词典；从备份一致位置接连续日志，执行 PITR（时间点恢复）到指定事务前，断档必须报告最后可恢复点；在隔离环境启动真实版本，检查行数、主键摘要、分区或部件；执行 WMS（仓储管理系统）库存守恒、支付借贷平衡、运单终态和合规删除查询。还要计时：2 TiB（太字节）全量在 1 Gbit/s（吉比特每秒）链路且有效率 70% 时传输约 6.65 小时，加解密、重放、索引和校验可能超过 14 小时；RTO（恢复时间目标）若为 8 小时，每天成功也仍不达标。改进应提高并行恢复、准备近线基线并分级恢复权威服务，不能删除校验伪造速度；失败快照先隔离取证，防止生命周期继续清掉健康副本。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：抽样恢复够吗？
• 直接回答：可高频检查介质，但仍需定期全量演练真实时长。
• 追问：校验和一致够吗？
• 直接回答：还需业务不变量、版本和依赖验证。
• 追问：坏快照立即删除吗？
• 直接回答：先隔离保留取证，查明根因后审批处理。
• 详情：恢复证据

11. 问题：如何用 RPO（恢复点目标）和 RTO（恢复时间目标）设计演练？

• 口述答案：先把目标翻译成时间线。RPO（恢复点目标）是最后可恢复位置与事故点之间允许缺多少变更，要记录基线位置、日志末端、最后订单和账务流水；RTO（恢复时间目标）从宣布灾难到关键业务写入、查询和路由恢复，下载、解密、重放、校验、审批与切流都计时。演练随机选历史时间，故意损坏一份快照并撤销主账号权限，再用跨账号只读身份选择健康基线；恢复元数据、插件和密钥后重放到误删前。技术侧复算校验和、行数、日志连续和分片状态，业务侧全量验证库存守恒、借贷平衡和删除集合并抽查运单版本。每阶段记录吞吐、失败和人工等待；若传输 6.65 小时、解密 1 小时、重放 2 小时、索引 3 小时、校验 1.5 小时，总计 14.15 小时而目标 8 小时，结论必须失败。改进后再次故障注入，证明权威服务先恢复、搜索分析后置，且未牺牲一致性门禁。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：零 RPO（恢复点目标）怎么验？
• 直接回答：证明所有已确认写被覆盖，并核对最后业务版本。
• 追问：RTO（恢复时间目标）从何时计？
• 直接回答：从预先约定的灾难确认点，发现和决策通常也应计入。
• 追问：演练可在生产做吗？
• 直接回答：恢复优先隔离，路由演练可受控灰度并限制爆炸半径。
• 详情：恢复目标

12. 问题：PITR（时间点恢复）怎样处理误删前后的合法写入？

• 口述答案：先恢复到明确一致位置，再处理误删后的合法业务，不能简单把生产整体倒回。假设 10:05 批量误删，之后仍有正常订单和支付。我会冻结受影响对象，保留现场，在隔离环境选误删前基线并重放连续日志到误删事务之前。恢复后比较被删主键、字段校验和与关联，提取仅受误删影响的数据；再把这些对象以补偿事务合并回当前生产，以业务版本条件防止覆盖 10:05 后的合法更新。删除涉及父子对象、索引和文件时按依赖恢复，再从权威状态重建搜索。支付流水不可覆盖，只能新增冲正或修复；已发送通知不回放。全过程记录基线、停止点、提取清单、合并规则和审批，最终检查库存、金额、轨迹终态与删除合规。只有业务接受全库回退且停机期间没有合法新写，才切整个恢复实例；多数在线系统应隔离恢复后定向合并。时间只作辅助，停止点优先使用事务或产品位置，避免时钟偏差。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：只按时钟停止够吗？
• 直接回答：不够，应以事务或日志位置确认边界。
• 追问：误删后同主键重建怎么办？
• 直接回答：按身份和版本判断，禁止旧对象覆盖新对象。
• 追问：搜索要同步回退吗？
• 直接回答：从修复后的权威状态重建或补投影。
• 详情：PITR（时间点恢复）

13. 问题：在线迁移从全量到切流的完整状态机是什么？

• 口述答案：先冻结模型和不变量，明确主键、字段、删除、顺序、金额与库存口径并给模式版本。然后在源位置 L0 取一致全量，同时从 L0 启动日志或 CDC（变更数据捕获）；全量按稳定键幂等装载，失败批次可断点重入。增量按实体顺序与业务版本应用新增、更新和删除，目标报告水位、重试与毒数据。追平后分层校验：行数与主键查缺重，分桶校验和查字段，删除集合查残留，库存、金额和轨迹终态做全量聚合，1% 抽样只快速反馈。再用生产查询影子读，比较结果、延迟、权限和排序。按租户或比例灰度读写，观察错误率、水位与不变量；失败收回流量并回追平。随后短暂停旧写，取得最终位置，应用最后增量后切换。回滚窗口内旧库只读，目标新写可反向同步，支付和通知进入对账。确认无旧流量、回滚结束、归档与删除证明齐全后才下线旧库。每一步都有进入、退出与失败回退条件。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：水位追平等于可切吗？
• 直接回答：不等于，还要清毒数据并通过内容与业务校验。
• 追问：为何影子读？
• 直接回答：用真实查询暴露差异而不影响用户结果。
• 追问：能省略停旧写吗？
• 直接回答：只有最后窗口被可证明地封闭时才可评估。
• 详情：迁移状态机

14. 问题：2 TiB（太字节）全量、日增 500 GiB（吉字节）怎样制定迁移计划？

• 口述答案：1 Gbit/s（吉比特每秒）理论 125 MB/s（兆字节每秒），有效率 70% 约 87.5 MB/s（兆字节每秒），2 TiB（太字节）仅传输约 6.65 小时；实际还有源读取、目标写入、索引、解压和校验，应以最慢阶段为准。日增 500 GiB（吉字节）平均约 5.93 MiB（兆字节）/s（每秒），高峰按 5 倍约 29.65 MiB（兆字节）/s（每秒）。若全量占 80 MiB（兆字节）/s（每秒），增量只得 20 MiB（兆字节）/s（每秒），高峰差距继续扩大，永远不能切流；必须限全量、优先增量或增加应用能力。容量上源、目标、下载临时文件、索引和合并共存，净 2 TiB（太字节）按双份再加日志与恢复余量。校验先抽样 1% 发现字段问题，再全量比较主键、删除和按日期租户的金额库存。计划可设快照 8 小时、追平 4 小时、校验 6 小时、影子 24 小时、灰度 24 小时、回滚 72 小时，每阶段都有门禁和回退，而不是只写切流日期。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：压缩后能直接缩短吗？
• 直接回答：需测端到端瓶颈，网络未必最慢。
• 追问：追平时间怎么算？
• 直接回答：落后量除以目标应用率减源新增率，并持续重算。
• 追问：为何临时盘翻倍？
• 直接回答：新旧数据、索引、合并和回滚窗口同时存在。
• 详情：迁移数据演绎

15. 问题：校验抽样、校验和与全量业务聚合如何组合？

• 口述答案：抽样成本低、反馈快，适合早期发现编码、时区、映射和权限错误，但 1% 样本全过仍可能漏掉集中在一天或一租户的缺口。分桶校验和按稳定主键范围或日期租户组合，对源目标规范化字段后计算摘要，可全量发现内容差异并缩小定位范围；必须统一空值、精度、字符和字段顺序。全量业务聚合验证领域语义，例如库存可用加占用与账本守恒、支付借贷和渠道金额一致、物流终态不倒退、删除对象不存在。行数只作粗门禁，一缺一重会抵消。顺序是先抽样阻断明显错误，再全量主键与删除集合，再分桶字段摘要，最后业务聚合与影子查询；差异桶逐行定位，修复后定向回放并重跑全套门禁。所有校验携带源位置、目标水位、规则版本和运行时间，避免源持续写产生假差异。切流后继续对账观察，证明不是只在一个瞬间相等。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：校验和不同一定错吗？
• 直接回答：可能是规范化差异，应先统一规则。
• 追问：业务聚合相同够吗？
• 直接回答：不够，金额会抵消，还需主键和字段摘要。
• 追问：源仍写怎么办？
• 直接回答：按同一位置和目标水位分桶比较。
• 详情：校验门禁

16. 问题：为什么应用双写不是无丢失、无重复方案？

• 口述答案：应用双写先后调用两个独立系统，没有共同原子提交。权威库成功、搜索失败会缺失；搜索成功、权威库失败会留脏投影；第二次调用成功但响应丢失，应用看到超时，换新键重试会重复；并发和重试还会让旧版本后到覆盖新版本。调用顺序反转只改变分叉方向。更稳妥是在权威事务内写业务状态和 Outbox（发件箱），或从提交日志产生 CDC（变更数据捕获），再异步投影。事件携带稳定标识、实体键、业务版本、模式版本和删除墓碑；同实体按分区顺序，目标以事件键幂等、版本条件拒绝倒退，未知结果先查证后用同键重试。字段不兼容进毒数据隔离，不阻塞无关分区，修复后从断点回放。持续对账主键、版本、删除和业务聚合。短信、支付与仓库动作不可盲目回放，必须查渠道、冲正或人工审核。因此可靠性来自权威事件、可回放、幂等和对账，不是代码写了两次。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：分布式事务能解决吗？
• 直接回答：两端真实支持且成本可接受时可评估，搜索分析通常不适合参与。
• 追问：Outbox（发件箱）会重复吗？
• 直接回答：会，消费者仍需幂等。
• 追问：目标长期失败怎么办？
• 直接回答：保护事件保留、告警水位、降级并断点恢复。
• 详情：双写同步

17. 问题：异构同步如何处理删除、字段演进和毒数据？

• 口述答案：删除不能依赖扫描当前行，因为对象消失后目标不知道曾存在；权威事件必须产生带实体键、删除版本和时间的墓碑，目标先逻辑移除，再按保留与合规物理清理，备份和跨地域副本也要形成删除证明。字段演进采用扩展、迁移、收缩：先加可选新字段并让旧消费者忽略，事件携带模式版本；同步器兼容新旧，历史回放用确定转换；回填和消费者升级后才移除旧字段。遇到无法解析、枚举未知、精度越界或映射拒绝的毒数据，保存原事件、来源位置、模式、错误和次数；隔离该事件及依赖其顺序的同实体后续，让无关分区继续，禁止无限重试。修复转换后从原断点按同一事件键回放，版本条件防重复和倒退。持续校验删除集合、字段非空率、枚举分布、版本水位和业务聚合，并给毒数据最老年龄设置服务目标。外部仓库或支付动作只修数据，不重复副作用，另走渠道查询与人工对账。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：软删除能永久留吗？
• 直接回答：要服从保留与合规，最终仍需物理清理证明。
• 追问：毒数据能跳过吗？
• 直接回答：不能静默跳过，同实体依赖链应一起隔离。
• 追问：墓碑保存多久？
• 直接回答：至少覆盖消费者最大离线和回放窗口。
• 详情：异构同步契约

18. 问题：复制延迟事故如何建立两类证据并止血？

• 口述答案：先确认影响的是确认安全、陈旧读还是迁移追平，不能只看一个延迟分钟数。产品侧证据取 PostgreSQL（关系型数据库）发送、接收、刷新和重放 LSN（日志序列号），MongoDB（文档数据库）多数提交点和从节点应用位置，ClickHouse（列式数据库）复制队列、缺失部件和最大事件时间，Elasticsearch（搜索引擎）分片序列号、恢复阶段与刷新水位。独立证据取网络吞吐、磁盘延迟、处理器、长查询，以及库存最后版本、支付最后流水、物流最后轨迹和分析最大业务时间。两类证据交叉才能区分网络阻塞、存储慢、重放能力不足、错误查询占用或只是搜索可见延迟。止血优先保护权威写和日志保留：暂停副本报表、回填与大聚合，关键读回主库或明确降级，限制源端低优先级批量，绝不直接删日志。修复按瓶颈扩网络、存储或重放能力，终止阻塞查询并调整资源隔离。恢复后验证位置差、时间差和业务版本都稳定，再灰度恢复读流量。演练注入 20 分钟落后和节点故障，证明 RPO（恢复点目标）、追平时间和日志容量满足承诺。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：延迟归零即可关闭事故吗？
• 直接回答：还要验证业务版本、查询回归和再次负载后的稳定性。
• 追问：先扩容还是先限流？
• 直接回答：先保护日志与权威写，再按证据扩瓶颈资源。
• 追问：分析报表怎么办？
• 直接回答：标注数据水位、暂停结算口径或回源，不静默返回陈旧结果。
• 详情：灾难证据链

19. 问题：旧主复活如何避免脑裂和二次写入？

• 口述答案：提升前先形成新任期或新历史，并让路由只指向新主；旧主复活时采用三层栅栏。基础设施层隔离旧主网络、存储写路径和负载入口；身份层撤销旧账号、证书或租约；业务层让库存、支付、Runner（执行器）等关键写携带领导任期或业务版本，旧任期即使通过缓存地址触达也无法条件更新。证据一是产品任期、时间线、选举与客户端路由日志，证据二是业务版本、重复写和外部渠道记录。若发现旧主已写入，立即冻结受影响实体，固定双边最终水位，按业务键分类：可回放数据库状态从权威新历史合并，支付扣款、短信和仓库动作查外部渠道后冲正或人工对账。旧主不能直接作为副本加入，因为历史可能分叉；应在隔离环境确认共同点后重绕，条件不满足则从新主重建。恢复验收包括旧地址请求被拒、新任期写成功、旧任期写零落盘、未知结果幂等查证和业务不变量通过。定期演练要故意保留一个缓存旧地址的客户端，证明控制面与业务栅栏都有效。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：只改服务发现够吗？
• 直接回答：不够，客户端缓存和直连可能绕过，应有网络、身份与业务门禁。
• 追问：旧主数据能否直接丢弃？
• 直接回答：先保留取证并核对是否含未进入新历史的合法业务事实。
• 追问：Runner（执行器）如何防旧主？
• 直接回答：结果提交携带租约任期，权威库条件更新拒绝旧任期。
• 详情：旧主复活时序

20. 问题：快照损坏、日志断档、权限丢失和密钥缺失如何处理？

• 口述答案：这四类故障分别击穿介质、连续性、访问控制和解密能力，不能用“还有副本”统一回答。快照损坏以对象校验和、分片清单和恢复错误为第一类证据，以底层存储审计或另一地域副本为第二类证据；立即禁用坏基线并保留样本，从独立副本恢复。日志断档要比较归档清单、起止位置与对象版本，明确最后连续位置，停止声称可做任意 PITR（时间点恢复），必要时生成新基线。权限丢失先用审计日志确认账号、策略、网络或组织控制，再启用预演过的跨账号只读应急身份，禁止临时授予全管理员。密钥缺失则核对密钥版本、托管审计和双控制备份；没有旧密钥无法用新密钥直接转换密文，只能从受控密钥副本或其他可恢复数据源重建。全过程冻结生命周期删除，避免健康对象继续过期。恢复后复算校验和、连续重放、执行业务查询并记录真实 RPO（恢复点目标）和 RTO（恢复时间目标）。演练随机损坏一份快照、删除一段日志副本、撤销权限和切换历史密钥，证明替代路径真实存在。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：能手工补一个缺失日志文件吗？
• 直接回答：只有来源、位置和校验均可证明连续时才可恢复，不能伪造或猜测。
• 追问：为何冻结生命周期？
• 直接回答：防止取证和恢复期间其他健康副本被自动删除。
• 追问：应急身份应长期高权限吗？
• 直接回答：不应，采用最小只读、双审批、短时授权和完整审计。
• 详情：备份灾难路径

21. 问题：切流后校验失败，如何回滚而不丢新写？

• 口述答案：先停止扩大爆炸半径，收回灰度并暂停目标新写，记录源、目标、增量日志和外部渠道的最终水位。不能直接把路由切回旧库，因为旧库缺少切流后的合法新写。把这段变更按可逆性分类：数据库内订单、库存状态和配置可用稳定业务键、版本条件与删除墓碑反向幂等应用；搜索、分析和文件投影可从权威事实重建；支付扣款、退款、短信、仓库出库和已发送导出链接属于外部副作用，必须先查渠道结果，按冲正、补发、作废或人工审核处理，禁止盲目日志回放。反向补齐后比较主键、字段摘要、删除集合、库存守恒、账务借贷与运单终态，确认旧库已包含切流窗口全部合法事实，再灰度恢复旧路由。目标保留只读取证，不立即删除。根因若是字段映射或精度差异，修复后从共同水位重建目标，再重新走影子读和灰度。演练应在目标写入 2300 条状态并制造 17 条外部通知后触发失败，证明数据可逆、外部副作用可对账且回滚耗时满足窗口。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：旧库只读保留为何不等于可回滚？
• 直接回答：它没有切流后的新写，必须有反向同步或补偿路径。
• 追问：目标数据何时删除？
• 直接回答：取证、修复、合规与新一轮迁移计划确定后再审批处理。
• 追问：支付如何回滚？
• 直接回答：不覆盖流水，按渠道结果做冲正、补记和人工对账。
• 详情：迁移回滚

22. 问题：PostgreSQL（关系型数据库）到搜索和分析投影如何迁移？

• 口述答案：先声明 PostgreSQL（关系型数据库）事务表和 Outbox（发件箱）或提交日志是权威源，搜索与分析只是可重建读模型。冻结文档标识、分析主键、业务版本、删除墓碑、字段精度与时区，在一致 LSN（日志序列号）取得全量快照，同时从该位置保留逻辑变更或 CDC（变更数据捕获）。全量按稳定业务键装载，搜索构建新索引，分析按目标排序与分区写入；增量按实体顺序和版本条件应用新增、更新与删除，未知结果用同一事件键查证。追平后比较源表主键集合、搜索文档版本、分析行摘要和删除集合，再全量核对库存、订单金额和运单终态；真实查询做影子读，搜索排序差异与分析口径差异分别解释。灰度切换读流量，权威写仍只进 PostgreSQL（关系型数据库），因此回滚读路由不需要反向改主库。可回放的是搜索文档、分析明细和聚合；不可回放的是支付、短信和仓库操作，事件消费必须把数据投影与外部副作用分开。最终记录源 LSN（日志序列号）、目标水位、映射版本和重建手册。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：能从搜索反写数据库吗？
• 直接回答：不应，搜索缺事务约束和完整历史，只作为候选定位。
• 追问：逻辑复制能覆盖所有对象吗？
• 直接回答：不能假定，表、序列、对象定义等按现场版本核对并另行迁移。
• 追问：删除如何验证？
• 直接回答：全量比较墓碑与目标不存在集合，并检查备份保留策略。
• 详情：PostgreSQL（关系型数据库）投影案例

23. 问题：MongoDB（文档数据库）分片扩容如何处理大租户与路由变更？

• 口述答案：先用真实分布证明旧键问题：若大租户占 35% 数据，纯租户键会让新节点增加后仍集中一片。为大租户设计稳定子桶，冻结新旧分片键、路由版本、文档身份、版本与删除语义；普通租户可沿旧规则，大租户按业务对象散列到固定桶。迁移在一致基线后从 oplog（操作日志）位置持续追增量，目标以文档键和业务版本幂等应用；路由层在过渡期读取对象的路由版本，不能随机试多个分片后把重复当正常。观察数据块迁移、复制延迟、孤儿数据、配置元数据和路由缓存，给源、目标都预留临时空间。校验按租户桶比较文档数、主键摘要、数组关键字段、版本高水位与删除集合，再用运单终态和轨迹数量做业务聚合。灰度先迁一个可回滚租户，再逐步扩大；失败回旧路由并从增量位置补齐。文档状态和删除可回放，已调用第三方轨迹、标签打印或仓库动作要查渠道对账。最终证明最大分片、写入率和高分位查询均下降，而不是仅证明迁移任务结束。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：增加分片为什么不自动均衡大租户？
• 直接回答：若分片键让一个租户不可再分，其数据仍集中在同一路由范围。
• 追问：路由缓存陈旧怎么办？
• 直接回答：版本化路由、刷新元数据并对旧版本请求提供明确重定向或拒绝。
• 追问：如何发现孤儿数据？
• 直接回答：按所有权范围、主键集合和路由版本审计，不让它参与权威查询。
• 详情：MongoDB（文档数据库）扩容案例

24. 问题：ClickHouse（列式数据库）集群换代如何保证分析口径不漂移？

• 口述答案：先冻结表定义、列类型、时区、排序键、分区、分片规则、复制引擎、物化规则和外部词典版本；这些差异即使行数相同也会改变结果。全量可按分区或数据部件迁移，也可从权威明细重导，必须记录每批清单和校验和；同时保留增量批次，按稳定事件键和版本装入新集群。迁移期间控制小部件数量、合并、复制队列和临时磁盘，避免全量把前台增量饿死。校验先比较每分区行数、最小最大事件时间、字段摘要和删除或变更任务，再全量计算订单金额、库存快照、设备分位数和迟到修正数量；0.03% 金额差也要定位数值精度、时区、重复、物化或规则版本，不能以“分析允许误差”豁免。影子运行真实报表，比较查询结果、高分位延迟和资源。灰度切换查询入口，旧集群保留回滚水位；明细和聚合可从权威数据重放，已交付客户的导出文件、结算报表和通知要按批次版本人工核对。最后在节点故障与磁盘翻倍条件下完成恢复演练。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：能直接复制聚合结果吗？
• 直接回答：可以迁移但仍需规则版本和源明细重算能力，防止把旧口径固化。
• 追问：行数一致为何金额不同？
• 直接回答：精度、时区、去重、物化和迟到规则都可能改变聚合。
• 追问：旧集群何时下线？
• 直接回答：观察、回滚、最终增量、导出对账与归档都通过后。
• 详情：ClickHouse（列式数据库）换代案例

25. 问题：Elasticsearch（搜索引擎）如何安全重建索引？

• 口述答案：不在旧索引上冒险原地改映射，而是创建带新映射、分析器、分片数和设置的新索引。权威数据库或事件日志在位置 L0 提供全量，投影链从 L0 持续消费新增、更新和删除；文档标识稳定，源业务版本写入目标，旧版本和重复事件被拒绝。全量结束后比较主键或文档集合、源版本高水位、删除集合、字段非空率、分词样本和关键聚合；文档数相同仍可能存在一缺一重或旧版本覆盖。影子执行运单精确查、商品全文检索、权限过滤、排序、分页与聚合，比较结果和高分位延迟。目标水位追平、毒数据清空后，先灰度读别名或路由，再原子切换；切换后继续监控零结果率、错误率、刷新与分片恢复。旧索引保留回滚窗口，新的写事件也要能在回滚时补回旧索引或从权威源重建。索引文档和删除可回放，但用户已依据错误搜索触发的仓库动作、通知或支付不能回放撤销，必须单独审计。最终才按保留策略删除旧索引。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：别名切换是否等于迁移完成？
• 直接回答：不等于，还需观察新写、水位、查询质量和回滚能力。
• 追问：为何检查分词样本？
• 直接回答：映射与词典变化可能让文档数相同但召回完全不同。
• 追问：旧索引要同步新写吗？
• 直接回答：回滚窗口内需有补齐方案，否则回切会丢切换后变化。
• 详情：Elasticsearch（搜索引擎）重建案例

26. 问题：WMS（仓储管理系统）库存的权威源、恢复顺序和不变量是什么？

• 口述答案：库存权威源不是缓存或搜索，而是库存流水、预占记录、条件更新结果和必要的实物盘点口径。恢复先装载仓库、货主、商品等基础主数据，再恢复不可变流水和预占状态，按业务版本重建当前库存视图；校验可用量、占用量、在途量与总账变化守恒，并逐个检查负库存、重复预占和已取消未释放。只有账本和当前视图一致后才开放扣减与释放，搜索、报表和缓存随后从权威状态重建。迁移时稳定键包含租户、仓库、货主、SKU（库存单位）和业务单号，删除通常用状态迁移而非静默物理删除；双写失败由 Outbox（发件箱）或 CDC（变更数据捕获）补投影。复制延迟时库存裁决回主库，落后副本只做标注水位的查询。旧主复活时，条件更新携带领导任期或库存版本，拒绝旧状态。恢复演练注入 1200 条未决预占、重复消息和旧主写入，证明不会超卖、重复释放或把搜索数量当事实；最后以流水、余额和订单三方对账验收。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：缓存能否作为灾备库存？
• 直接回答：不能，缓存缺完整事务历史与恢复证据，只能从权威账本重建。
• 追问：搜索显示有货怎么办？
• 直接回答：下单仍以权威条件扣减结果为准，搜索只做展示候选。
• 追问：预占超时如何恢复？
• 直接回答：按业务状态、版本和订单结果补偿，不能只按墙上时间盲目释放。
• 详情：项目恢复顺序

27. 问题：跨境物流搜索与轨迹怎样迁移和恢复？

• 口述答案：运单主记录和可回放轨迹事件是权威源，事件包含渠道事件号、运单号、业务时间、接收时间、版本与原始载荷；当前轨迹状态、Elasticsearch（搜索引擎）索引和 ClickHouse（列式数据库）分析是派生层。恢复先重建运单与事件唯一集合，按渠道状态机和版本规则生成当前状态，保证终态不被迟到旧事件倒退；再重建搜索文档和时效分析。迁移采用一致全量加事件水位后的增量，新增、更新、删除或隐私擦除都带稳定身份；搜索影子读覆盖运单精确查、渠道名、轨迹文本、权限过滤和排序，分析校验每渠道件量、终态比例与时效分布。复制落后时搜索返回源版本水位，关键客服查询可回源。第三方轨迹拉取、面单打印和通知是外部副作用，不能因数据回放再次调用；应查渠道请求号和发送记录，缺失才补偿。演练注入 8000 条乱序轨迹、删除传播失败、词典变化和切流回滚，证明事件不重、状态不倒退、已删除隐私不残留，旧索引和分析集群可从权威事件再次构建。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：事件时间相同如何排序？
• 直接回答：结合渠道版本、接收序号和状态规则，不能只按时间戳。
• 追问：搜索命中能否证明终态？
• 直接回答：不能，客服裁决应回运单与事件权威状态。
• 追问：面单能否重打？
• 直接回答：先查渠道和业务请求身份，避免产生重复单号或费用。
• 详情：项目权威边界

28. 问题：支付账务恢复为什么不能直接重放所有日志？

• 口述答案：支付权威源是不变账务流水、支付单、渠道请求号、回调验签结果和对账记录，不是搜索、报表或缓存。数据库内状态可以按稳定幂等键和版本重放，但扣款、退款、短信和渠道调用已经改变外部世界；盲目回放可能二次扣款或重复退款。恢复先验证账务流水校验和、借贷平衡、币种与精度，再按渠道单号主动查询 17 笔未知结果：渠道成功而本地缺失时补记账务与业务状态，渠道失败才允许受控重试，仍未知进入人工队列。余额和报表从流水重建，搜索最后恢复。迁移切流前比较逐日逐币种金额、笔数、手续费、退款和渠道结算，全量业务聚合差异必须为可解释值；影子查询不触发渠道动作。切流后若回滚，先停新写并固定双边水位，把可逆数据库状态反向补旧库；渠道副作用用冲正或补记，不覆盖历史流水。旧主复活还要以账务版本和领导任期拒绝写。最终由数据库摘要与渠道对账两类证据证明无丢单、无重复资金动作，并保存人工审批链。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：流水能更新吗？
• 直接回答：核心流水通常追加更正或冲正，不覆盖原事实，具体按账务模型执行。
• 追问：渠道超时等于失败吗？
• 直接回答：不等于，必须以幂等请求号主动查询或对账。
• 追问：报表先恢复可以吗？
• 直接回答：可后置重建，不能先于权威流水和借贷校验承担结算。
• 详情：支付恢复顺序

29. 问题：异步导出系统如何迁移并避免重复交付？

• 口述答案：异步导出的权威源是任务、查询口径版本、源数据水位、分片清单、租约、每片结果摘要和最终交付状态；生成文件与通知是可重建或外部副作用。迁移先冻结任务状态机和文件命名规则，全量迁移未完成任务与已完成元数据，再从任务事件水位追增量。Runner（执行器）领取分片携带租约任期，目标系统只接受当前任期结果；未知结果按任务与分片幂等键查证，不能创建新任务重复跑。恢复时先校验源查询水位仍可访问，再恢复待执行分片；已生成文件比较对象校验和，损坏则重建，已发送链接通过交付记录判断，不重复通知。切流影子阶段用同一批次在新旧系统生成文件，比较行数、字段摘要、金额聚合和对象校验和，但只旧系统向用户交付。灰度后若回滚，把切流后任务状态反向补旧库，文件可重建，通知需按用户、任务、版本去重。演练包含 48 个未完成文件、租约过期、对象权限丢失和源数据过期，证明同一批次口径一致、文件完整且只交付一次。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：文件是权威数据吗？
• 直接回答：通常不是，它是按任务口径和源水位生成的派生物，应可验证重建。
• 追问：任务完成但文件丢失怎么办？
• 直接回答：校验对象后把交付状态退回可重建阶段，保留同一任务身份。
• 追问：通知可重放吗？
• 直接回答：只能按交付记录和通知身份补发，不能随任务日志全量重放。
• 详情：异步导出恢复

30. 问题：Runner（执行器）调度恢复如何防止旧租约重复执行？

• 口述答案：Runner（执行器）的权威状态包括任务定义、分片、租约持有者、租约截止、领导任期、尝试次数和执行结果；日志与指标只是证据，不能单独决定完成。恢复先提升调度主节点并增加任期，隔离旧主入口；新领取返回包含任务、分片和任期的栅栏令牌，结果提交必须在权威数据库做“状态仍运行且任期相同”的条件更新。即使旧 Runner（执行器）缓存地址、网络恢复或长任务晚返回，也会因旧任期被拒绝。对 36 个灾难时未过期租约，不立即全部重发：先查外部执行结果和幂等副作用，能确认完成则补记，明确失败或租约安全过期后才重试，未知进入人工或延迟查证。迁移全量任务后从状态事件追增量，比较每状态计数、分片集合、任期和最老任务年龄；影子调度只计算计划，不真正触发外部动作。回滚时反向补任务状态，已执行脚本、发货或扣费不能重放。演练旧主复活、租约超时、结果迟到和目标切流失败，证明同一分片最多一个有效提交，重复尝试也不重复业务副作用。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：租约过期就能安全重试吗？
• 直接回答：不一定，旧任务可能仍在运行，需栅栏令牌和外部幂等共同保护。
• 追问：结果提交失败怎么办？
• 直接回答：以任务身份查证权威状态，用同任期重试或进入未知结果处理。
• 追问：旧主只读是否足够？
• 直接回答：还要撤销调度能力和拒绝旧任期结果。
• 详情：Runner（执行器）恢复

31. 问题：IoT（物联网）报警系统恢复如何避免报警风暴？

• 口述答案：权威源是可回放遥测事件、设备与规则版本、报警实例和状态迁移，不是搜索结果或已发送通知。恢复先装载原始事件与规则版本，按事件时间、水位和允许迟到重建窗口，再生成报警状态；回放阶段禁止直接调用短信或电话。通知身份由租户、设备、规则版本、报警实例和状态迁移组成，查询既有发送记录，只对仍有效、严重且未通知的状态补发。200 万条待重算遥测按租户和时间分批，严重报警通道预留资源，普通历史报警只进入审计，不补发过期通知；重复事件命中幂等键，乱序旧版本不能让已恢复状态倒退。聚合与 Elasticsearch（搜索引擎）索引可从原始事件重建，外部通知不可盲目回放。迁移校验比较事件唯一数、窗口计数、报警实例、状态转换和通知集合，影子运行只生成候选差异。切流后发现规则字段错误时，停新通知、固定规则与事件水位，重算受影响窗口并人工审核补发。演练包含设备批量补发、旧主复活、通知渠道超时和删除请求，证明严重报警不漏、重复不重发、隐私可删除。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：为何不补发所有历史报警？
• 直接回答：多数已过时且会制造风暴，应按当前有效性和业务时效决定。
• 追问：严重报警如何穿透？
• 直接回答：预留独立队列与配额，但仍使用稳定报警身份去重。
• 追问：规则变化后怎么重算？
• 直接回答：按规则版本和事件水位隔离重算，校验后发布新状态。
• 详情：IoT（物联网）恢复

32. 问题：如何严格区分复制、高可用、备份与可恢复性？

• 口述答案：复制解决在线冗余和读扩展，把当前变化送到其他副本，但会快速传播误删和逻辑污染；高可用在复制之上增加故障检测、选主、旧主栅栏、客户端路由与服务连续性，目标是缩短中断；备份在独立故障域保存历史一致基线、连续日志、元数据、密钥和依赖，目标是应对误删、勒索、介质损坏和历史审计；可恢复性则是通过隔离环境演练证明这些材料能在 RPO（恢复点目标）与 RTO（恢复时间目标）内恢复业务。三副本不等于三份备份，因为它们可能共享账号、软件缺陷和当前错误；每天快照成功也不等于可恢复，因为可能损坏、无密钥、日志断档或恢复太慢。设计时分别给四者指标：复制位置与陈旧窗口，高可用提升时长和旧主拒写，备份成功率、校验和与保留，可恢复性演练耗时、业务查询和删除证明。事故复盘也按层定位，不能用“集群是绿色”回答历史恢复，不能用“有备份”回答分钟级故障切换。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：跨地域副本算备份吗？
• 直接回答：若只同步当前状态仍不是完整历史备份，还需保留和独立权限。
• 追问：高可用能否做到零停机？
• 直接回答：取决于检测、提升、路由和客户端重试，必须用业务观测验证。
• 追问：可恢复性由谁负责？
• 直接回答：数据、平台、安全与业务共同负责，业务方必须定义不变量和验收。
• 详情：四类能力边界

33. 问题：复制、分片、备份和迁移各自把原问题转成了什么问题？

• 口述答案：复制并没有消灭故障，而是把单节点失败转成客户端等到哪个位置、哪些已确认写能在提升后保留、副本有多陈旧、旧主怎样拒写的问题；同步越强，延迟和可用性耦合通常越高。分片没有凭空增加效率，而是把容量上限转成分片键、路由、热点、广播、跨分片归并和再平衡问题；只有查询可裁剪且片内能剪枝时，分治才提速。备份没有把持久化自动变成安全，而是把数据存在转成一致基线、日志连续、密钥权限、保留和可验证恢复问题；任务成功只是输入证据。迁移也不是复制一遍文件，而是源、目标两个持续变化的状态机，在有限窗口内通过业务键、版本、删除、查询和不变量证明等价，再用灰度和回滚控制风险。这四个设计思想共同要求显式写出失败边界和证据：复制看位置与业务版本，分片看分布与扇出，备份看恢复演练，迁移看水位与对账。删除和外部副作用最容易被“最终一致”掩盖，因为一个事实已经消失，另一个事实已经发生在系统之外，必须单独建模。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：最终一致可以不定义时间吗？
• 直接回答：不可以，应有水位、收敛时限、失败队列和人工升级条件。
• 追问：设计时先选产品吗？
• 直接回答：先定不变量、查询、增长和恢复目标，再映射产品机制。
• 追问：哪个边界风险最高？
• 直接回答：通常是删除、未知结果和不可回放外部副作用。
• 详情：设计思想与项目边界

34. 问题：请给出本章完整的上线与验收清单。

• 口述答案：上线前先登记四种产品实际版本；无法确认统一写“待现场核对”，把确认级别、选举、日志保留、快照兼容、插件与升级回退放入核对卡。复制侧逐产品记录确认条件、复制单位、进度坐标、提升判据、旧主栅栏和陈旧读窗口，并注入 20 分钟落后与旧主复活。分片侧用真实租户和查询分布验证单调热点、低基数、大租户、广播、跨分片 Join（连接）、聚合和重新分片，容量计入临时磁盘与网络放大。备份侧保存逻辑或物理基线、快照、连续日志、元数据、密钥、插件、词典、跨地域副本、保留和删除证明；随机损坏快照、撤销权限和缺失密钥后，在隔离环境完成 PITR（时间点恢复）、校验和与业务查询，测得真实 RPO（恢复点目标）和 RTO（恢复时间目标）。迁移侧按冻结、全量、CDC（变更数据捕获）、幂等、追平、全量校验、影子读、灰度、停旧、回滚窗口和下线推进；删除、字段变更、双写一边失败、毒数据和外部副作用都有补偿与对账。最后按库存、物流、支付、导出、Runner（执行器）和 IoT（物联网）权威源恢复，所有图真实渲染、数量审计与差异检查通过后才验收。。落地时我还会把结论写成可执行契约：明确责任人、源端位置、目标水位、允许陈旧窗口、超时后的未知结果处理、降级入口和人工升级条件；监控同时展示内部复制坐标、最大业务版本、删除积压、毒数据年龄与预计追平时间。发布前在隔离环境注入网络中断、节点重启、磁盘高水位、重复与乱序，保存日志、指标和业务查询两类证据；发布中按租户或比例灰度，任一不变量失败立即收回流量；发布后持续对账一个完整业务周期，并把真实恢复耗时、差异原因和改进动作写入演练记录。这样回答的不只是正常机制，也包括失败时如何止血、如何证明修复、何时允许恢复业务。
• 追问：最先阻断上线的条件是什么？
• 直接回答：权威源、不变量、版本或回滚路径未定义，任何一项都应阻断。
• 追问：抽样校验全过能上线吗？
• 直接回答：不能，关键主键、删除和业务聚合仍需全量门禁。
• 追问：旧系统何时下线？
• 直接回答：观察与回滚窗口结束、最终水位、归档、外部对账和删除证明通过后。
• 详情：项目与版本核对卡

4. 复习与验收清单

• 能分别复述 PostgreSQL（关系型数据库）、MongoDB（文档数据库）、ClickHouse（列式数据库）和 Elasticsearch（搜索引擎）的确认、复制、提升、恢复与可见窗口。
• 能用确认条件、复制单位、进度坐标、故障提升、旧主防护和陈旧读窗口完成横向比较。
• 能解释分片何时提速、何时因广播、Join（连接）、聚合与协调归并变慢，并量化重新分片临时成本。
• 能严格区分副本、高可用、备份与可恢复性，并用 RPO（恢复点目标）、RTO（恢复时间目标）和业务查询证明恢复。
• 能完整复述在线迁移状态机，处理删除、字段演进、双写分叉、毒数据、回放、回滚和外部副作用。
• 能按权威源、不变量和依赖顺序恢复 WMS（仓储管理系统）、物流、支付、异步导出、Runner（执行器）和 IoT（物联网）。
• 项目版本均为“待现场核对”；版本敏感实现进入核对卡，不把默认值泛化为跨版本事实。
• 正式 PlantUML（开源建模工具）图见 备份恢复与迁移切流全景。