由于讲述内容较多,故拆分了四个小篇
MySQL 数据库平滑扩容方案剖析 - 第一篇_YZF_Kevin的博客-CSDN博客
MySQL 数据库平滑扩容方案剖析 - 第二篇_YZF_Kevin的博客-CSDN博客
MySQL 数据库平滑扩容方案剖析 - 第三篇_YZF_Kevin的博客-CSDN博客_mysql 数据扩容
MySQL 数据库平滑扩容方案剖析 - 第四篇_YZF_Kevin的博客-CSDN博客
方案四:(平滑 2N 方案)
原理是:每个数据库配置一个从库,读写分离架构,从库和主库数据基本保持一致。扩容时把所有的从库都变成主库,这样主库就从N个变成了2N个,哈希算法从%N变成%2N
操作步骤如下
1. N个主库,每个数据库配置一个从库
线上数据库,为了保障其高可用,给每台主库会配置一台从库,主库负责读写,从库负责读取。下图所示,A,B 是主库,A0 和 B0 是从库
2. 扩容时把从库升级为主库,此时变成2N个主库,0个从库,同时上层修改hash算法,从取余N, 变成取余2N
当需要扩容的时候,我们把 A0 和 B0 升级为新的主库节点,如此由 2 个主库变为 4 个主库。同时添加上层的分片配置,做好哈希映射,规则如下:
把 uid%4=0 和 uid%4=2 的数据分别分配到 A 和 A0 主库中
把 uid%4=1 和 uid%4=3 的数据分配到 B 和 B0 主库中
因为 A 和 A0 库的数据相同,B 和 B0 数据相同,此时无需做数据迁移。只需调整变更一下数据库配置即可,通过配置中心更新,不需要重启
由于之前 uid%2 的数据是分配在 2 个库里面,扩容之后需要分布到 4 个库中,所以需要对冗余数据做一次清理。这个清理,并不会影响线上数据的一致性,可以随时随地进行
举例一:uid为3 => 扩容后数据在从库
扩容前,两个数据库,哈希算法3%2=1,数据在数据库B,数据库B0是从库,也有这条数据;
扩容后,四个数据库,哈希算法3%4=3,数据在数据库B0,由于B0之前是B的从库,有这条数据,但数据库B中也有这条冗余数据,后面再清理即可;
举例二:uid为4 => 扩容后数据仍然在主库
扩容前,两个数据库,哈希算法4%2=0,数据在数据库A,数据库A0是从库,也有这条数据;
扩容后,四个数据库,哈希算法4%4=0,数据仍然在数据库A,但数据A0中也有这条冗余数据,后面再清理即可
根据以上举例我们可以发现,2N扩容后,原来的主库,从库中都有一半的冗余数据,不过这些数据后面随时都可以清理
3. 为现在的 2N个主库的每个主库都配置一个从库,一是可以保证数据库的高可用,二是为了下一次的2N扩容,至此,升级数据库操作全部完成
方案四总结
1. 由于旧的主库一直在进行CURD,从库不可能完全和主库一致,所以需从库和主库完全同步结束时才能升级成主库,也就是说需要主库停止写入一段时间,办法可以是停服一小段时间,也可以是开启主库只读一段时间
2. 三个小步骤:从库升级为主库;逻辑层把哈希算法从取余N变成取余2N;为2N个主库再配置一个从库;这个三个小步骤要全部完成后才算是彻底完成数据库升级,服务器才能继续提供服务
3. 此种方案需要随时有相同个数的从库