MySQL 线上日志库迁移的解决办法

这篇文章主要为大家详细介绍了MySQL 线上日志库迁移的简单示例，具有一定的参考价值，可以用来参考一下。

感兴趣的小伙伴，下面一起跟随数据库教程的小编来看看吧！

说说最近的一个案例吧，线上阿里云RDS上的一个游戏日志库最近出现了一点问题，随着游戏人数的增加，在线日志库的数据量越来越大，最新的日志库都已经到50G大小了，在线变更的时间非常长。

之前之所以没有发现，是因为之前一直没有进行过日志库的变更，但是随着业务的深入，需要增加一些游戏属性，要对之前的日志库进行变更，这样一来，长时间的维护窗口让业务方和DBA都望而却步，日志优化迫在眉睫。

首先看日志库的情况：

1、日志库中数据量大于5000w的大表有5张；

2、这5张表开量前每个月的数据量大概在2000w左右，开量后会更多；

3、有2个表的索引大小已经超过数据文件大小

询问了业务方和运营对这些表的要求，具体如下：

1、保留最近这3个月的数据，其他的数据可以进行流转，避免影响线上业务的性能。

2、3个月之前的数据流转到一个本地库中，可以支持查询即可，查询速度不能过于慢，分钟级别的可以接受。

3、日志库在迁移的过程中，能够容忍几分钟的表数据丢失，对数据的同步实时性要求不是很高

4、线上的日志库需要支持用户活跃度等统计

5、不希望执行分库分表，有很多查询近几个月的SQL操作，表之间存在一定的耦合性，分表之后不利于关联操作

基于上面的分析，结合实际情况，初步设想的方案是：

1、对线上数据库game_log中的表进行rename操作，然后将原来的表重新创建出来，这个过程中不是连续的，可能会丢失几秒钟的数据。具体的操作如下：

代码如下：

#第一步
rename table game_log.table to game_log_bak.table;

#第二步，获取表结构，其中重要的是auto_increment的值，
#保证后续导入三个月内数据的时候不会发生冲突
show create table game_log_bak.table\G

#第三步
在game_log库中重新创建第二步的表结构

MySQL 线上日志库迁移实例

2、将rename过后的game_log_bak库中的数据流转到本地的离线数据库中，该数据库采用infobright存储引擎，这样能够支持离线数据的快速查询

3、备份并清理线上表3个月之外的数据，大概是40G，并将线上的game_log_bak数据库中3个月以内的数据（大概10G）重新灌入game_log数据库中，这样结构就变成了：

4、删除game_log_bak库，并搭建一个只读从库，实时的从主库上同步game_log库的信息，如下：

5、从本地的只读从库中，像本地的infobright数据库中同步数据，同步的方法可以选用dataX工具，像下面这样：

6、设置定时任务，按照一定的周期清理线上的过期数据，确保线上只保留最近3个月的数据，不会对rds的磁盘存储空间产生压力。

这个方法中，目前看来存在下面几个问题：

1、经常性的清理线上数据，这些数据占用的表空间不能被立即回收，可能会造成数据表的碎片问题。

2、后续如果游戏的量级上来之后，使用这个问题可能还是会有问题，届时可以适当调整日志表的清理周期，如果数据量过大，可以考虑其他的方案来处理。

回过头来分析，表的设计上还是存在一定的问题，日志表中记录的应该只是流水数据，尽量不能出现关联查询的情况，或者说可以提前评估数据量，然后使用季度表或者月表来处理这种的大量的日志情况，这样在清理和维护的时候可能就方便的多。

以上就是MySQL 线上日志库迁移实例的详细内容，更多关于MySQL 线上日志库迁移的资料请关注512笔记其它相关文章！

注：关于MySQL 线上日志库迁移的简单示例的内容就先介绍到这里，更多相关文章的可以留意