记录一次线上严重事故（变更表结构导致商城系统宕机）

事故一

事件：

早上 7点左右 ，商城表更新了价格字段精度(500万级)，导致商城系统系统不可用

影响：

1. 商城系统从 7点到11点间不可用 （严重级）
2. 报表系统整天不可用 （严重级）

事故解决过程：
（创建一个和原来一样的空表，加上需要变更的表结构，然后把原来表数据复制过来）

1. 早上9：30 点左右，商城表重新建立索引，商城系统恢复
2. 报表系统同步一直到12点发现还一直卡着，然后找阿里云技术解决，一直到20：00 才ok

技术原因分析：

1. 刷表结构导致商城系统不可用原因： 刷表结构后，表的所有索引需要重建，而polardb数据库创建从库建立索引失效，price 表每次全表扫描，查询时间平均 13秒，
   由于这个张表的查询时间过长导致所有的线程被耗尽，k8s 做健康检查的时候没有线程响应，k8s认为服务挂了（10秒未响应），kill掉这个应用

2. 报表同步问题：频繁修改dts同步表结构导致dts卡死，原因是 adb 数据库缓存过小，后来找阿里云那边搞好的

问题总结：

1. 之后我们需要严格对待表结构变更问题，之前数据量比较小基本变更一下表结构几秒钟就ok了，目前我们有些表的数据已经是千万级规模了，很容易出现锁表。

解决方案：

1. 以后所有的线上数据运维必须走dms工具
2. 涉及表结构变更的发版要提前做好预案

事故2：

事件：

早上 9：40 左右 ，因为要同步adb表结构需要删表，操作失误误把线上product库删掉了

影响：

整个系统从9：40到11点间不可用 （严重级）

事故解决过程：

1.恢复备份数据，耗时1小时左右 2.验证并补全错误数据

原因分析：

本次事故主要是人为操作失误造成

问题总结：

为防止人为操作失误 最好的办法是从流程上来解决 ， 为此以后所有的数据上线必须走dms审核工具，并且要做好数据备份，不允许直接操作数据库

远期改进：
1.做好分库分表，减少单表数据量

2.做好数据库的冷备，缩短以后数据的恢复时间