前言

合服，为什么要合服，当一个服务器数据下滑后，其一为了节省服务器硬件成本就需要合服；其二是玩家需要一定的热度环境。
合服最好的做法是数据结构等上线前都设计好，也准备好，尤其是账号角色重名处理等，这里会分几段讲。
没啥时间写，另外在研究新东西，这个也是拿我之前自己博客里改的。

内网预演

1）提前在内网进行一些业务的预演。2 个服的数据准备，不同的服务地址来区分，信息方面比如等级 or 积分排行榜信息，pvp 数据，pve 关卡排名等（需要 check 本次合服到上次合服是否有信息添加，来源是数据库表）。<--根据实际游戏业务来

---

2）在内网环境，数据库建立起码 2 个库，从库到主库，执行脚本合并。

---

3）预演几次后，如果已经成熟的 1 次就可以，脚本失败后，再次执行是否数据出现异常。

---

4）提前准备好外网所需要用到的区服账号，记录 roleid，区服信息，渠道账号、密码。

---

5）数据检查字段名数据正确，不为空；删除账号规则变更后脚本修改，没有变更则需要改时间戳

---

合服逻辑操作

1) 归集合并的游戏库到同一个 mysql 服务器,假设是 1,2,3 三个区合并, 数据库名字分别是 gm1,gm2,gm3.

---

2) 建立和现有游戏库相同结构的空库,空表. (检测每个库表结构一致) 该库作为合并后的新库.

---

3) 脚本.sql 默认会去合并名"sr"的库, gd1 的库名改为 sr,执行脚本合并到新库.

---

4) gm2 的库名改为 sr,然后也是这样合并.依次累推。合并成功 1 个区的库后需要检查 1 次。

---

脚本.sql
delete from db_表;
replace into db_表 (字段 1, 字段 2, 字段 3,字段 4,…)
select 字段 1, 字段 2, 字段 3,字段 4,…;
测试需要提前配置账号，检查哪些表，验证 delete from 是否干净（内网就是 1），外网预登陆也要检查次）

容易出现错误的地方：

---

合服后，发送奖励礼包，不能还是以之前服务器数量来发，以一组区服来发。要不会合并后的服务器，每个人可以多领到合并前服务器数量的礼包。
合并前没有检查是否之前的脏数据，内网测试量较少不一定发现，需要区域比对下，如果有这类解决不难，会影响维护时间
删除账号业务，时间戳甚至错误。
带附件的系统邮件和带交易缓存的交易行等，合区前会强制物品下到玩家空间内，合服这部分要重置后，才可以上架交易。

其他问题下文待续
我们除了测试还有什么，比如吃了不会辣眼睛的辣白菜