割接后测试不完整，导致数据库双写

故障还原

某医院梳理规整业务的过程，需要把服务和数据库做分离。需求如下：

1. 要求不同的服务写到不同的数据库，业务逻辑繁琐。
2. 要求现有外网数据库迁移到内网，并启用主从模式。
3. 要求数据库割接时间不超过30分钟（300G的数据量）

割接整体过程较为顺利，并且在测试过程中测试了主要的预约服务，当预约服务测试正常，数据库有正常数据写入时，项目、运维、研发都认为本次割接顺利，未对核酸服务进行测试，导致第二天核酸服务仍有部分数据写入老数据库，紧急更新配置后，核酸服务正常写入新数据库。最终导致新老数据库都有核酸业务数据，造成了数据库双写。 最终研发和运维通过手动导入数据的方式，把故障期间核酸写入老数据库的数据，依次导入到新数据库。

责任人	项目、运维、研发-对割接后的业务测试不完整
故障等级	P3
故障状态	已定级
故障简述	因割接测试存在侥幸心里，导致割接业务测试不完整。最终出现数据库双写问题
发现方式	业务运行过程中，通过登陆后台发现数据数量及信息有差异，最终发现新数据库并未记录业务数据。
故障发现时间	11:00
故障发生时间	202206241100
故障恢复时间	202206242300
故障影响时长	服务正常可用，但修复数据花了一天时间

业务影响

不影响业务正常使用

处理过程

处理过程推荐按照时间以列表形式，将处理过程时间点，处理内容，阶段性结果描述清楚。

关键时间点	时间	动作	备注
【故障开始】	202206241105	无法通过后台查看核酸用户检测记录
【紧急处理】	202206241120	重新更改配置文件，重启容器，使核酸系统指向新的数据库
【故障观察】	202206241231	查看核酸系统的数据，已经指向新数据库
【故障恢复】	202206241240
【故障修复】	20220624	按时间、人员、数据库名称等关联信息，手动导出老数据库数据。 并导入当天数据至新数据库
【故障结束】	202206242000	监控恢复正常或客诉解决

故障原因

产品需求

• 无整体的产品设计，一台服务器运行了大量的应用服务，并且这些服务的数据库分散在内网和外网等多个数据库服务器上。
• 要不采用集群化方式，把应用服务集群化管理。要不对服务进行归纳拆分。
• 数据库运行方式有主从、双主、单机等各种方式，这些分散化的数据库，占用了医院大量资源，而且无法有效提升应用程序的负载能力、无法解决单点故障问题。

研发阶段

• 因需要查询交易记录、his响应等各种情况，目前采取的方式是把日志全部写入到数据库，目前一天的数据库日志量约10G左右。需要对日志进一步优化。
• 在未优化数据库之前，研发并未对日志进行分割，导致几个月的日志都在一个数据表中（曾有一个数据表320G约等于1个月的日志）

测试环节

• 测试需要再深入应用，确保数据库写入正常。

发布流程

• 不涉及发版

应急处理

• 本次应急处置风险较大，因为是对生产库进行的操作，极容易发生重大事件。

故障总结

在业务的日常变更中，是否遵守了安全原则，技术架构是否合理，等等。

• 未进行全部数据库的验证测试

  做得好的

  1. 割接方案得到了医院的认可
  2. 总结了短时间内，切换上百GB数据库的经验
  3. 提炼了Rsync同步数据库的方法

做得不好的

• 未进行全部数据库的验证测试

后续改进

复盘后需要进行的后续操作，应指定负责人。