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