一个MySQL连接问题的优化过程
发布日期:2021-06-30 13:21:50 浏览次数:2 分类:技术文章

本文共 2020 字,大约阅读时间需要 6 分钟。

这是学习笔记的第 2008 篇文章

  今天有一个开发同事反馈说通过sqoop在大数据和MySQL之间同步数据的时候,报了一个连接失败的错误。 

org.apache.hadoop.mapred.YarnChild: Exception running child : java.io.IOException: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.

顺着这些错误日志定位发现是大数据集群的新增节点无法访问MySQL导致。 

经过梳理,发现这个连接的问题竟然和大数据集群操作有关。问题的过程是这样的:

大数据集群管理员新增了集群节点,对于分布式系统来说这是对业务透明的。

sqoop做数据流转的时候,恰好数据就在新增的节点上面,但是新增节点是没有访问MySQL的权限的,也就导致了我们开始时所说的问题。

640?wx_fmt=png

对于这个问题,我们划分了4个角色,也是归属于4个不同的小组,彼此独立:

1)大数据管理组,集群节点的操作对于业务来说应该是透明的。

2)数据分析组,他们使用大数据集群,同时做数据流转的工作,对他们来说对于大数据集群的节点也是不关心的

3)数据库管理组,因为涉及到大数据到数据库的数据流转,DBA不知道大数据新增节点会涉及哪些数据库的权限变更。 

4)数据业务组,他们使用最终的数据,对于他们来说只识别MySQL端

通过上面的一些角色和基本的分工,我们发现看起来是一个简单的问题,实际上是一个流程化的工作。上游不关心下游的使用,下游不知晓上游的变更,信息在流转中出现了缺失。

所以这个问题只是冰山一角,这映射出权限管理的一个通用的问题。对于上下游之间如何衔接和有效配合,我们多个小组做了讨论,初步的想法就是通过邮件的方式来建立这个流程,我们可以叫它是一个邮件链。信息由变更发起方通知,在这里就是大数据管理组,他们发布变更通知的时候,需要同时附带关联的MySQL集群,而这个信息显然不是大数据管理组来获得,而是应该有数据分析组来提供,对于他们来说应该需要明确数据流转的细节,而这个邮件信息初步确认之后,DBA收到这个邮件信息之后就会根据提供的信息开通相应的权限,而这个操作对于数据使用方来说是无感知的。 

   而这个问题仅仅是个开始,我们在处理权限问题的时候发现这个数据流转相关的单表有近400G,数据量在17亿左右。 对于MySQL来说,这个表的数据操作就是一颗不定时炸弹,一旦出现慢查询,那执行时间都会无限放大。 

经过分析,我们大体理解了这几个大表的业务逻辑,大数据集群会去做计算,把计算后的结果数据导入MySQL中,这个导入的频率是T+1,也就意味着这是一个延迟1天的数据流转操作,比如今天是6月13日,那么流转的数据是6月12日这一天的。 所以按照数据的生成规律来看,使用典型的周期表业务就可以支持这种数据管理方式。 

假设表为test_data,则周期表为:test_data_20190601,test_dat_20190602,test_data_20190603

和业务方做了初步的沟通,会发现周期表可以实现这个需求,但是对于目前的问题来说,需要相关的多方都改动业务逻辑代码,要完成这个联调还是需要花费一些时间的。 所以业务同学是倾向于通过删除数据的方式,尽可能保留原来的表名,我们经过沟通提出了潜在的问题,即数据流转写入的时候,假设数据有300万,则在binlog中会记录这300万的数据变化,而要删除以前的数据,假设也有300万,则binlog也会记录这300万的数据变化,这样一来数据的代价就是600万,而使用周期表的方式,我们就可以很容易的控制表的数据,确认删除的数据使用drop产生的binlog很少,所以从功能和性能角度来说,我们是不建议在一张大表中存放数据按照时间维度来删除的。

    在当前的情况下,尽可能让双方都不做变更,我们可以间接的实现周期表,即表test_data名字不变,在20190603的这一天,写入test_data的数据是20190602的数据,则DBA在数据流转之后,就可以把表test_data改名为20190602,而复制完整的表结构信息新建表test_data.

这样一来整个数据库中的列表信息如下:

test_data

test_data_20190601

test_data_20190602

test_data_20190603

使用这种方式之后,对于业务使用经过确认是不需要改动的,但是对于DBA来说可以更加有效的管理数据。

下午的时候经过确认把原来的近400G的大表做了rename操作,整个数据流转的过程就更加轻量了。

640?

转载地址:https://jeanron100.blog.csdn.net/article/details/102479267 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:认知的偏差
下一篇:迁移到MySQL的架构演进(一)

发表评论

最新留言

很好
[***.229.124.182]2024年04月20日 05时23分53秒