周耀荣: 珍爱网云数据库使用实战分享

周耀荣，珍爱网DBA负责人。具有多年mysql/oracle使用经验，曾任职于腾讯、金蝶、华为，现任职珍爱网，负责DB运维。

周耀荣：感谢大家坚持到现在，我先介绍一下我自己，我叫周耀荣，曾经任职于腾讯、金蝶、华为，现在在珍爱网，也算是数据库DB运维的老兵。

怎么从客户角度看云产品？我们公司用过很多云产品，有幸被腾讯邀请过来做分享，下午的老师分享了干货的分析，下面我从客户的角度看这个产品是怎么样的。

使用云数据库后DBA会失业吗？在座的有没有做数据库的？看来失业的压力不大。想当年我第一次接触云数据库的时候，我那个时候心里就在担心了，这个东西做的那么好，我以后能干什么呢？我是不是就要失业了，所以我是持拒绝态度。所以我先很严谨的分析一下使用云数据库后DBA会不会失业？

这个图是自动驾驶，目前很火的自动驾驶话题，自从特斯拉把自动驾驶带到国内，这个词就很火热。我们看一下自动驾驶与司机的关系，我们先看一下简单的场景，我理解自动驾驶其实比数据库管理碰到的东西场景简单一点，只是关心路上有没有人、物体、速度怎样。在这种情况下能不能做到自动化的过程，所以自动驾驶用到AI、图像识别技术判断路上的东西是人、倒影还是汽车，它的速度跟我速度的关系，我会不会追上它？理论上解决了这两个问题之后，这种驾驶其实就是可以把司机干掉了。这是我们看的这个过程，类比一下，干掉这个司机，但是我们现在看到的情形是特斯拉也出了很多事故，大部分的人使用汽车的时候，你敢就让他自己开，然后闭上眼睛等着吗？在自动驾驶简单情形下，其实自动化的东西想代替司机还是很困难的。

下面我们进入严肃讨论的话题就是云数据库和DBA的关系，啥时候能代替DBA呢？就是智能运维，当智能运维现在也是很火的概念，如果智能运维真正代表人思考的时候，DBA这个职业就消失了，但根据我在DBA行业里面多年的经验，DBA里面碰到的情景和各种问题非常复杂，而且目前人工智能大部分是机器学习，像人一样思考、解决问题可能还要有一段时间，估计在我们这些人退休之后也不一定实现，我们可以安心的多做几年DBA。

下面我来讲一下云给我们提供什么服务？从我们使用角度来看，在讲云数据库提供什么服务的时候，我先说一下这么多年在DBA运维的一些小故事还有案例。这里面可能是结果比较好的故事，还有一些结果是带有淡淡忧伤的故事，给大家讲一下。讲故事可能凸现不了我个人能力，所以在讲故事之前，先讲点带有小技术的案例。这个是我们之前实施MHA的案例，因为使用MySQL的人都知道，MySQL最开始最古老的时候，就是高可用架构，就是主从，当年我刚进入DBA行业的时候，那时候就讲这些东西，就没有那么多自动化的东西，就讲高可用架构是什么，一主两从这些东西。再后来，大家思考怎么让你的高可用架构能够做到自动化，这个时候就出了一种下午在其他老师讲的时候也讲到的高可用架构。但是MHA出来是第一个架构，而且是第三方的。上面有一个S端，下面有一个每个数据库会装个NODE，去观察每个节点上的NODE，获取数据库信息，比如说有某个库挂了，就需要切换。最开始安装mha server，MHA工具是很古老的语言，在装的时候有一堆的perl依赖组建。

第二个我们要做的就是一些我们需要配置MHA，让它自动切换。这个时候原始MHA不太支持多套集群，每套集群有自己的工作目录，然后日志是有工作目录的。第二个是当时我们想说当切换的时候，因为切换完故障节点的恢复和加入是需要DBA干预的，这个时候我们把它记下来，最后还需要启动N个观察者的脚本，最后我们把这套MHA的架构起完了。

然后我们要做监控，有没有发生切换，总不能说切换完了我们还不知道。其次复制方式对不对，包括从库开启了没有，这些东西都是需要我们考虑的问题，各种步骤都需要投入我们很多精力，最终对接监控。

我们监控的东西，你要对接Zabbix，获取的结果很简单，集群到底有没有问题，可能告诉DBA需要人工介入分析，到底哪里出了问题，怎么恢复。我们当时做了管理平台，展示所有细节，就是说主库到底有没有切换，有没有跨机房切换还是本机房内切换复制方向对不对，包括提到的所有东西，只读开启了没有，我们考虑不同切换状态下，本机房内切换复制方向对不对，展示了状态是怎样的，我们觉得这种展示没有平台很难做，所以我们当时做了管理平台。这是我们但年实施MHA的实施案例，讲这个案例并不是说我们的技术有多么厉害，只是给大家一个印象，DBA要做什么事情，DBA需要考虑的东西很多，如果做不到这么多细节，可能你的管理就失败了，可能出问题了你都不知道。

