数据库秒级平滑扩容
最后更新于：2022-04-02 04:12:43
[TOC]
## 停服务方案
1. 站点挂一个公告“为了为广大用户提供更好的服务，本站点/游戏将在今晚00:00-2:00之间升级，届时将不能登录，用户周知”
2. 停服务
3. 新建y个库，做好高可用
4. 数据迁移，重新分布，写一个数据迁移程序，从x个库里导入到y个库里，路由规则由%x升级为%y
5. 修改服务配置，原来x行配置升级为y行
6. 重启服务，连接新库重新对外提供服务
整个过程中，最耗时的是第四步数据迁移。
回滚方案：
如果数据迁移失败，或者迁移后测试失败，则将配置改回x库，恢复服务，改天再挂公告。
**方案优点**：简单
**方案缺点**：
1. 停服务，不高可用
2. 技术同学压力大，所有工作要在规定时间内做完，根据经验，压力越大约容易出错（这一点很致命）
3. 如果有问题第一时间没检查出来，启动了服务，运行一段时间后再发现有问题，难以回滚，需要回档，可能会丢失一部分数据
## 秒级平滑方案(推荐)
**成倍扩容，避免数据迁移**
改为
主要修改两处：
1. 数据库实例所在的机器做双虚ip，原来%2=0的库是虚ip0，现在增加一个虚ip00，%2=1的另一个库同理
1. 修改服务的配置（不管是在配置文件里，还是在配置中心），将2个库的数据库配置，改为4个库的数据库配置，修改的时候要注意旧库与辛苦的映射关系：
```
%2=0的库，会变为%4=0与%4=2；
%2=1的部分，会变为%4=1与%4=3；
```
这样修改是为了保证，拆分后依然能够路由到正确的数据
### reload配置，实例扩容
服务层reload配置有这么几种方式：
1. 比较原始的，重启服务，读新的配置文件
2. 高级一点的，配置中心给服务发信号，重读配置文件，重新初始化数据库连接池
reload之后，数据库的实例扩容就完成了,对服务的正确性和可用性完全没有影响
**但是**
1. 即使%2寻库和%4寻库同时存在，也不影响数据的正确性，因为此时仍然是双主数据同步的
2. 服务reload之前是不对外提供服务的，冗余的服务能够保证高可用
完成了实例的扩展，会发现**每个数据库的数据量依然没有下降**，所以第三个步骤还要做一些收尾工作
### 收尾工作，数据收缩
有这些一些收尾工作：
1. 把双虚ip修改回单虚ip
1. 解除旧的双主同步，让成对库的数据不再同步增加
1. 增加新的双主同步，保证高可用
1. 删除掉冗余数据，例如：ip0里%4=2的数据全部干掉，只为%4=0的数据提供服务啦
这样下来，每个库的数据量就降为原来的一半，数据收缩完成
';