钟建辉，YY基础运维经理，负责数据库及服务器基础运维工作，在数据库领域有超过10年的工作经验，见证了YY数据库平台化从”0”到”1”的整个历程，目前主要致力于推动YY数据库、服务器平台化建设。
以下为钟建辉老师演讲实录：
我的侧重点主要在运维DBA的角度介绍我们数据库系统。前面周老师就是研发的角度怎么看我们数据库平台系统。
一、YY数据库团队面临问题
我们早期有哪些问题？
- 第一是质量。早期我们经常会有质量事故发生，严重影响了我们一些服务对外的“口碑”
- 效率来说我们对于资源需求的响应远远达不到业务方的要求。
- 另外就是安全的角度来看，我们可能事后救火的东西比较多。
- 另外成本的角度来说我们资源利用率比较低的，就是说成本比较高。
这是我总结的YY平台发展的几个阶段。在座大多数都是DBA，可能的话这三个阶段，我想都有一个经历。
- 首先第一个阶段纯手工运维，可能早期只有三五个实例。大家通过人肉的方式做部署、配置白名单的管理。
- 然后陆陆续续引进到可能我们有类似于上百个实例或者是几百个实例的时候，我们可能会想办法做一些工具和脚本。也就是说我们可能会做部署，我们可能会有部署的工具和脚本。我们做白名单的添加有白名单工具。
- 随着我们数据库规模的一个增加，像YY有将近上万个实例，怎么管理呢？光工具和脚本就达不到目标。就是面向业务整合工具嵌入到流程管理实现自动化管理，数据库流程自动化运维。
- 未来下一个阶段我们要讨论哪个方向发展呢？大家可能也有不同的声音，我理解后续我们可能的方向还是在智能化的阶段。类似我们做智能化的收容、扩容。
二、数据库平台目标
这是我们做平台化的目标第一是效率。效率我们当初定的目标，我们这个平台一定要立足于一站式对外提供服务。
我们业务上限就是实现分钟级的上线，老业务基本实现自动化，变更操作基本实现自动化的操作，质量纬度监控告警实现分钟级，故障可以快速切换，DBA能快速实现故障诊断，提供开发可参考的质量数据供业务参考。
安全的纬度，安全级变更问题可追溯。我们出了问题一定要追溯，数据库操作可审计。成本的纬度就是可度量，会计升降级优化我们的成本。
这是我们平台的一个总览。
分三层，业务服务、基础平台、资源管理。最上面是面向业务的基于下面提出的申请、扩容、数据库的权限管理、下线以及数据库质量等等种种服务。
但是我认为，最基础的一层就是资源这一层，所以我认为资源池的管理非常重要。
下面会讲一下资源池的管理。
三、资源池管理现状及目标
我们目前的现状就是我们有多个IDC，有物流和公有云的机房，支持多种存储，我们有Sas和sata的存储以及ssd的存储，还有Pcie的存储，还有我们多组件、多版本的存储。
支持MySQL、Mongo和Redis的多个版本，还有支持一台机器部署多个实例。这是我们的现状以及目标。如何对业务进行服务呢？
左边的图每个IDC都提供资源池，MySQL、Redis和Mongodb，业务到对应的平台选择数据库的类型和套餐的大小以及配置的信息，在左边资源来对应我们的套餐，总共来说就是四份资源，我们要实现分钟级的交互为什么可以做到呢？
业务只是在的资源池做一个理论和配置的操作，仅此而已。所以这种效率是非常高的。
基础组件首先是高可用这一块。为什么要做高可用？DBA或者是业务方，平常遇到的故障分三种类型的故障。
第一种是实例故障，第二是主机故障，第三是机房故障。但是第三类话说的很响，好像上午有人在群里面讨论，刚好有一个机房的故障，我们碰到很少。
但是遇到这些问题传统方式怎么解决呢？传统方式就是我故障了，DBA就是去手工切换主库，然后业务方更改配置文件指向新的MySQL主库，重新启动应用，让更改配置生效，流量切换到新机房，但是在这种情况下DBA或者是开发抱怨非常多，很苦逼。
基于这些我们每个公司都有高可用Proxy系统架构。就是应用程序通过MySQL协议、统一入口到OSPF/VIP，然后下面是一个代理层，代理层有三个，横向可以扩展的，代理层再到真实的存储。
就是它实时探测我这个MySQL的存活状态然后再切换故障的切换。ZOOKEEPER就是不同的业务对应的真实的IP的Proxy就是GK里面记录的。这个是高可用Proxy特性。
我画了三个示意图，就是北上广三个机房，所有机房的写操作都会路由到IDC1机房，读是每个机房都可以读，但是写操作会帮你路由到IDC节点，不需要关心主节点、从节点在哪里？
但是大家可以看出一个问题，可能对于一些写量非常大业务来讲，它的写是有延迟的，这是一个缺点。
它有几个特性，一个是高可用，第二是负载均衡，第三是读写分离，第四是BigSQL特殊处理。
有一些业务经常会有一些统计性的操作，那种怎么办呢？可以通过其他的方式，不一定通过MySQL去满足，但是必须要有，我们的技术方案什么？我们的技术方案就是我们会自动判断它的大SQL，然后路由到一个节点来规避这个问题。
然后到多租户，多租户对于我们来说太重要了。就是我不太可能来一个业务我们就部署整个一套集群，那样对于我们来说成本太高了。就是对于我们来说，一个新业务，只能在我们的GK里面做一些配置基本上就OK了。
这是我们性能测试报告，整体大家可以看到，毕竟中间加了一层，性能会有一点点损耗，但是整体的话还不是那么明显。基本上还是可以接受的。刚才讲到的是高频的一个方案，那个对于我们大多数业务场景数据量并不是那么大，可能就是三五百的写请求，跨机房写都可以接受。
恰恰这种业务写量几千上万。或者我不知道大家有没有类似的经历，类似有很多公司都在出海，有可能类似于你不可能让人家欧洲的用户的一个数据，类似于写到亚太来。那怎么办？
我们也会有一个相应的配套解决方案提供给业务方。我们内部的项目叫MyShard，MyShard解决了什么？MyShard解决了一个多写的问题。
MyShard的原理是什么？它的原理实际上就是最终一致性。然后实际上最终一致性怎么解决的呢？就是可能的话，在每个表上会加版本号的概念。
以最大版本号覆盖小版本号。大概原理是这样的。但是还有一个优势就是代理分支可以去做分片，可以映射到不同的层面，对于业务来说会透明很多。
这个也会有一点点缺陷就是相应比较重一点。当然这个还没有上限，右边这个会基于5.7019去做了一个改造的版本。
就是利用多源复制的特性，实现多写。大概原理实际上也是说在每个表上可能会加一些版本号的概念。然后我们复制的话就自动给他带一个版本号。
另外一个是同步平台数据库基础组件。DBA经常会遇到这样的问题，有这样的需求，把AB库的某一些表同步到C库甚至更加变态的需求就是我要把AB库某几个字段同步到C库。
或者说我的MySQL要同步到异构的库，类似于我要切到Manager或者是缓冲，类似这样我们会给到一些基础服务给到业务方。
它有几个功能。第一就是特性，同步性能会提升。大家做DBA都知道，我要同步不同的数据库到C库，目前MySQL都会有全面的Redis，会同步一次，效率很难做到。
第二我们会做到缓存更新和清除。还有我们会将Manager同步到RabbitMQ做到应用通知，最后是异构数据同步。
四、数据库质量平台
讲完基础组件来聊聊我们对于质量的看法。
- 第一就是我们的告警。出了问题我们能快速发现，发现了可以快速找到原因，就是快速的诊断，包括实例级别的故障。另外还有一个业务级别的诊断。
- 我们针对一个数据库的事件跟问题能够有效的管理起来，并用于我们的追踪。
- 我们能把我们数据库的质量能够透明的就提供给领导或者是提供给我们的业务方，让大家都知道我的数据库在运维数据库平台上它的质量情况怎么样？
- 我们要定期对数据库的一个故障做复盘。还有做一些故障的演练。这个是非常重要的，有可能我们平常比较稳定，突然来一个故障不至于比较慌
- 我们可以检验我们平常的数据库平台，提供基础服务是否可以达到我们的预期。
这是我们数据库质量分析平台技术架构。上面这一部分的指标类型通过Kafka到我们的这些数据库上面。然后下面是我们截图的一些我们平台上系统的功能，左边这部分就是我们全局看板，全局看板做什么？
就是我要全局知道，我在我们数据库平台上，就是在DBS上跑的情况怎么样？有没有预警？有没有告警？红色可能有告警，黄色区域有预警。
第二张图是我们的一个实例级别的分析跟诊断的一个图片。就是我们能够对MySQL的指标项做一些分析和诊断。
第三张图就是我们一些事件管理，就是我们诊断出故障原因能够把问题修复了。我们要记录一个事件，方面追溯，就是下次出现同样问题的一个处理方式。
五、数据库成本
谈谈我们对于数据库成本自己小的一些看法。我觉得可能数据库MySQL是几十实例或者是上百的实例对于成本的概念不会有那么多，数据库的规模有几千甚至是上万，成本这一块，是一个很大的问题。
做好成本，我觉得有几点，第一点最重要的就是我们能够量化成本。把成本能够量化出来，你首先管控成本要知道成本，右边这一张图我们申请了一个页面，每个申请都会给到业务方相应申请的套餐，未来一年的一个成本。
让他知道，有一些业务方看到类似于说，我可能评估不想那么仔细，随便就选一个套餐。他看到这个成本可能就会去仔细评估它的实际上的需求，这里面非常重要。
另外做了一些成本上的一些报表，能够汇总某一个团队或者是某一个人下面所有的业务，他对应存储的成本。
有三个纬度统计，一个是实例纬度、业务纬度和组织结构的纬度，哪个部门在存储花了多少钱？它的利用率是怎么样的？另外知道我们的成本和利用率了，下一步就是本的优化，自然而然就是这样的。
成本的优化这是一个根本，成本优化有技术手段和非技术手段。下面我列举一个做成本优化的时候，在技术的手段做了哪些事情？
首先我们会有一个类似于一键升降级套餐的功能，这个功能基于什么去产生的呢？业务方评估需求的时候可能往往不会那么精细，可能有时候也没有办法精细。可能原来申请了一个独装的套餐，随着业务的发展远远没有达到预期，这个时候怎么办？我们要给他降套餐。
有可能他申请了很小的套餐，业务超预期发展要给他升级套餐。基于这个我们做了一些技术手段的保障，帮他一键升降级套餐。
原理很简单，首先我们原来是一个类似于大套餐掌握小套餐，我们会新建一个小套餐，然后的话我们会把小套餐的一个DB指向原来的指向同步，做到上面是老的，下面是新的，做到数据一致，这个是前提。
后面的话，我们会再把它的主角色改为新的主，然后我们把所有的DB都会配置为一个带下线的状态，这个时候我们的老的DV，都会去到新的DV。老的做隔离下线操作就完成了套餐降级的功能，实际上升级是一样的事情。
六、数据库安全
我认为安全这几部分非常重要。
- 第一是基础安全，这一块做好这一部分事半功倍。就这一块是一个基础的保障，网络上或者是OS基础的安全。
- 然后就是DV，DV就是存储上的安全。类似于一定要做好跨区域的容灾，或者说备份上跨区域的容灾，这方面非常重要。
实际上很重要的一块就是内容上的安全，这里面非常重要。就是我们怎么保障？我可能有跨区域的容灾了，我怎么保证它的数据是一致的？这里面非常重要的，虽然有一个主库和从库，可能切过来一边是100多个数据，一边200多数据，数据内容的安全一定要保证的。
- 操作层面的安全也是非常重要的，减少误操作，尽量规避误操作。另外的话，出了安全问题，类似于说数据的一些泄露或者是种种的安全问题，能够审计和追溯，这一点也是尤为重要。
首先讲一下数据存储的安全。就是DBMS很大的一部分工作就是备份，这是我们备份的一个总的架构图，就是一个简图，我们在本地叫一级备份，就是我们在跨区域的话，会有两个备份中心，我们从一级备份会传到二级备份。
然后右边是我们的一个备份的总览图，我们可以在系统查出备份的某一个业务备份是否成功还是失败？能够统计到我们有多少个业务是成功的？有多少个业务是失败的？它目前的备份状态是怎么样的？都可以查到。
然后的话这个就涉及到数据内容上的安全。例举了一个数据一致性。刚才我也举了一个曾经发生的事情，这个非常重要。目前我们内容上的一致性怎么保证的呢？我们定期会去通过PP去做一些对于原库和目标做对比。
然后通过BD做一些自动化修复，然后第二天可以看到我们对比的报告。我们的数据有没有不一致？不一致是哪些地方？我们修复的成功与否？这部分是我们数据库操作的安全，就是我列举了一个我们的数据库的一个下线的操作。
我不知道大家有没有一些体会。就是我们很早期也会发生我们可能会有一些已经有跑业务的残留的东西被我们下线掉了比如说用户提单根据重要级别去进行DBA审批，然后DBA执行，类似于下线第一步需要做隔离。我防止我误下线了？怎么样可以快速解除隔离，尽快恢复服务。我们怎么做的呢？
技术上比较手段，我们就是通过某一个端口的一个MySQL，我要隔离，我可能会把所有的端口把它禁掉。另外的话就是隔离完成了我们可能就会发起一个下线，下线其实就是后台做的东西也挺多的，我类似于要关掉实例，关掉实例我可能要做备份。可能要查到实例的节点。整个流程DBA做的事情挺多，但是通过流程化管控的方式方法去走。做完就可能是一个通知的流程。
这是我们的一个SQL发布系统。为什么讲这个呢？我想就平常大家DBA日常的工作，这一块也会非常多。就是说，故障一定是有故障几率的，我操作多几率一定会大。在这一块我们也做了一些风险上的控制。
比如说我们可能在类似于说我要DROP table，不会直接操作这个table，我肯定有一个加Db，Drop table语句会转换一个RENAME的语句。TRUNCATE table语句会转换成RENAME和CREATE table的语句。
大家都是DBA，都是没有特别的，可能就是用DP的方式执行的。整个步骤第一就是需求申请，整个平台会基于这些步骤会去进行审核，另外可能就会分不同的级别。有一些可能不需要审批，类似非重要这些东西我们不需要审批，直接就SQL执行了。
未来和理想
我总结了四块。效率层面的东西，我刚才总结了我们三个发展阶段，我觉得未来的话，我们会朝着更加智能化的方向去发展，类似于说我们的一些监控，监控我不知道随着量越来越大，大家有没有发现，我们可能DBA收到的现象级的告警会非常多，但是它只是一个表象，类似于流量高，就是我们要通过各种各样的现象去分析它的原因或者是对应的影响。
这是我们未来要考虑的东西。我们做扩容，我们做扩容实际上刚才也讲过，我们能够一键扩容，我们是否未来可以就朝着自动化扩容，就是智能化扩容去发展？随着我们数据越来越多，我们的系统之间的关联性越来越建立这种关联关系，我觉得这个是可期的。
质量这一块，我们提供更加可靠的，就是更加透明的SLA的服务保障给到业务方。另外我们的安全：加强SQL方面的审计，这一块实际上我们做的不太好，等一下会有圆桌的讨论，希望可以更多讨论这一块。
成本这一块，未来我们会优化隔离方案，类似于增加目前的机器使用率，降低整体的运维成本。
注：本文经高效运维社区 2018 数据库专场沙龙活动演讲整理而成。