数据库容器化｜未来已来

2017年12月09日 来源：CSDN技术头条 作者：熊中哲

关键字：数据库数据库运维

“你不是不够好，你只是过时了”这句话用到 IT 行业特别合适，每隔一段时间都会有新的技术出现，让码农们应接不暇。借着回顾DBA工作中的几个时期，跟大家分享我们对下一代数据库运维架构的理解和目前正在做的工作。

明星 DBA 层出不穷的时期

刚进入阿里时听过一句话一直记到现在，“要像了解自己的老婆一样了解自己管理的数据库”。当年我还没有结婚，对这句话的理解并不深刻。

这应该是@冯春培说的，当年进阿里的面试考官之一，大家都服气的称他为大师。

这句话后面其实隐含了一个背景：相比现在，当时的应用迭代较慢，架构集中，尤其是在数据库层面，用比较流行的叫法是巨石型“monolithic”应用。

在数据库数量、容量和业务需求都没有爆发的情况下，更需要 DBA 做出极致的优化，更强调对数据库内核的掌握，10年前混过 ITPUB 的都知道，当时的 DBA 都是以写出极其复杂的 SQL 和掌握 Lock、Pin、Latch 运行机制为荣的。

还记得，当年每条 SQL 上线都需要 DBA 审阅，这也是 DBA show muscle的最好机会。

巨石型应用突出了DBA 的重要性，那是一个明星 DBA 层出不穷的时期。

DBA 的转型期

后来有机会去了百度，作为一名 DBA ，给我的冲击很大，总结下来有几个不同：

数据库以 MySQL 为绝对多数，并且大多数都是由开发自己运维

DBA 团队刚刚组建，目标是集中管理集团的所有数据库。当时整个团队不到15人，线上运行的 MySQL 实例1000+

没有 SQL Review

1000+实例和15个 DBA，这时我刚结婚，虽然时间不长，但我马上意识到 “要像了解自己的老婆一样了解自己管理的数据库”恐怕是做不到了。

工作的重点不再是学习数据库内核和SQL Review，而是转而将大量的日常运维工作脚本化，自动化(其实是人肉+半自动)。当时没有Puppet/Ansible，一刀一斧都得自己来，不得已，又捡回编程的手艺。这个时候，我从关注少量库的性能 (Load， TPS， QPS)，到关注大量库的可用性，主要包括：

监控的配置和有效性

空间是否足够

备库恢复是否正常

是否有备份，备份是否有效

硬件是否有故障

没有SQL Review这样奶妈式的贴身服务，如何能解决性能问题呢？总结下来就是：

将复杂的SQL拆分成多个简单的 SQL，将复杂性留给应用

做好Scale Out的架构，性能不够就扩节点

多说几句：

Scale Out：要支持Scale Out架构，应用需要做些改造。说一个常见的问题， MySQL集群的各个分片如何高效的，不重复的获取自增序列作为 PK 或者 UK 呢？在 Oracle Rac 里面，sequence让一切变得简单，DBA 关注的只是如何优化获取 sequence 的效率。但是在百度，我第一次知道原来可以通过 zookeeper 解决这个问题。