数据库
首页 > 数据库> > MySQL数据库机房裁撤问题总结

MySQL数据库机房裁撤问题总结

作者:互联网

背景:公司某一机房需要裁撤,涉及到大量DB服务器,需要在裁撤截止日期以前完成业务的平滑迁移和设备退还工作。

历时2个多月,经历了设备梳理、裁撤资源评估、裁撤资源申请、裁撤DB部署、裁撤DB业务关系梳理、裁撤DB合并协调、裁撤DB数据迁移、裁撤DB切换、设备下架和退还等流程后,终于将组内涉及到的DB都裁撤完成。裁撤期间遇到很多问题,总结一下,希望对大家有帮助。

一、裁撤遇到的问题

1、存在着很老的版本比如4.1、5.5的版本

2、表字段使用系统关键字带来的兼容性问题

3、表没有主键,导致从机有的时候延迟很大(row format)

4、数据库中存在大量的MYISAM的表

5、部分实例数据量很大,超过1T

6、项目经久失修,找不到负责人

7、没有名字服务或者proxy,裁撤需要业务修改IP,如何做到平滑切换

8、用于裁撤的资源很少

历时2个多月,经历了设备梳理、裁撤资源评估、裁撤资源申请、裁撤DB部署、裁撤DB业务关系梳理、裁撤DB合并协调、裁撤DB数据迁移、裁撤DB切换、设备下架和退还等流程后,终于将组内涉及到的DB都裁撤完成。期间不仅仅将各个业务梳理清楚,并且对裁撤实例进行了清理和合并,仅用12台设备就完成了全部实例的迁移,并且实现0故障裁撤。裁撤期间遇到多个问题,总结一下,希望对大家有帮助。

二、问题解决方法论

1、系统思维

从全局的角度去看待遇到的问题,解决问题的时候不要只盯着某一个出问题的点,而应该站在更高的维度去思考解决方案。

2、资源整合

3、双赢思维

裁撤是一项需要运维、研发、资源、质量等同事一起协作的事情,我们目标就是为了业务平滑进行迁移和切换,我们在做事情的时候,要多从双赢思维中入手。其实本质就是要尝试站在对方的角度思考问题,自然更能找到双赢的解决方案。

三、解决方案

1、针对版本问题的解决方案

将DB全部迁移到mysql 5.7版本,迁移数据分为3步即可解决绝大部分的兼容性问题

a、只迁移业务数据,不mysql库数据

b、迁移权限

c、做主从同步

针对4.1的同步不兼容的问题,由于业务改动小,采用了的方案为:

直接解析binlog将新产生的数据同步到新的DB上,多次迭代,确保DB的差距最小后,直接停掉老DB,将少量新增的binlog通过工具同步到新DB上,并启用端口转发,将新的请求转发到新DB,停机时间1分钟以内。后面再让业务平滑修改业务到新的DB上。

2、针对表字段使用系统关键字的解决方案

业务表使用系统关键字在mysql 5.7中会人为SQL语法错误,从而导致sql执行失败,有2个解决方案:

a、修改表的字段,兼容mysql 5.7(这个方案会导致业务侧需要修改大量的代码)

b、对字段的所有操作都加上反引号(这个方案对业务影响小,我们采用的就是这个方式)

3、针对表没有主键和MYISAM表的问题

针对表没有主键和含有很多MYISAM表的问题,为了方便管理,对裁撤的实例都进行梳理,并且在裁撤过程中完成改造。长痛不如短痛。

没有主键的解决方案

和业务沟通,统一在新实例中增加主键(现存字段)

MYISAM的解决方案

和业务沟通,统一在新实例将MYISAM表全部修改为innodb

4、针对项目经久失修的问题,只能通过抓包确定对应的负责人,这里的梳理工作确实非常繁杂;

5、针对实例数据量很大的解决方案

由于设计到版本升级,无法采用物理备份的方式进行,因此采用的是mydumper多线程备份的方式,导入的时候,将mysql相关的表全部移除。另外导入的时候不要记录binlog,新DB主从都导入(不要做好主从后,只在主机上导入),或者在主机导入完成后,直接通过拷贝文件的方式做从机。

6、针对没有名字服务或者proxy,做到平滑迁移的解决方案

之前老的DB没有名字服务和proxy,如果要做切换,需要业务侧去修改各个server的配置,由于项目经久失修,大部分初始开发人员基本都已经离职或者转岗,很容易出现修改遗漏,如何实现平滑迁移是重点要考虑的问题,我们采用的方案是使用端口转发的方式,端口转发完成后,业务就可以从容地去修改业务的配置了。使用端口转发有如下几种常见的方式:

a、使用iptables进行转发

优点是不需要停mysql,可以做到真正的平滑迁移;缺点是处于安全考虑,公司的linux机器都没有加载nat模块,老系统如果要加载nat模块需要编译内核

b、使用ssh进行端口转发

优点是一条命令即可完成,非常方便,也不需要做改造;缺点是需要停mysql,会造成短暂的业务中断;

c、使用haproxy进行端口转发

缺点是需要额外部署和配置haproxy,也需要停掉mysql,会造成短暂的业务中断;

d、使用lvs进行端口转发

缺点是需要额外安装和配置lvs

经过综合考虑,我们选择了通过ssh端口转发的方案。范例:

ssh -f -N -g -L3306:newDBip:3306 root@localip

注意:有部分系统ssh命令不支持-N参数,去掉-N参数即可。此外还需要注意的是需要给老DB的机器进行授权,否则会由于权限问题带来访问失败的情况。

7、用于裁撤的资源很少的解决方案

机房裁撤的时候,资源侧给的裁撤资源肯定不会按照置换比1:1置换,而DB数据量一般都比较大。我们采取的方案是清理能清理的数据、合并能合并的实例。

四、DB裁撤问题的思考

经历一次裁撤,真的有种“不会再爱了”的感觉,每次都非常痛苦。要规避这种痛苦,只有从架构上去规避这种业务直连DB带来的问题。可以采用netagent/名字服务/l5等。在后面的DB接入中,需要将此种需求纳入到数据库的准入标准中。



作者:飞鸿无痕
链接:https://www.jianshu.com/p/5e55d29dbd57
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

标签:裁撤,解决方案,MySQL,DB,业务,机房,mysql,转发
来源: https://www.cnblogs.com/zping/p/11022463.html