前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL线上日志库迁移优化案例

MySQL线上日志库迁移优化案例

作者头像
AsiaYe
发布2019-11-06 17:12:08
6760
发布2019-11-06 17:12:08
举报
文章被收录于专栏:DBA随笔

MySQL线上日志库迁移优化案例

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

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

首先看日志库的情况:

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

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

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

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

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

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

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

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

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

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

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

代码语言:javascript
复制
#第一步
rename table game_log.table to game_log_bak.table;

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

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-10-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DBA随笔 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档