背景
有一个业务需要分 1000 个库,每一个库中都有 80 个表,总共就是 80000 * 2 个文件。文件使用率还挺高,大概是 60000 * 2。
这个业务采用的高可用架构是 MMM,由于集群机器在硬件检查时发现有问题,必须要换掉。于是想了一个比较简单、影响面较小的方法去解决,就是找了另外两台机器迁移过去。同时,要求这四台机器属于同一个网段,VIP(虚拟 IP 地址)在机器之间可以漂移,这样业务就不需要修改 IP 地址即可迁移,相当于两次主从切换过程。
切换方案如图 16.1 所示。
从图 16.1 中可以看到,切换过程很简单,如下三步。
先将原来的写节点(db1)与一个新的节点(db3)切换成一套集群,也就是把在 db2 上面的 VIP(读流量)切换到 db3 上面,此时 db1 与 db3 组成一套新集群。
接着将 db1 和 db3 的角色互换,让 db3 成为写节点,db1 成为读节点。
最后,再将 db1 读节点上面的 VIP(读流量)切换到 db4 上面,此时新的集群就是 db3 和 db4,db3 为写节点,已经切换完成。这样的变更是晚上做的。做好之后,观察了一段时间,发现没有什么问题(因为压力小),所以觉得事情完成了,睡吧。 第二天上班之后,业务反映说迁移之后,数据库比原来慢了 10 倍(10 倍啊!感觉不可思议)。询问了一番,说没有任何变更,只是做了迁移之后就成这样了。同时经过观察,只有写库的读操作变慢了,而读库的读是不慢的。最后,业务已经受不了了,要求切换回去。还好,db1 还正在从 db3 复制,做了一个回退操作,把写挂在 db1 上面,把读挂在 db3 上面。神奇的是,问题解决了!好吧,那就先这样,走出去的路不能回头,总是要迁出去的,所以先在新旧两台机器上面挂着,查明原因后再切换回去(这样少做一步)。
以上是背景。
问题分析
环境对比
db1 写入时,db1 写不慢,读不慢,db3 也不慢。
db3 是新的硬件,db1 是老的、有问题的硬件。
db3 切换成写之后,在慢查询文件中明显看到很多慢查询(使用相同的语句查询,原来是 50ms,现在是 500ms),和监控是一致的。
db1 和 db3 配置文件有差别,如图 16.2 所示(左边是 db3 的,右边是 db1 的)。