一个数据库十年老兵的思考与总结

474 阅读38分钟

一、数据库开发

2011年从华中科技大学数据库与多媒体研究所毕业之后,免试被达梦数据库录取。其实真正进入达梦数据库的时间是 2009 年,当时是以实习的身份进入的。那时达梦数据库的主流产品还是 DM6 ,我在里面的工作内容是看 DM6 的源代码,当时第一次接触到了语法分析、yacc.yy、REDO、UNDO 以及执行器等概念,并在代码中验证了这些概念,从此走上了数据库开发的道路,打开了一个新的认知世界。

到 2010 年年中,我从武汉去了上海,因为达梦在上海有一个新的宏伟目标,即从头写一个数据库-DM7,我有幸见证了这个过程。“从头写”,所言非虚,我加入到开发工作中的时候,已经具备了一个简单的建表功能了,B 树相关的分裂及合并等还正在进行中,此后所有的工作,就像是在建一座大楼,一块块的砖砌在上面,到 2012 年,数据库已经可以用了,常用的功能都已经很完善了。我在其中,做了不少工作,包括 Job 模块、兼容 Oracle 的包的实现、pl/sql 的部分实现、调试 pl/sql 的调试器 dmgdb 的实现、dm 列存储的存储引擎的实现以及 Oracle 同义词 synonym 的实现等功能。

在开发 DM7 的过程中,我成长得非常快,作为一名数据库从业者,能参与开发一个大型数据库,非常幸运,通过实现 pl/sql 的功能,对达梦的执行器理解非常深入,对执行栈及指令生成跳转理解深刻,这为后来开发 dmgdb 以及进一步理解 gcc 的 gdb 非常有意义,并且我还记得,dmgdb 的功能、命令、使用方式,和 gcc 的 gdb 非常相像,这里面学到的最核心的理念是“旁路干预”,即用另一个活动连接或者线程去控制主线程,从而实现了可以在任何一个指令暂停、继续、断点设置等功能。这个理念其实和现在我们 MySQL 从业者都很熟悉的 MySQL 插件很类似,比如半同步、审计、MGR 等功能。

同时还实现过两个版本的列存储存储引擎,我在2011年就写过一篇文章,关于 DM7 的行列融合的功能(百度可以搜到,搜索词:行列融合),现在想来,当时已经是非常超前了,这也为后来从事 MySQL 运维及开发,打下了坚实的基础。

在达梦的三年时间,让我认识到了数据库的未来之好,数据库的技术门槛之高,作为写过达梦数据库代码的我,到现在都觉得,达梦数据库的技术,绝对可以称得上是先进,优秀,现在在分布式领域里面出现的一些设计方案,在2011 左右的达梦身上,已经实现过了,比如 MPP 的数据分片路由,任何一个节点都是路由节点,而且在某一个节点发现分片数据不在本地的话,可以将本地生成的执行计划打包,直接发送到对应节点来执行这个计划,而不是重新生成计划,这有赖于它强大的指令集,生成的指令有点类似C语言编译之后的执行码,或者汇编指令。就现在看,这些也是非常先进的,这样设计出来的数据库,兼容及扩展无疑都是非常容易的事情,所以这也是为什么现在去 Oracle 方案中,达梦可以做到让业务不需要改代码就可以直接迁移到达梦上的缘故。

二、初入运维

做了三年的数据库开发后,我开始感觉工作有点枯燥,看不到正向回馈,工作的内容都是一个个的功能实现,实现完一个又一个,需求就是功能,实现就是代码,与外界接触太少,没有机会了解真正的需求是什么,实现之后,也没有机会了解对方使用的如何,所以决定离开。

当时已经在工作之余看了一部分 MySQL 代码,对比之下,MySQL 的代码,当时感觉不太像一个数据库,没有什么设计,数据插入用一个 mysql_insert 的函数就搞定了?不应该分阶段吗?比如语法分析、语义分析、执行计划优化、生成、执行这样的步骤。熟悉之后,也慢慢接受了,但这种设计,肯定是不优美的,对于兼容性、扩展性,是没办法很好的保证的,现在想来,确实会经常出现一些牵一发而动全身的问题。

