前言：在实际项目中,我们可能会出现业务扩展,但是现状却无法满足,需要对现有的表字段扩容或者增加字段等情况,但是如果数据库的数据量如果过大,我们就需要考虑修改字段带来的影响.在这里我分享一个我在实际项目上因为对字段进行扩容引发的事故。
一、背景
由于业务方提出需求,我们现在库存无法满足,经过沟通我们决定采用对库存中的一个字段进行扩容,但是在扩容期间业务方反馈出现大量调用服务超时问题。
二、问题定位和原因
当业务方出现超时时候,我们就迅速的查看日志和我们服务管理平台,发现服务整体的响应时间变慢,然后就想起扩容问题,然后就停止扩容,经过分析发现,原来dba的同事修改字段采用的alter,导致在修改期间锁表,这样一来业务大量的请求就出现等待,而数据库连接长时间无法被释放,这样一来就出现了业务方超时。
三、alter修改原理
- 先进行锁表
- 创建一张临时表
- 将老表的数据拷贝到临时表中
- 修改源表名为old表,把新表的表名修改为源表名,删除old表
四、热修改原理
后来dba同事对数据量大的就采用pt-online-schema-change这个工具进行修改,下面我简单说下原理,想研究更透彻可以网上找下教程自己去学习
- 创建一张临时表(表结构则是修改后的表结构),并从源数据表向新表导入数据
- 创建触发器,用于记录从导入数据期间所有操作表(增删改)的操作,主要用于拷贝后执行触发器保证数据不会丢失
- 导入数据结束后短暂锁表然后执行触发器
- 修改源表名为old表,把新表的表名修改为源表名,删除old表
- 删除触发器
五、后续问题规避
如果不到不得已不建议修改线上数据苦,如果真的修改注意下面几点
- 找dba分析修改的源数据表需要锁表的时间(数据量小采用alter,量大则采用热修改)
- 是否可以接受锁表的时间(如果不能接受则需要采用其他方式)
- 修改表安排在流量小的时候比如晚上6点后,并观察dba数据连接池变化、日志变化、服务耗时的时长等,如果有异常停止修改