记一次库级别的拆分

背景

线上有个 LBS 的端口，每秒1600左右的写入，从库经常延迟。经观察后发现大部分写入操作都集中在更新某个 DB 上，该 DB 容量也有将近 400G，占了整个端口的 70%，并且容量还处于上涨的趋势。大量的 update 导致从库追不上，对于日常备份、扩容都是问题。（如果表结构以及 update 语句使用不当，update 造成的资源消耗将会非常多，可参考何登成的 MySQL 源码分析视频）

需要解决的问题

容量问题

延迟问题

备份问题

解决办法

和开发商量后决定对该 DB 进行拆分，思路是一拆多，分摊主库写的压力，同时也能分散主库容量压力，也有利于备份。具体如下

库名 wifi 下有 256 张表是主要的更新对象，考虑到对写入量和资源分配的折中，决定将 256 张表拆分到 4 个不同的新端口。

最终1端口保留如下表

wifi_00.ibd ~ wifi_3f.ibd

最终2端口保留如下表

wifi_40.ibd ~ wifi_7f.ibd

最终3端口保留如下表

wifi_80.ibd ~ wifi_bf.ibd

最终4端口保留如下表

wifi_c0.ibd ~ wifi_ff.ibd

具体拆分步骤如下：

一、基于已有的从库或备份扩容出从库 s1，修改配置文件（和其它从库一样连到主库，配置过滤条件，只复制需要的 DB）

replicate_wild_do_table = wifi.%

replicate_wild_do_table = mysql.%

replicate_wild_do_table = 其它内部使用的库

二、在扩出的从库 s1 上删除其它不需要复制过滤的 DB，例如：

drop database ip

drop database cell

三、没问题后停 s1，拷贝三份数据 s2，s3，s4 至其他机器，修改 server-id，buffer pool，端口号后启动复制。

1)stop s1

2)rsync to 其它三台机器

3)在每台机器上：改数据目录权限，改配置文件以及里面的端口信息

4)start ALL_PORT

5)观察一段时间

四、前三步没问题后基于 s1，s2，s3，s4 扩容出相应的从库，修改从库的配置，重新 change master。通知业务切换对 wifi 库的写读。

1)四个端口分别 stop 实例，rsync 数据到相应的从库，传完后按序启动源实例，分别记录下 master position，启动前将 log-slave-update 改为 1

2)分别到相应的从库修改如下配置：

server-id、删除 replicate_wild_do_table 参数、开启复制

3)change master to 步骤1）记录下的点位

4)观察一段时间，如没问题通知业务修改代码逻辑。先开放读，切换时再开放写

五、drop tables。

1)观察一段时间，等业务已经将读写分离后，再将各自端口不需要的表 rename，每个端口保留 wifi 库中表的 1/4 即可，端口之间不能删重了。期间可抓包、或者查看数据文件的最后修改时间或者跟业务确认，来确定是否 rename。

2)继续观察一段时间，跟业务确认保证读写已完全分离后再 drop 掉 rename 后的表。

3)确定源端口主库已没有 wifi 库的读写后，将新端口的主库 stop slave。新端口稳定后，可以将源端口的 wifi 库删除。

六、指定备份策略等其他善后工作。

总结

1、拆分之前要做好拆分计划，以及计划的具体实施步骤，落实到每一步，该注意什么，免得操作的过程配置出差错，延缓整体拆分时间。

2、拆之前要找几台好机器，免得延迟大了，时间拖得久。

3、传数据的时候以一传一的方式，比如 A 传 B，B 再传 C，这样 A 传完就可以启动服务，可能会节省整个过程的时间。

4、在迁移读写策略前，需要先停原主库的数据写入，等新端口的数据都应用完后再切换读写逻辑。

5、读写切换后，需要观察数据文件是否按照预期进行更新。

6、拆分过程帮助开发解决了一个遗留的历史问题。256 张表里面其中有张表竟然少一个字段，但开发一直没察觉。

7、拆分后写入量降为 300-400，一段时间后业务量增长，每个新端口又恢复到了 1000 左右的写。