2013 年,我进入了现在所在的去哪儿网。做了运维才发现,工作内容与开发数据库的工作,简直天壤之别。首先面对的对象不一样,运维面对的是线上一个个活生生的 MySQL 实例,你做任何事情,首先得保证它们的可服务性,才能谈别的;其次,面对的人也不一样,运维面对的是真正的需求者,比如业务开发,他的需求是使用数据库以及更丝滑的使用数据库,更具体一些,就是如何能保证他这个数据库的可服务率。相比之前开发数据库的工作,需求更明确了。实现方式,那就看个人能力了,能力好,反馈就有保证,能力不好的话,经常出问题,那就自然会给你很多负面的反馈了。

三、如何提升效率 2013 年进入 MySQL 运维行业之后,我开始关注的内容不一样了,工作时所面对的对象也不一样了。DBA 通常都是一对多的服务,必须要保证公司的数据库有足够的可用性才行,这考验的是 DBA 的多方面能力,包括抗压能力、问题应急处理能力、解决问题的能力、学习能力、沟通能力等等,总结下来更多的是一个综合能力,在这种状态下,工作效率是必须要提升的,不然 DBA 就会无休止地在低效的工作内容中,不断地循环往复,这种状态,我一般称之为——旧式的 DBA 生产力。

旧式的 DBA 生产力,每个 DBA 的工作时间,都被这种低效的工作所占据,没有更多的时间做提效的事情,所以造成的结果是,频繁加班、熬夜、士气越来越低、头发越来越少,而数据库的可服务率很低。在这种情况下,必须要有人去打破这个恶性循环,去做一些提效的事情,进而实现不断的螺旋式的上升,而不是原地打转。这里讲如何提效,我想可以从以下几个方面入手:

1. 需求与实现

我们技术工作者,很容易出现的一个现象是,对自己所涉及的技术或者产品,或者业务等都可以提出来很多需求,或者整天在吐糟各种问题,比如一些不方便的点,低效的现象等等之类的,但很少有人能自己动手去解决这些自己发现并提出来的需求。

而反过来,这些技术及产品的开发者,他们的开发能力很强,却不是这些产品的用户,做出来的东西经常很反人类,或者干脆自我感觉良好,觉得自己已经把产品做到无可挑剔的地步了,不接受反驳,不接受新需求,或者即使有新需求,但需要需求方和开发者反复沟通,其中也可能会出现一些偏差,或者由于排期迟缓,或者周期太长等种种原因,最终没有下文。 其实在我看来,在某些时候,如果考虑二者能相互融合一下的话,比如自己的需求自己解决,这样结果会好很多,此时可能进入一种全新的状态,即产品里面,开发能力最高的,而开发里面,产品能力是最好的,如此有下面几个好处: 设计的产品可能是真正能解决用户需求的,也是用户真正想要的样子。

提需求的人,不需要等待开发去排期,自己就直接做了,不需要看别人脸色,不受制于人。

效率是最高的,不需要来回沟通需求,等排期。

个人成长明显,相对可以做到不被淘汰。

在 DBA 行业里面,这点更加明显,纯运维将来能走的路非常有限,需要有代码能力的支撑。

2. 基础数据建设

DBA 需要对自己所管理的资源,做到系统中有数据,而不是心中有数。因为随着系统越来越多,靠人的记忆去运维是非常不靠谱的,我们必须要有对应的系统去支撑,才能做到持续地,稳定地提供服务,有如下几方面原因:

人的记忆不具有传递性,如果人离职了,那相应的记忆也离职了。

人的记忆不能保证准确性,容易出现问题。

靠人的记忆去做的话,在合作场景下,顿时失灵,存在数据不一致的问题。

数据化管理效率高,准确。

数据化管理,可以实现数据共享,合作无缝衔接。

3. 自动化平台管理

有了基础数据之后,就可以在其基础上实现自动化了,只要有点自动化,就比人肉强,这有如下几个原因:

效率方面,自动化相比人肉,效率提升是可见的。

准确性方面,人为操作是最容易出问题的环节,自动化可以保证准确性,不需要因为频繁的操作失误而被动工作。

人非常不擅长重复性工作的,相反,机器很适合做这类型的工作。

自动化可以实现操作的规范化,标准化,智能化。

自动化可以解放 DBA,让 DBA 腾出双手,提更多的需求,DBA 再把这些需求实现掉,进一步提升效率,进入良性循环。

让 DBA 做更有价值的事情,DBA的耻辱是,一天审核了 1000 个上线 SQL 语句。

4.学会利用资源