下面我们再来讲故事，第一个故事讲完大家可以猜一下是比较好的结果的故事还是淡淡忧伤的故事。这是我们真实发生的一件事情，就是在我们使用的过程中出现的一个事情就是存储过饱，我们得制定好切换计划，这是我们的行动，我们做的行动要做很多东西，一个要制定机器迁移方案，我们不想在换出过程中对业务影响过大，我们当时制定机器的迁移方案，这样做之后时间窗很短，但是我们要协调时间窗，要有点时间，要做数据库切换的东西这两个东西基础打好之后，最后要实施做苦力，分批迁移，然后让业务做验证。最后的开销是停机时间沟通，我们当时有很多套系统，每套系统都要沟通就非常痛苦，实时就是N个通宵的不眠之夜。做完这个工作我们有体会，感觉我们是数据库的搬运工。

大家觉得第一个故事的结果好还是不好？（不好）错了，这是比较好的结果，这体现了公司管理能力很强，当公司存储过饱的情况你要提前知道，其实已经体现了很高的水平了，如果管理不规范的公司，可能机器用了多少年，啥时候出故障，他可能都不是很清楚。

第二个小故事，这个故事不是真实的，是我虚拟出来的，是今天小明哼着小曲上班，来了一个“故障”，故障发生之后急急忙忙分析问题。分析问题的原因就是磁盘出问题，这是有点北上的故事，可能Raid机制合巡查做的不到位，最后导致数据丢失，最后尝试用备份集恢复，然后发现前几天备份任务失败无告警。小明这个周末可能就过不好了，可能要恢复几天数据了，然后找业务补数据。

我讲这几个案例和故事，当一个公司的运维设施做不好的情况下，自己管理所有东西，难度很高，这就是引入了一个问题就是云数据库提供什么服务？我觉得云数据库类似一个很好的运维公司给我们提供了基础服务，在很多大公司，自己的机房建设能力是够的，但对于小公司，如果你基础能力不好的情况下，就是实例创建。今天刚上班，来了一个新项目，过几天装一套数据库出来，云数据库最简单了，直接提供实例创建就可以了。

高可用单元结构，MHA复杂的过程其实云上也是复杂的，只是说云是做产品的，帮我们做切换，我们直接用产品的话，这个就解决了。第二是备份，机制还是有一些机制检查的，可能不会备份我们都不知道。后面我讲的时候，我还是不相信它的，我们看一下我们还要做什么。第三就是监控，云上提供监控，这些东西我们不需要实施了。再下一个程序是做容灾，当一个公司运营规模很小的时候，想做容灾难度很大，因为还需要一个异地的机房，这时候在云上做容灾成本就会低了很多。

其实总结一下，云上提供的服务就是重复性高工作标准化和自动化。

高可用单元，下午也有人讲，我就不重复了，就是当我们实施的时候也要考虑这些东西，跟之前也有点类似，我们进入下一个话题，需要DBA考虑的问题是什么？这个问题不回答好，那我们就真的失业了，所以我的问题要回答好。云提供的服务就是基础运维，据小道消息，腾讯云同事跟我交流说他们想提供DBA的工作的，所以他们后续可能会提供CloudDBA的锁分析和慢SQL分析，需要我们DBA的思考是什么呢？第一个是业务整体运维的角度，就是说当你买云服务的时候有什么差别，老板对你的要求就是公司的业务能不能稳定运维，作为DBA角度说，这个业务相关的DBA的状态是什么样子的，后续我们会做很多从业务角度看这些DBA状态的东西，其实我们是回答了那个问题，当云服务商是一个基础了，我们自己要做什么事情，让我们管理好业务相关的DBA，这是业务整体运维角度去看。

第二能做的事情就是异常的处理，比如说CPU高，腾讯云会告诉你要去分析了，还有优化。当一个公司的业务性上不去，可能需要系统优化的时候，这个时候就需要很人工，就看你能不能跟他一起优化好了。其实回到我们之前说的问题，人工智能的东西目前还没有深度学习发展的那么全面，都是一些规则。

第三是性能容量管理，可能关注的是某个DBA，我们要整个业务视角，可能我们也会做同一个事务出来。故障的透视能力，作为DBA管理员很重要的能力，当你发生故障的时候你要知道哪个节点发生问题。比如说你有很多节点，你要知道哪个节点发生问题，再追进去，到底是哪个SQL导致的问题，起码要把SQL抓出来，MySQL没有具体分析工具SQL出现故障可能你能做的事情很少，这种工具明显支撑很落后，这个能力是需要我们思考和解决的。其实我们也思考了这些东西，后续我们会做怎么分析，把这个问题定义出来。

