概述
公司经过多年的发展，数据库数据存储已经达到了使用年限，需要更改新的数据存储。随着年限的增加，数据也日益膨胀，用户、推广、客服等系统在庞大的数据中查询速度日益减慢，许多新的业务也因需要避免在海量数据中做查询而不得不另谋方法。为了达到未来一段时间内数据的安全、快捷，并适应以后的业务发展，对光宇社区数据库进行一次大规模的迁移升级。
[编辑] 操作步骤及经验
[编辑] 前期工作
创建新数据库AccountDB；AccountDB-Log；AccountDB-Freeze；CacheDB；AccountDB-FastMirror；AccountDB-Log-History。 创建相应的表及存储过程。 创建数据库访问用户并做好权限分配。 做好ACL配置，确保网络畅通。 更改、添加涉及到的数据库访问字符串。 更改数据库迁移升级涉及到的代码文件，并在测试环境做测试。
[编辑] 即时操作
停止所有的站点，确保数据库不再有任何访问链接。
耗时：0.5小时 查找活跃用户（365天内没有登录记录的用户），导入原AccountDB中。
耗时：3小时 失误及经验：LogDB中的登录日志不全，最先使用了LogDB中的登录日志，浪费了小段时间。完整登录日志存在HistoryDB中。使用T-SQL导数据，速度比较慢，使用SQL SERVER导数据的工具，速度比较快。此处多花费1小时左右 分离原数据库，为传输原数据库做准备。
耗时：0.7小时 经验：最好使用脱机的方式，后期需要对数据进行核实校验的时候，还需要用到此数据库。分离后，在需要使用时，还需要重新附加。 在新服务器上附加原数据库，改名为AccoutnDB_Old。
耗时：0.2小时 在新服务器上创建AccountDB，并创建表、视图、存储过程、函数。
耗时：0.4小时 将活跃用户从AccountDB_Old导入到AccountDB中，将非活跃用户从AccountDB_Old导入AccountDB_Freeze中。
耗时：1.5小时 经验：2011.1.26数据库变为“可移状态”，导致有5条用户数据，在做count(*)操作时，无法得到此用户信息，但是在按条件查询时，又能查询到。为了查询此问题，多花费0.5小时左右。 将所有的user_id和account从AccountDB_Old导入AccountDB中。
耗时：2小时 失误：原表中，account字段为varchar(18)，新建时，建成了varchar(50)，占的空间会比较大，最后为了将varchar(50)更改为varchar(18)，多花费了1小时左右。 将LogDB中的登录日志导入到CacheDB中。
耗时：0.5小时 将LogDB中的修改密码日志导入到AccountDB-Log中
耗时：0.5小时 在10.0.0.234的测试环境中对基本业务做测试。
耗时：2小时 失误及经验：在新数据库创建时，没有将表上的索引带过来，导致数据库内存使用量迅速达到27G多，CPU使用率100%。创建索引后，内存增长缓慢，最后也停在27G左右，但是CPU使用率降低到2%左右。 开启所有站点，观察数据是否正确。
失误及经验：有一个获取用户信息的存储过程出现问题，导致游戏直时，充扣除了玩家的游戏卡却无法将元宝充入玩家游戏账号中。但是由于游戏直充日志比较全面，并且有相应的失败处理机制，我们在短时间内将失败订单全部重试成功。
[编辑] 并行操作
从(二)中3-9步期间，可以并行操作的工作有
更改所有涉及到得站点数据库连接字符串。 全面更新站点代码。 辅助验证数据库数据一致性。
[编辑] 总结
这种大型数据库迁移及优化工作，会导致玩家长时间无法登录和消费，需要有上级领导的大力支持；需要一个经验丰富的、沉着冷静的带头人，在处理前作细致的分析，处理中无误的操作以及处理后效果跟踪验证；需要多个优秀团队通力合作，齐心协力，在遇到问题时，能够互帮互助，分享自己的经验和智慧；需要整个公司兄弟部门的理解和支持，在系统出现问题时，能够理解并提供协助；需要玩家们的支持和理解，为了更好的游戏体验，能够接受运营公司的升级维护。所以先需要感谢大家提供支持和帮助。然后是在这个过程中，我们也学到了很多东西，这些都总结在经验里了。也存在许多不足。例如站点关闭时，没有给予友好的提示和引导；遗忘了HistoryDB中数据是最完整的；在时间的预估上，严格根据理论时间来计算，没有预留排查问题、解决问题的时间。
--Zhutianye 2011年3月8日 (二) 00:03 (CST)
