rds事故
昨晚收到rds磁盘报警,本来就直接升级下磁盘就好了。可半夜不知道哪根筋搭错了,居然要想彻底解决这个问题。
这个表总共800G,但是里面索引居然又300G多。数据量是22亿。 索引里面有个聚集索引是一个int(11)+char(32)+char(32)
那就想着优化下这个索引。还翻了下代码,居然有申明索引名字的。看来没法新增索引来解决,还必须要删除旧索引,新建一个一样的索引的(prefix length)。
果然晚上脑子不清楚,都忘记22亿索引估计需要多少时间了。一小时600万,这22亿得多少小时啊。
结果居然执行了,还发现问题了。
1 | ALTER TABLE TABLE_NAME DROP INDEX IDX_XXX; |
结果rds出现了问题,删除了索引居然空间不释放。然后新的也建不上,而22亿的数据要是没有索引,你想这查询效率得有多低啊。
1 | ALTER TABLE TABLE_NAME ADD INDEX IDX_XXX(`xxxId`,`vId`(8),`oId`(8));" |
这里面有2个问题。首先就是没有确认原有的索引删除后磁盘空间是否已经释放成功,特别是在云上,这个就是个黑盒,必须通过api去获取。第二个就是要加这个索引需要多少时间没有计算过,22亿的数据,600万每小时,需要10多天才能加完。
这真是只有半夜脑子糊涂的时候才会想到干这种事情。那正确的做法是什么呢?
- 首先是修改代码,不要强制使用那个索引。
- rds扩磁盘(至少要保证新索引的大小)
- 新增索引
- 删除旧索引
- rds缩磁盘
所以以后前面不能半夜突发奇想要搞点什么,特别是线上环境。