1.清理快照方案选型：
1.使用阿里云提供的DTS服务。未采用，原因是该服务价格成本较高
2.使用任务编排的跨库SQL，将历史数据同步过去。由于该任务每次会将复制范围内的数据查出来，因数据量较大会报慢sql警告，影响线上数据库吞吐量
3.数据数据归档+任务编排，在夜间的业务低峰期进行按月份的数据归档（方便出问题后进行数据恢复），数据会归档至廉价的OSS进行备份存储，待数据归档完成后跑任务编排进行数据的硬删除，操作期间需关注数据库的CPU/内存使用率，以及IOPS（每秒I/O的次数）
2.归档进度
| 任务iD | 时间范围 | 数据数量（条） | 执行 |
|---|---|---|---|
| 982276 | ～2020-02-07 11:07:41 | 104,204 | 1 |
| 987926 | 2020-02-07 11:07:40～2020-03-01 | 2,740,087 | 1 |
| 988963 | 2020-03-01~2020-04-01 | 2,972,159 | 1 |
| 989486 | 2020-04-01~2020-05-01 | 4,576,500 | 1 |
| 990053 | 2020-05-01~2020-06-01 | 4,423,192 | 1 |
| 1001771 | 2020-06-01~2020-07-01 | 3,582,377 | 1 |
| 1006296 | 2020-07-01~2020-07-15 | 1,468,383 | 1 |
| 1006629 | 2020-07-15~2020-08-01 | 1,795,105 | 1 |
| 1014309 | 2020-08-01~2020-08-15 | 1,681,431 | 1 |
| 1028061 | 2020-08-15~2020-09-01 | 1,970,644 | 1 |
| 1020231 | 2020-09-01~2020-09-15 | 1,605,406 | 1 |
| 1020665 | 2020-09-15~2020-10-01 | 3,162,828 | 1 |
| 1028508 | 2020-11-01~2020-11-24 | 4,800,932 | 1 |
| 1029411 | 2020-11-24~2020-12-01 | 5,956,095 | 1 |
3.删除历史快照记录导致线上故障
事故现象： C端下单报错，快照ID为0
事故定级： 事故责任人：孙彬 事故时间：2021-04-29 事故原因：清理历史快照表数据导致C端个别商品无法下单
影响范围：C端无法下单
排查过程： 2021-04-29 10:01 接到C端开发（邱立波）反馈，商品取快照id拿到是0
2021-04-29 10:20 韩永恺、孙彬、吴文全、刘旺杰 商定解决方案
2021-04-29 10:58 商品拿到无法下单数据进行修复
2021-04-29 11:08 数据修复完成
解决方案：
手动触发相关商品快照生成
后续Action：
创建备份库实例，将已归档至OSS的数据恢复至备份库，商品修改查询快照代码，同时查备份库
4.复盘：
1.订单查询的快照应该由订单域自己来维护，不然库存和价格也都要对订单域进行相关字段对快照维护
2.快照表设计有缺陷，维护了太多无关的字段，导致单条记录过大，并且没有进行分库分表，导致单表的数据量过亿（15个月的数据，500G），从而影响整个库的查询性能
3.在快照表清理的方面决策太过草率，没有实际结合业务场景，仅凭经验主义就删除了最早7个月的历史数据，没有考虑过部分动销商品可能价格从没变动过，因而只在商品创建时生成了一条快照记录
4.接到故障反馈后，第一时间从日志捞取问题数据，进行数据修复，重新生成对应商品的快照数据，保证线上出现问题的相关商品可以正常下单；与此同时协同DBA及TL商定解决方案
方案一：调整代码，增加备份数据的数据源，直接使用阿里云的DAL对OSS进行SQL查询未在主库查到的快照数据，由于性能问题PASS
方案二：增加数据源的思路不变，使用新的数据库实例，将归档数据还原，当天紧急发布上线，已解决该问题
5.后续操作：
1.写脚本检查3个月内变更的动销商品是否在主库中存在快照记录，如果不存在则从备份库中获取相关快照记录插入至主库快照表，（新的备份库实例4核8G，每个G每天的存储成本约在50～100RMB）
2.推动订单域进行快照方案的进行，商品后续不对快照进行维护