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

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

MySQL 数据库平滑扩容方案剖析 - 第一篇_YZF_Kevin的博客-CSDN博客

MySQL 数据库平滑扩容方案剖析 - 第二篇_YZF_Kevin的博客-CSDN博客

MySQL 数据库平滑扩容方案剖析 - 第三篇_YZF_Kevin的博客-CSDN博客_mysql 数据扩容

MySQL 数据库平滑扩容方案剖析 - 第四篇_YZF_Kevin的博客-CSDN博客

上一篇博客

MySQL 数据库平滑扩容方案剖析 - 第一篇_YZF_Kevin的博客-CSDN博客

我们介绍了mysql扩容时的问题，以及解决方案，需经历停服，增加库，迁移分发数据，重新开服后才能恢复服务，大大影响用户体验。那么有没有一种不那么影响用户，又能正常扩容数据库的办法呢？

再回顾一下方案一，问题就在于需要停服一段时间，如果我们不停服，只是停止写数据库，期间服务器以只读的方式维持有限服务，用户可以登陆，可以查看自己的数据，可以参与任何的非DB写入性活动，那也是一种不错的办法

这便是本篇博客要讲的第二种数据库扩容方案 - 停写方案

方案二（停写迁移再恢复方案 ）

1. 发布停写公告

为了进行数据的重新拆分，我们需要提前通知用户，比如：我们的服务会在 yyyy-MM-dd 进行升级，期间不可进行某些操作，给您带来的不便敬请谅解

2. 停写，中断写操作（或拦截返回统一提示）

每个数据库设置为只读状态，关闭写的功能。在 Service 层对所有的写请求进行拦截，统一返回提示信息，如：服务正在升级中，只对外提供读服务

3. 增加新的数据库节点

购买或建立新的数据库，建好数据库和表

4. 旧数据增量式迁移

将旧库中的全部数据按照新的哈希算法，将数据重新分配，更新到正确的数据库。注意迁移时不可删除旧库的冗余数据，因为正在提供读服务

5. 数据校验

开发一个程序对旧库和新库中的数据进行校验，比对，确保重分配是正确的

6. 更改数据库配置和哈希算法

Service配置中添加新库连接地址，账号密码等；修改 Service 层的算法，也就是将原来的 uid%3 变为 uid%4

7. 恢复写操作

打开数据库的写功能，去除 Service 层的写拦截提示

8. 清除冗余数据

按照旧的哈希算法，也就是uid%3，使用 delete 语句对冗余数据进行删除

方案二总结

优点：避免了长时间的停服，期间玩家可以登陆，可以查看自己的数据，可以做其他非DB写入性活动

缺点：类似方案一，造成了时间压力， 必须在指定的时间内完成迁移，且不能出错，每一步都要有回滚预案