附录A：练习解析与扩展实验
恢复承诺的参考答案
库存服务可以要求库存流水与订单明细对应、可售量等于期初加全部增减、已发货订单不超过已确认出库。三者成立仍可能遗漏一整笔客户已确认订单，也可能把客户身份关联错。内部自洽与外部确认必须同时检查。RTO可以从故障注入开始到独立客户端成功下单并查询库存扣减结束，明确是否包含检测、路由和下游同步。
提交与复制的参考答案
源端提交先于客户端成功回执，但异步副本接收和应用不需要先于这个回执。网络在提交后断开时，客户端可能只收到错误，源事务却已经存在。恢复后根据稳定业务键查询并按幂等协议重试，不能换一个新订单号盲目再扣款。GTID包含只表示执行历史声明，不能替代金额、对象关系与外部回执检查。
暂停线程的扩展
停止IO线程时，SQL线程仍可能应用已有relay log，所以副本数据可能继续前进，直到现存日志耗尽。要观察后续缺口，应先固定已执行水位，再在源提交新的唯一标签事务。记录源集合、副本集合与业务查询结果，恢复接收后等待明确集合执行，再核对。不要假设停止接收等于立即停止所有应用。
外部支付已成功的扩展
五千零一缺失时，至少需要稳定订单号与支付流水或幂等请求键。先查询支付通道确认扣款，再决定在新主补建业务对象还是退款。重复支付不安全，因为原支付事实不会随着数据库切换消失。对业务的准确说明可以是：新主已恢复写入，订单五千零一尚未在新主找到且源已确认成功，正在核对支付流水并执行补偿。
不能直接照搬的三项改造
第一，将pitr加入原拓扑：需要处理本地导入产生的GTID、源集合、数据覆盖范围与额外事务，不能只执行CHANGE SOURCE。第二，跨文件回放：需要验证文件连续性、来源身份与各自起止边界。第三，自动提升：需要真实故障检测、旧主隔离、候选数据比较、路由与恢复后的防回切机制。任何改造都要增加负例，不能仅改变脚本开关。
建议的下一步实验
可以为订单添加外键与触发器，备份后验证其恢复行为；可以制造较大的单笔事务，区分接收日志大小与应用可见性；可以在归档上传中途故障，验证不完整文件不会进入可恢复清单。以上是待执行方向，不属于本版十个已运行场景。扩展时继续遵守随机独占资源与仅删除自己的容器约定。