测试一切。没有任何风险。充满信心地升级。
快速说明：Rediacc 目前还没有生产环境的客户。这是一个用例示例，展示了该架构如何在实践中处理这种场景，而不是来自真实部署的案例研究。
危机场景：在数据库升级期间，发生了意外错误，阻止了版本回滚或继续升级。客户无法访问系统，5000 多名员工无法工作。唯一的解决办法是进行完整的系统恢复，耗费了数小时的工程师时间，而业务在此期间一直处于离线状态。
问题
Mehmet 管理着一些生产数据库，他的团队无法承受这些数据库离线的后果。今天他要升级一个100 TB 的 PostgreSQL 数据库，从版本 13 升级到版本 14。他的计划：
- 进行备份 → 但是，由于数据规模，备份需要几天
- 在周末执行升级 → 各部门收到周六 01:00-05:00 的停机通知
危机影响
- 升级过程中发生意外错误
- 数据库既不能回滚到旧版本也不能继续到新版本
- 即使外部支持团队也无法解决问题
影响：
- 客户无法访问支付和订单系统
- 公司员工（5000+ 人）无法工作
- 声誉受损和投诉增加
临时解决方案：
- 最后的备份被加载到新服务器 → 硬件成本加倍
- 周四和周五的数据仅存在于在线环境，因此会发生数据丢失
- 创建了两个不同版本的数据库 → 不一致性增加
Rediacc 解决方案
以下是 Rediacc 的变化：
1. 即时克隆
- 100 TB 数据库的克隆在几秒内创建
- 升级测试不会影响实时系统
2. 每小时快照
- 确定在升级过程中哪一步从什么时候开始出现问题
- 有问题的操作被提前识别并纠正
3. 无缝升级
- 如果升级失败，实时环境不受影响
- 如果升级成功，新的实时环境将成为最新的克隆
结果
节省时间和成本：
- 备份时间从 7 天减少到 10 秒
无风险升级：
- 在测试环境中提前检测到错误 → 生产系统中没有问题
零停机时间：
- 客户和员工完全感受不到中断