滴滴MySQL架构及自动化运维工作

在上周4.14 北京3306π活动中,看到朱进桌分享了滴滴的MySQL架构及一些自动化工作,一方面感吧,滴滴同学面对的DB压力也比较大,另一方面也赞叹滴滴的DBA同学牛。

在这里小记一下:

滴滴的MySQL架构

 

这个结构算是一个数据库四层结构和美团,小米的数据库架构都有点类似,整体结合如下:

  • 第一层是基于LVS的一个FNAT接入, 对后面的dbproxy做负载均衡
  • 第二层是DBproxy ,在滴滴的dbproxy中好象没有分库分表功能,可以理解为是ProxySQL的基于port的分组或是读写分离(细节不多)
  • 第三层 基于MHA做的主从高可用切换。 看样子滴滴的数据库还没升级到GTID :),估计也是数据量太大,不好升级。 不过,还是值得考虑升级到MySQL 5.7.
  • 第四层 MySQL主从这块采用,双主结构,后面接两个从库。这个结构GTID环境中非常好运维。有点失误忘了问作者,他们是不是使用的GTID复制。

 

滴滴数据库平台中主要模块

从上面的主要模块来看,大多是基于开源来构建,来的快。 也正所谓作者讲的,平台小的时僮做自动化不划算,平台做大,再来做自动化,推动实在太难。 采用开源的东西,小做改造就可以快速的实用起来。

滴滴DB自动化整体架构介绍

从整体结构上看, 在自动化平台中实现了: 自动化备份恢复, 自动化表结构变更, SQL审计,SQL统计等在线辅助系统。在自动化这块大量依赖于saltstack实现。

在大规模自动化平台saltstack目前在国内许多公司得到验证都是可行的。 而且效果不错,当年飞信的自动化运维也是大量的使用saltstack封装。

滴滴自动化平台技术栈

看了这个图也深深的感受到现在做个MySQL DBA不容易啊。 除了MySQL需要搞定外, 还需要一堆的周边工具待你发现,同时还要会一门语言能把这些串起来,现在运维及云平台语言,基于是Python和Golang的天下。 作者讲解的东西比较多,整体上觉的滴滴还属于中规中矩,踏实做事。

如果想了解更多3306π是滴滴自动化 PPT信息可以关注 3306pai公众号,回复“bj”获取 3306π北京的PPT打包下载。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.