说起资源,每个人都不陌生,对于 DBA 而言,资源通常可能包括机器、同事、朋友、经验、认知、大脑、书籍、网络、系统、平台等等之类的。这里所举的例子,都是客观独立存在的,会不会与你发生关系,这取决于你是不是要利用他,只有利用了,这些资源才会与你形成一个关系网,从而让你的工作更加高效,并且在你利用之后,你自己本人,也会在这个过程中,形成赋能效应,让你的能力变得更强。但如果你没有利用他,或者不知道如何利用,更甚者,根本就没有意识到他的存在,这样的话,他们的客观存在,并不会对你产生任何影响,而你的能力,极大可能会保持原地不动,因为我们所有现在所处的境地,都是由我们的认识决定的,或者说我们大部分吃过的亏,产生的损失,都是由认识决定的。

在意识到上面所讲的资源的存在之后,要不断地去利用他们,这样做事情的效率,自己的能力才会不断的提升。

另外,还有一种资源,我们也要学会利用,通常情况下,当你学会使用这种资源之后,你会发现,解决难度相 比之前,不可同日而语,这种资源就是——你的领导。

当你发现有些事情推进非常缓慢,或者解决起来各种阻力,所有你身边常用的资源都用了,就是很难解决,不断 delay,可能已经陷入僵局。这种情况下,你不妨把目光放在你的领导身上,也许在他的层次及角度上,解决起来,不费吹灰之力,另外,此时你可以关注一下他的解决方式,你会发现,他的解决方法正是你现在所看到的——学会利用自己的资源。

四、DBA应该尽可能聚焦

聚焦,对于我们技术工作者来讲都是需要的,这是一种工作和学习的方式,也是一种快速提升自己的方式,有以下几个方面,来保证我们可以做到聚焦:

1.做事情不能摊大饼 技术工作者,经常会犯的错误是,一个项目在规划阶段,规划的非常完美,动不动就来一个五年计划,实现方案考虑的非常周全,各种边界情况都考虑到了,为了解决这些边界情况,会把问题放大,导致解决方案放大无数倍,这样的做事方式是不可取的,所以在设计项目或者方案的时候,需要考虑以下一些问题:

大项目要拆分成多个子项目,或者分期完成,要把不同模块划分出来,一个个实现,并且这些模块可以阶段性地使用起来,而不是等到最后一刻和其它模块组合起来,才能被使用。

要想清楚做这个项目的初衷是什么,不要把项目方案放大,最终搞成一个宏伟的目标,这样可能永远也实现不了了。

根据项目初衷,设计一个能解决这个初衷的方案即可,不要因为解决一个小问题,而“创造”一个更大的问题出来。

开发者,也要定期向上反馈成果,不要让领导觉得项目是遥遥无期的。

2.避免陷入技术死胡同

就像上面所说的,掌握技术,或者精通技术,作为一个技术工作者是非常有必要的,但技术人员很容易陷入一种陶醉的状态,进入这种状态之后,就会处于一种只见技术不见初衷的局面了。

技术工作者,需要时不时地跳出来,从上帝视角去观察自己,现在做的事情是不是有意义的,是不是合理。如果不跳出来去审视自己的话,可能出现的局面就是——我们走的太远,已经不知道为什么而出发。这样的后果,通常可能出现的局面就是南辕北辙,做的东西并不是对方想要的,或者做完了,发现做的东西并没有解决问题,从而导致自己长期没有成就感,没有被领导及同事认同等等之类的问题。

技术工作者,还要避免的问题是,非常执着地追求“新技术”,新技术固然有吸引力,但我们还是要理性地去看待这个问题,关于新技术,有以下几方面的想法: 新技术,是相对旧技术而言的,通常会出现与旧技术不一样的表现形式,最常见的就是兼容性,带来的问题是,我们需要维护非常多的版本,老的下不掉,“新技术”的版本不断上线,久而久之,维护成本非常高,DBA及平台,需要处理各种新特性的兼容问题,处理不及时,就会导致出现故障之类的问题,吃力不讨好,所以面对新技术,我们扪心自问一下,旧技术是不是够用了?够用就好,这点在 MySQL 上面,我觉得够用的,但PG由于种种原因,会出现各种新技术,如果不谨慎的话,就容易出现上面的问题。

