MySQL 数据库平滑扩容方案剖析 - 第四篇

 由于讲述内容较多，故拆分了四个小篇

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. 此种方案需要随时有相同个数的从库