日期:2014-05-16 浏览次数:20440 次
整理了一下思路,记录下。供以后参考吧。
?
?
前言:
游戏服务器。部分游戏数据。超过一定时间后。对玩家来讲,不再有很大的使用价值。但这部分数据却一直保存在数据库中。特别是如:玩家信件,道具消费日志,等每日增加量比较大的表。问题尤其明显。
?
目标:
1.将数据库中超过指定时间的数据,从游戏服务器数据库中,迁移到备份数据库中。
2.并实现迁移目标分表的自动切分。
3.各待迁表支持设置不同的迁移间隔。
4.每次迁移备份后。将处理结果发送邮件。
?
分析:
1.仔细分析要迁移的表结构可以发现。这些表都有添加时间(createDate)类的字段标志。某些表可能出了添加时间外,还有其他的判断依据。如任务记录类。为了尽可能的保证迁移数据的正确性,还要添加任务状态的条件(state=9)类。
2.同一款游戏,不同的游戏分区。表结构基本上时完全相同的。要做的备份迁移的逻辑也基本一致的。
?
设计:
不同的最终要求,可能设计的具体方案不尽相同。
?
已知:
1.mysql存储过程中,不支持如oracle里的dblink。所以一个存储过程里调用不同机器上mysql查询,暂时实现不了。
2.mysql存储过程中,不支持动态创建数据库。但可以动态创建表。
?
准备:要迁移备份的表信息,配置表。
transfer_database_info;?????
--游戏分区信息(含:数据库名,分区名,用户名,密码等)
--主要是考虑最复杂的情况时,如,多个游戏分区在不同的电脑上。备份服务器在另外电脑上时候用。
??
transfer_table_template;????
--迁移表模板(含:表名,鉴别字段,分表间隔,迁移间隔,是否备份)
--分表间隔,过多久将备份库里面的目标表切分
--迁移间隔,每个表要迁移的间隔不尽相同。有的可能迁移3各月前的,有的可能1个月前的旧可以迁移走。
--是否备份,有些数据可能再也没有用到得可能了。只需从运行库中删除,不需备份到备份库里
?
transfer_setting_info;?????????
--前两个表的一个整合表,保存实际迁移备份过程中。实际需要处理的所有表。
?
只所以这么设计,主要是基于分析2.
?
辅助表:
transfer_table_log;
--(transferSettingInfoId,createDate,destTableName)
--记录待处理表中,要在备份库中生成的目标表表名。
transfer_task_log;
--迁移备份的日志。每运行一次该任务。生成一条日志。
?
-------------------------------------------------分割线-------------------------------------------------
实现目标一:
1.在游戏所在的服务器上,同一个mysql进程下。备份各区的数据到一个库中。
?
实现:
考虑用存储过程实现。在linux中添加shell脚本,创建cronjob。每天或指定时间运行该任务即可。
伪代码:
创建存储过程{ 迭代transfer_setting_info{ --第一部分: -- 本次迁移环境信息获取。主要是找到要迁移的源表,迁往的目标表 { 取出数据库,及表配置信息。 设置:当前要迁往的目标库。--后面用; 按transfer_setting_info.id检查备份目标表 (transfer_table_log中destTable)是否存在。 不存在,新建表; 设置当前要迁往的目标表(新建的表)。 存在,按表模板里配置的信息检查是否该分表 { 分表。不分表 设置当前要迁往的目标表。 } } -- 第二部分:迁移 1.拼接sql中where条件。模板里配置的.按多少天或多少月。等 拼出,本表的具体条件。 --本表需要备份:往目标表插入 { insertsql := concat(" insert into desttable select * from sourcetable where;"); execute insertsql; } --源表:从源表按where条件清除 { deletesql := ; execute; } --拼本表迁移日志 } --记录总日志,本次迁移的日志。 }
?
shell脚本里,查询最新日志。发送邮件。
?
?
实现目标二:
1.在游戏所在的服务器上,同一个mysql进程下。备份各区的数据到不同个库中。
?
由于mysql存储过程不支持动态创建库。所以在设置备份信息时候。先创建好备份库。
其他实现基本同目标一。
?
实现目标三:
1.各游戏服务器在不同机器上,备份库在另一台机器上。
?
思路一:
1.用java写个小程序。连接不同的数据库。
2.先将要迁移备份的信息dump到备份机。dump可以支持--where的。因此是可以实现增量处理的。
3.然后将dump文件,执行到备份机的备份库中。
?
思路二:
1。将备份处理逻辑,分别放到不同的游戏服务器上。由不同的游戏服务器上的cronjob定期执行备份处理。
2。将游戏服务器上的数据文件,文件夹映射到远程备份机的指定文件夹下。
?
思路三:
借助,mysql提供的备份策略,mysql的增量备份策略等实现。只是粗粗看了下,感觉可控性不高。就没有试验。应该也是可以实现的。
?
?
?
?