现在流行新技术 docker/k8s,有人经常问到我,你们 MySQL 用 docker 了吗?我通常是用两个成语回复,分别是隔靴搔痒,作茧自缚,你想上k8s,是为了解决什么问题?编排部署安装找资源的问题?MySQL 是一个有状态的大型通用数据库,这么重存储的服务,找资源安装,问题很大吗?又说是资源隔离的问题,资源隔离的需求很紧迫吗?单机单实例就不说了,即使在单机多实例的情况下,也没几个实例,并且 MySQL 本身内部就是多线程的,均衡问题也比较好,同一台机器上一个实例影响其它实例的案例少之又少,所以这需求有那么紧迫吗?而且对于使用 MySQL 没有上到一定量级的情况下,非 k8s 的自动化平台就可以很好的解决资源部署安装编排的问题,为了解决这个问题,创造一个上 k8s 的大问题,这样就有点和初衷背道而驰了。同时 k8s 是一个新的技术栈,支撑它上线,是需要另一个专业团队来做的,投入产出比非常低。我反过来再问一下, MySQL 本身的问题你解决完了吗?慢查询有没有好的工具去优化?主从切换能不能不影响业务?机器挂了能不能不丢数据?数据库服务能不能做到不同机房的多活?自动化 SQL 审核可以自助服务了吗?如果哪个没做到,那就先放弃 k8s 吧。再者,我们专业的 MySQL 运维技术人员,非要作茧自缚,给 MySQL 套一个壳,出了问题,是壳的问题?还是 MySQL 本身的问题?当引入一个变量的时候,可服务率肯定就会有一定程度的下降,因为 99.99%*99.99% 的结果是 99.98%。

3.善于总结

DBA 这个职业,是非常适合聚焦的一个职业,为什么?因为几十年以来,变化非常小,作为从业者,有足够的时间去学习,去钻研,并且有足够的机会,让你变成这个行业的专家。何谓专家,就是对某一个方向,有足够的经验,有足够的思考,有足够的总结,这三个因素中,总结是最容易的,也是最重要的,因为只有总结了,才可以把思考,经验变为自己的财富:

在相对稳定的变化不大的行业中,总结出来的知识,有利于循环利用,有利于进一步提升。

总结,不是做到心里默念一下,感觉会了就表示总结完了。

总结一定要从心里默念,转换到笔记里面去,或者转化到可发表的文章中去,任何有疑问的地方,要有自己的思考并能解释清楚。

总结,在转化为文字之后,要求再高一些的话,就是可以把相应的内容转换为ppt,在公司或者社会上讲出来,好处不言而喻。

如果做到了这些,恭喜你,你已经正在向通往专家的道路上前进了。

五、DBA 应该做什么事情

我们有幸从事了 DBA 这份职业,上面已经说了,相对变化不大,有足够的时间让你成为专家,那在成为专家的道路上,你应该做哪些事情呢?

这里我想引用一下贝壳找房一直说的一句话:做难而正确的事情。

1.什么是难的事情?

我认为,难的事情,可能是业界难题,也可能是一个具体案例,举例来讲,差不多 8 年前,SQL 语句审核肯定是难的事情,属于业界难题,当时开发了 Inception,就很好的解决了这个问题,直到现在,应该还是 MySQL 运维中的必备工具。业界难题还包括慢查询的评估,如何定义一个慢查询的影响?之前没有人做过,去哪儿网在 2021年做了这个事情。我想还有很多,需要我们不断地去发现,去解决。

2.什么是正确的事情?

提升效率的事情肯定是正确的,节约成本的事情也肯定是正确的。

3.产品化思维

我认为,不管是业余开发者,还是专业开发者,都需要尽量去保持一个产品化思维,如果拥有了,那么在一定程度上可以做到“我好,你好,大家好”。产品化思维一般包括几个点,比如不要让用户产品困惑,能适应更多场景,适度考虑边界情况,耦合度要低等等,可以具体问题具体讨论。

4. 正确的需求

DBA是服务人员,一般都是别人提很多需求,DBA来服务,其实不只是DBA,不管任何行业,需求可以随便提,可以天马行空,可以摊大饼,但实现需求的人,一定要认真评估这些需求是不是合理,是不是正确,是不是应该去实现,这些如果不提前做好认真评估的话,会产生很大的问题,可能的问题包括:

长期以往,自己所实现的服务或者产品,会变为一个垃圾场,八面玲珑,样样不行,最终都会走上“重构”的道路。

是不是可以换一种思路去解决?这考验的是需求实现者的判断力。

接受在普适场景下的定制化,而不能为了解决1%的需求,创造一种新的架构或者服务,还是之前说过的原则,不要因为解决一个小问题,进而创造出来一个更大的问题。

不是所有的需求都需要满足。

5. 十年经验