说了架构规划，比如说你的高可用架构，你要做怎么拆分，你的表怎么做拆分，容灾怎么考虑，这都需要公司DBA需要考虑的问题。

还有就是SQL上线审核，你要做好，就是说当你公司业务做变更的时候，怎么把控上线的风险会不会对你的数据造成误删除，这些都是需要DBA考虑的，这些东西目前像SQL审核等云平台不会帮你做，肯定DBA要自己做。

这个我也总结一下，就是规划类的、优化类、主动管理类，目前来看还是需要DBA解决的，这是在未来还是持续比较长一段时间的。

下面简单介绍一下我们在做的东西，我们做了第一个是SQL上线审核平台。SQL审核为什么要做呢，我们看INCEPTION看，当开发人员提交SQL，不管公司有没有留存审核，审核过程基本是虚的，通过INCEPTION到线上库试一下，看一下能不能执行成功，包括影响行数。

INCEPTION审核之后帮你执行和备份，取回日志之后把你更改的进行存储，发现问题之后可以把SQL提交回去。我们做的时候有两个选择，一个是Archer和Yearning，我们最后选择的是Archer，对我们来说也不需要，对你们来说也可能需要，这两个都不错，我们选择了Archer，我们客观采用一些工具帮助开发人员做一些优化，提供优化的建议，提供不了的时候，才需要DBA工。

最后还有一个功能就是慢日志的统一展示，我们把慢日志的东西推给开发人员，其实我们管数据库的思路一定要做到自助化。第二我们要做的管理平台，其实就是实现了刚才我列举的那些DBA存在价值的服务了。

目前我们做的东西像DB基本信息、容灾实施情况。我们的数据库上来之后是不是有容灾，当几个DBA或者很少的人管理很多库的时候，很多库之后就产生容灾，备份的配置、状态，我们目前用的什么备份方式，还有性能监控，当我们发现业务有问题的话，我们需要快速定位。

计划做的同步信息、增长趋势、智能跟踪，CPU异常智能跟踪，解决了故障透视的问题，我们想借助一些工具分析，当时跑了一些SQL，得出结论，到底是这个SQL出现什么问题，然后做优化。这块我考虑了一下，还是想利用一些监控联动加上一些工具分析我们当时的信息，帮助我们做结论出来，这是我们目前正在做的，可能这个计划做的东西会越来越长。

实现我们这些功能其实需要的相关技术，比如Bootstrap、Djangg、Javascript为、Gunicom、MySQL等，可以帮助我们DBA把性能做的更好。

下面就是我们的展示效果，我们上线之后还是每天的量还是蛮多的，如果都是人工执行的话，开销比较大。我们新上线一套系统，这里是没有容灾的，会提醒我们去做容灾。这是我们做了监控的汇总图，就是知道我们当前的整体的情况是怎么样子的。这是我们做的备份，像腾讯云做的备份都比我们好很多。但是我们能发现异常，我们这个问题反馈之后，腾讯云也会做优化的，我们从DBA的角度，我们也会做很多事情，比如备份细节，什么时候开始什么时候结束。这个是我们目前从DBA角度看，我们所做的东西。谢谢，我分享的东西就这么多了。

Q&A：

主持人：大家有没有提问的？

听众：我想了解一下现在有没有金融行业也放在云数据库里面？远程容灾，本地机房就是本地数据库，远程容灾能直接容灾到你们云上的吗？

周耀荣：比如我们机房在一个地方，我们容灾选择在另外一个地方，利用容灾服务，我们做容灾的时候有两种考虑，第一种是我们自己搭建服务。第二种是腾讯云的，最后我们考虑了还是使用了腾讯云的容灾来做，当一个地区出现地震或者不可抗力灾难的时候，我们的数据还能回来一份。

听众：你好，我刚刚听你讲的时候有一个过程，之前高可用之前几位老师讲过了，如果高可用不用云产品的话，可以做本地的高可用吗？

周耀荣：你说的keepalive你要双向考虑，这个东西蛮复杂的，而且也是相对来说是比较古老的方案。其实应该是跟MHA同时代的产品，现在其实下一代的高可用架构的，在这个基础上，我比较建议一点就是MySQL的MGR的复制集群，技术比其他的高可用技术更先进，比如PXC是有点类似全新做了一层高可用，群组复制还是利用了原来的复制技术，会更优雅，我原来在考虑高可用单元时，考虑的一种是云提供的高可用单元，另一种就是MGR。

听众：管理平台是云产品还是你们自己研发的？

周耀荣：是我们自己做的，是从DBA整体角度去思考如果管理好数据库。

听众： 腾讯云数据库产品有没有类似的，但是可能比你们功少一点或者多一点，他们的产品和你们的界面是不是有相同的功能？

周耀荣： 你购买服务是实例购买的，会根据实例情况给你预测的，DBA从更高层次考虑这个问题。