如果不是一个经验用十年的话,那就恭喜你了。

六、打破规则

规则存在的意义,就是要去打破的,旧的规则被打破了,新的规则才能建立起来,正所谓不破不立。

我们是技术从业者,在工作中也会遇到各种各样的规则,有些规则存在的意义,说不清,道不明,对于这种规则,我们就需要对其打个大大的问号,因为建立规则时,一定是有他当时的时代背景、条件环境的,时过境迁之后,这些条件可能已经不成立了,此时如果不打破规则,那可能出现的局面就是固步自封、因循守旧、墨守成规、循规蹈矩等等之类了,所以规则,有时候必须要打破,只有打破了,才有可能创新,有可能创造。

image.png

如上图漏斗所示,我们技术从业者,可以分为四个大类:

  1. 守城型,这种类型的人是最多的,他们可以站在巨人的肩膀上,过得比较安稳,可以继续保持前人留下来的工作,但让他们去改变的话,非常难,难在两方面,一方面是能力不足,另一方面就是心力不足了。

  2. 被动型,这种类型的人,相对守城者,会稍微少一些,他们的能力是可以的,不过主题词是一个“被”字,工作被动,生活被动,在我们运维行业中,一个集中表现就是,整天“被”各种故障、问题所累,状态也不好。

  3. 参与型,这种类型的人会更少,他们的态度非常积极,很乐观,做事情可以按照预期,甚至超出预期完成,但他们的成就感可能更多地来源于重在参与,很少可以主动去改变现状,去思考面临的问题等等。

  4. 打破型:这种类型的人,非常之少,通常不会按照既定陈规出牌,对过去的传统都会产生疑问,和其它三种有不一样的思考方式,他们的出现,通常会石破天惊,会颠覆某一个规则,甚至某一个行业,拥有这样特质的人,可以参考乔布斯、马斯克这样的人。

上面说了四种人,形成了明显的对比,我想说的是,我们从事 MySQL DBA 的人,不用也不可能和乔布斯、马斯克这种斯字辈儿的人看齐,古人都说了,穷则独善其身,达则兼剂天下,我们可以在自己领域里面,向他们学习,就已经足够了,对现在你所遵守的规则,打几个问号,可能也就足够了,有时候,我们打破了一个规则,或者一堵墙,可能看到的是炫彩斑斓的新世界。

七、 工作模式的转变

DBA 这个职业,一般被认为是属于服务行业,但DBA 的存在感,一般只有在两种情况下比较突出:

  1. 数据库出故障了。
  2. 有人对你有需求。

其它情况下,可能并不能感觉到 DBA 的存在,这样对 DBA 的固有印象,已经持续多年,很难改变,因为这涉及到的是一种工作模式的问题,我在这里可以列一下,是一种什么样子的工作模式:

  1. 各种权限、数据库、SQL 审核等的审批工作以及执行工作。
  2. 各种合作伙伴的咨询问题,需要承担客服的角色。
  3. 各种问题的追踪、调试、找原因,需要面对各种相关人员的询问以及好奇心,查不清楚或者没有结果,是不可以的。
  4. 到处救火,工作时间被安排,没有办法保证。
  5. 这样的状态持续久了,团队情绪低落,士气不高。
  6. 各种重复的,繁复的日常工作需要处理,效率很低。
  7. 等等之类的。

这是一种什么模式呢?很明显,这样的工作状态,非常被动,就像上面说过的,一切都是被安排的状态,这里的主题词,其实就是一个“被”字,过去的十年,已经过去了,以这种状态的工作方式工作了十年,有了足够的教训以及经验,如果能意识到这些问题,这种状态,那我想现在是应该做出改变的时候了,我们应该尽可能的把被动的工作状态,改变为“主动”,包括如下好处:

  1. 团队人员的时间,可以自由支配,而不会被突如其来的事件所干扰。
  2. 是不是可以想办法在故障发生之前,能将故障解决掉,或者破坏掉,故障没了,大家相安无事。
  3. 故障变少之后,上面所说的“数据库出故障了”的存在感就会消失,整体上得到的评价不会因为故障而不断降低。
  4. 相比所有被动处理的局面,变为主动之后,工作量可能会更少,可以做到有条不紊。
  5. 能把被动,变为主动,团队的能力提升肯定是非常大的,这样人员情绪高涨,一举多得。

这样的主动,是一种什么样的概念呢?其实很简单,可能包括如下几个方面:

  1. 做了一件事情,能有效地提前避免将来的问题,即是主动。
  2. 有效地发现潜在的问题,能主动找到当事人并通知到,即是主动。
  3. 能有效地发现数据库的风险,能尽快地解决问题,从而避免问题的发生,即是主动。
  4. 能综合过去各种迹象,从整体来评估一个数据库的健康状况,如果风险相对比较高,做出相应措施,即是主动。
  5. 能通过事件触发,在关键时刻可以留存一些重要信息,在解决问题的时候能用得上,即是主动。
  6. 足够完善的监控系统,日志分析及抓取系统,保存足够的重要数据,即是主动。
  7. 能精确地找到资源浪费,使用不合理,空闲等问题,并且能够处理掉,即是主动。

主动做的事情,可以有很多,列举出来的可能只是常见的一些情况,和自动化是一样的,只要做了,就会有成果,但这种成果不一定能立即体现出来,比如解决了一个高风险的问题,后来确实没出故障,但不解决这个,就一定出故障吗?似乎也不一定,但这是一个思路,这也是我们做为 DBA 的职责,有风险就得解决,那如何检验我们的努力和故障少是正相关的呢?这个很好办,可以长时间观察,做一个环比,通过故障率来衡量,比如去年一年出现的故障,与今年一年相比,是降低了还是上升了,这样去衡量的话,就可以说明问题了,至于可能有些人会问,是不是因为今年运气好没出现问题,而并不是你的这些努力所得到的成果呢?这个是证明不了的,也无需证明,一是因为你属于钻牛角尖,另一方面,你想想,你的目标是什么?是不是要降低故障率,现在达到了,不就可以了吗?或者检验时间还是不够长,如果环比两年,三年来看呢?我想你的运气不可能那么好,以至于你不做这些工作的话,还可以做到故障一年比一年的少。

此时再想想,如果我们能把工作模式成功转变了,那存在感就可以非常强了,这种存在感,再也不是只有故障的时候才想到你,也不是只有需求的时候才想到你,而是你总会以主动的形式出现在他们的面前,比如在你评估之后,一个数据库需要拆分了,或者需要迁移了,或者有很多慢查询需要解决了,或者某个表占了很大空间但没有使用了,等等之类的情况,你都会以预言家的姿态出现在他们面前,而这背后,靠的都是你的辛苦付出,靠得都是技术支撑。

八、我们具体应该做那些事?

讲了这么多,可能都是方法论,可能有些人就想知道,对于我们传统 DBA 来讲,应该做哪些事儿呢?其实我的思路还是一样,要想着转换工作思路,工作模式,将“老旧”的“被动”的 DBA 工作模式抛弃掉,换一种思路,去做一名新时代的 DBA ,我本人从2012年开始做 DBA,到现在 2021 年年底,正好十年,所以过去的十年,可以将其抛之脑后,从2022年开始,迎接新的工作模式,我们可以给自己起一个名字,叫:New DBA。

那我们到底应该做些什么事情呢?我可以举一些例子:

1. 智能报警

报警系统,做为数据库运维来讲,是必不可少的,有问题全靠报警来主动发现,但有一些问题我们是需要解决的:

  1. 阈值低报警太多的话,就会将非常重要的信息,淹没在报警的海洋之中,导致报警失效,因为我们根本不能及时发现;
  2. 阈值高报警太少的话,就有可能在报出来的时候,已经晚了,还是不能及时发现;
  3. 如果不同对象设置不同阈值的话,维护起来又非常不方便,因为报警阈值这种底层配置一般都是本地配置文件,维护困难;
  4. 本地个性化配置阈值的话,迁移之后这些配置也得跟随,也是有问题的;
  5. 不管报警多,还是少,总是有些不管三七二十一都需要必须马上处理的报警,对于这种及时发现还是个问题。
  6. 报警屏蔽,报出来,都会有延迟,经常出现错乱,不知道是延迟导致的还是新出来的报警。

等等如此之类的问题,我们在给 MySQL 上容器之前,这些必须是要先解决掉的。如何解决呢?我们之前发过文章讲过这个事情,这里可以大概说一下我们现在已经做到的以及将来的一些改进:

  1. 我们现在重要的报警可以在一分钟之内直接打电话给相关人员,电话肯定可以接到。
  2. 我们所有报警对象的本地配置,阈值设置的都很低,在智能报警模块去做判断及过滤是不是要报出来。
  3. 我们针对没有报警出来的,会做综合分析,然后统计出来,通过对象维度定期去集中解决某类型的报警。
  4. 我们现在对报警的管理没有任何延迟,因为做在了智能报警模块中。
  5. 我们将来做的一个重要事情是,把报警想象成一个事件,这个事件在报出来的时候,会动态触发新的事件,可能去收集当时数据库或者机器的状态,用来在真正出问题的时候,查问题之用,智能自动化诊断之用。

(相关技术细节请参考往期文章:去哪儿网数据库告警系统演进之路

2. MySQL全日志分析

之前我们也发过文章讲这个事情,我们是通过抓包实现了这样的全日志功能,抓包率可以达到 95% 以上,但我们的目标是要不断达到 100%,为什么呢?因为我们要达到一个目标,就是要可以肯定地说,我们的全日志系统的日志是可信的,而不是模棱两可地说,有可能丢包了没抓到云云之类的。

这里讲一下全日志的好处:

  1. 可以精准掌握资源利用的信息,包括某一个对象是不是还在被使用,哪个是僵尸账号等等,用来回收浪费资源。
  2. 某个 SQL 语句什么时候访问了数据库,每一时刻的访问频率是什么,可以用来定位问题及查故障原因。
  3. 可以与慢查询日志做联动,能得到慢查询日志中不存在的信息。
  4. 用来做安全审计。
  5. 用来打通数据库与应用程序之间的技术栈。
  6. 用来精确地找到某一个表或者库的使用者,更好的推动业务及数据库的配合事务。
  7. 可以做“主动”的工作,做精准通知。
  8. 可以发现异常使用及风险相关的问题。

可以肯定地说,New DBA 可以在这个事情的基础之上,做很多有意义的事情,有价值的工作,所以这项工作是必不可少的。

(相关技术细节请参考往期文章:谁动了我的数据?去哪儿网MySQL嗅探程序

3. 慢查询风险指数

这是我们今年做的一个事情,也是体现我们“主动”运维的重要一环,慢查询是不可避免的,并且是不断变化的,老的被干掉了,新的又不断涌现出来。它是故障原因的常客,因为慢查询的影响足够大,当多个因素包括执行时间、扫描行数、频次都上来之后,它们的执行非常容易相互影响以至于将整个集群或者实例打爆,所以我们必须要有一个评估方案能准确找到真正“慢”的查询,这里的慢表示的是影响程度。

为了应用及数据库健康,降低故障风险,相关人员的慢查询解决意愿其实是有的,只不过由于这些慢查询都在系统里面,他们并不知道哪些是应该优先解决,哪些是需要重点解决的,最终的结果可能就是不解决,等出了问题再解决,这样的话,工作模式又进入到了“被动”模式中,此时我们能做的事情就是,使用这个模型,将风险用量化的数据表示出来,辅助相关人员去找到什么样的慢查询应该优先解决,让解决慢查询的工作变得高效、有的放矢,把有限的时间花在真正需要的工作上面,而不是想当然地盲目地去解决。

如何有效地推进呢?这个问题可以定几个规则,比如定期发邮件给相关应用,给他列出来需要解决的 Top-N 的慢查询,我们需要具体跟踪每一个慢查询的解决进度吗?我想是不需要的,如果是这样的话,那工作量就会增加好多倍,相应的DBA人员也要增加不少,这不是我们想要的,那如何检验慢查询优化的状态?可以从整体上看所有慢查询的P95,P50,P99 等等之类的统计值,如果是在降低,那说明是有辅助效果的(也可能有人对此有疑问,此时想想你的目标是什么?目标不就是要降低P95之类的值吗?目标达成了,那至于是不是因为风险指数的作用,这个和上面说到的故障问题是一样的,是你运气好?还是检验时间不够长?),推动方式可以和相关 TL 沟通好,要根据邮件信息主动推进,并且还可以将数据化的推进情况发给相关 TL 来综合检验,比如发邮件次数最多的 TOP10 的慢查询,也就是一直发但没有解决的。

至于肯定还会存在的一些情况,比如邮件是通知了,但对方就是不主动解决,这样的情况肯定也是不少的,或者说很普遍,那不解决怎么办?对于这种情况,我们可以回头想一下,这个风险指数的意义是什么?不就是辅助相关人员去判断哪些应该优先解决吗?所以如果他不主动去解决,除了被统计发给其 TL 推动之外,我们可以忽略不计,就像你在路上立一个路牌,告诉他“此路不通”,但他就是不信,不听,还是过去了,你需要把他怎么样吗?不需要的。

(相关技术细节请参考往期文章:MySQL慢查询风险指数模型设计

4. 数据库的 HA

在做 MySQL 的容器化之前,先考虑一下,你管理的数据库是不是已经做到了高水准的 HA?可以达到几个9?正常 switch-over 是不是会影响业务?影响时间是多少?重要业务做这个操作的话,是不是需要晚上?还是随时都可以?DBA因为HA的问题是不是心理还会承受很大的压力,需要不停地夜战?

failover 的情况下,是不是还存在丢数据的问题,切换的时候需要多少时间?是不是还在使用 VIP?是不是还在使用单点监控?最近有没有发生误切?

如果没有做好的话,就先把份内之事搞定再说,有闲功夫后再去做 MySQL 的容器化吧。

至于 Redis 集群来讲,HA 方便又是如何,上面的事情是不是可以保证,一个更有挑战的事情是,你的扩容和缩容,是不是做到了对业务无影响?是不是随时可以在无感知的情况下干这些事情?是不是在业务不知道的情况下,发现他们存在资源浪费的问题,即可直接给他们缩容了呢?而在内存报警的时候,是不是可以直接自动给他们扩容节点数呢?

如果没有做到,先想想办法看,然后再做容器化的事情吧,HA 的问题,肯定比容器化能带来的资源隔离,以及任务编排更重要。

5. 自动化操作

你是不是还记得,由于你的一个命令,导致出了一次故障,或者由于某一次疏忽,导致配置错误?

其实通过这一次次的经验教训,可以总结出来的是,很多故障都是人为操作导致的,人的操作是最不可靠的,原因很明显,人工操作有很多不可靠的因素,包括情绪、状态、熟练程度、能力、认知、时间、是不是认真负责等等,这些因素结合起来,如果能够成功实现某一个变更,或者操作一个任务,那简直是运气爆棚,不成功才是正常的。

我们也吃了不少这方面的亏,记得 2019 年一年,人为操作出现的故障就大概有十起左右,历历在目。
这如何防治呢?在防治之前,我们选择先搞明白原因,其实就是操作的随意性,不规范,不标准,想当然,试试看。我们一直强调,在你不能确定这个命令的影响是啥的话,那就别执行,但强调是没用的,能力,状态,熟练程度就摆在那里,强调实在是苍白无力。

在确定的事情面前,人为操作的成功率就是比不上机器去执行的成功率,因为机器执行的话,可以在既定的步骤上面,按部就班地执行,没有其它影响因子,执行过程很规范,很标准,很统一,执行一遍和执行一千遍的结果是一样的,在这样的前提下,那就要尽可能地避免人为操作。

吸取 2019 年的教训之后,在 2020 年,我们实现了可以自定义编排任务的自动化迁移系统,把很多操作任务拆分成原子动作,然后按照提前编排的操作流程,实现最终的迁移目标,最终我们能在两个月内成功地将 100 套 3M 架构的数据库迁移为 PXC 架构,最难的是,我们实现了零故障迁移,这在过去是不可想象的,因为从 3M 到 PXC 的迁移,还需要联系这 100 套数据库的所有业务去改连接方式,那如何在2个月去完成呢?这个战绩是非常惊人的。

同时还可以看出,不仅仅是零故障,效率也是非常值得称赞的,所以我们要做一个 New DBA 的话,一定要自动化,自动化可以解放你的双手,解放你的时间,为你成功地转变工作模式而助力。

九、总结

我们要做一个新时代的 DBA,成为一名 New DBA ,除了上面举例说明的一些重要事情之外,还有很多值得做的事情,而这些正是通往 New DBA 的必经之路,那究竟 New DBA 具有哪些特征呢?我想应该有以下几点:

  1. 高效率:低效率的事情都让机器去干。
  2. 自动化:让机器去做重复低效的事情。
  3. 主动性:具有一定程度上的预言特质,可以把问题提前发现并解决。
  4. 覆盖面广:解决一个问题,就可以解决一类问题,从一个点上升到一个线,进一步上升到面儿。
  5. 自由支配:事情安排不受制于其它因素,任何时间,任何地点,都可以进行。
  6. 轻松愉快:自我成就感高,生活幸福指数高,时刻体现自己的价值。

这是我们的目标,我希望也是 DBA 的共同目标,未来十年,DBA 的路在何方?

如果是上述这样的话,我们已经在路上了。