随着业务系统数量快速增长、数据规模越来越大、交易复杂度不断提升，数据库数量的增多，对于管理和人力成本也提出了巨大的挑战。于是更多企业选择和开展了分布式数据库的探索和应用。与此同时，关于分布式数据库的运维工作也面临着新的需求。
本期对话ACE，邀请了 OceanBase 技术专家鲍磊，Oracle ACE 皇甫晓飞一起探讨“如何做好分布式数据库的运维管理？”
以下为对话实录，欢迎大家阅读、收藏！
Q1 分布式数据库运维管理面临哪些新挑战？
皇甫晓飞：
结合我的工作实际，谈谈我个人的观点。
第一，首先用户关注的还是数据安全，不管什么数据库，数据安全是最关键的。和传统的Oracle数据一样，安全的关键目标仍然是敏感数据看不见，核心数据拿不走，运维操作能够审计。对访问数据库的路径，不管是应用、客户端，只要能访问数据库的，以及数据库的特定操作，特别是一些特权操作，要能够进行审计，保证安全。当然这话题很广，肯定还要涉及到一些用户管理，安全加固，这是用户比较关心的。
第二，是可用性。其实高可用性，当数据库出现故障的时候，能够快速恢复，满足行业和监管的要求。对客户来说，减少宕机的风险，减少对业务的影响。对于运维人员，对于DBA来说，操作简单，不能太复杂，就是他看下文档，或者是做两把实验就能够进行操作，这种高可用。以及刚才鲍老师也提到了切换，其实切换和恢复对于DBA来说要容易上手。
第三，就是数据库性能。如何能够快速定位和分析数据库，在生产环境遇到的性能问题。比如说在上线前，我们有一套方法能检查、能预估出这个系统会有哪样的性能问题。比如说从开发前置，对一些执行开发规范，完善开发规范，DBA把更多的精力投入到开发测试环境、开发测试环节。要有一套完整的故障处理流程和方法论，运维人员通过我们的知识库、用户手册以及借助我们的数据库运维工具，能够快速分析处理问题，就是要高效。性能问题，一个是被动的，出现问题的时候处理问题，一种是提前预估，第三个是数据库性能。
第四，就是能够对性能以及容量进行评估，我这个数据库还能够支撑多少业务，随着业务发展，保在保证业务连续性的的情况下，当我业务量，以及业务类型发生变化，比如说银行的交易发生了变化，或者是高峰期搞一些活动，数据库能不能顶得住压力？这个就是我们要对客户提供的依据，对容量有一个评估。我建议也是应该是要工具，人工加专家的经验是最好的。
第五，就是如何更好的满足，特别是金融行业，能够满足监管的要求和业务的变化。金融行业根据自身的特点，每年或者甚至每个季度都有一些业务的变化，而且要符合监管机构的要求，应对这个复杂多变的金融场景。
再一个，因为我们每一个客户那边，他对于现有的运维分工、运维制度都是基于原来传统数据库制定的运维规范和制度。在这个运维规范和制度中，我们原有的运维参与者，像DBA、架构师、开发，也涉及我们基础相间的中间键、服务器，以及存储、网络主机这些人员，随着分布式数据库的广泛使用，原有的分工在有些客户或者有些行业，可能要进行调整。我刚才也说了，因为分布式数据库可能就需要DBA将更多的精力投入到开发测试环节，开发测试环节投入的精力多了，上了生产之后，性能问题和故障率应该会明显下降。
Q2 关于金融行业，OceanBase 针对集群设计方面，在运维管理上有什么独特的方法？
鲍磊：
在金融行业，随着国内业界分布式技术持续升温，我们这边越来越多的金融客户将业务系统迁移到 OceanBase 的分布式多租户的数据库上，同时利用原生的分布式的特性做一些技术转型，促进它自己本身业务的持续创新。转型同时，分布式数据库产品的运维对传统数据库DBA有着更高要求和机遇。
实际运维中， 集群升级、租户扩容降配，容灾搭建、容灾切换等工作是通过OCP产品白屏交互方式来进行运维管理的，数据库管理人员对这些运维工作上手较传统数据库来说比较容易的，另外在排查问题方便，比如数据库备份恢复发生了错误，在多节点分布式数据库架构下OCP（OceanBase 运维管理工具 OceanBase Control Platform）会智能的给出对应报错日志所在节点及traceid，引导DBA去基于traceid排查找到这个问题触发的上下文逻辑，进而找到问题根因。同时多节点数据库运行日志可以进行一键收集和基础分析。
Q3 相较于传统集中式架构，分布式架构的运维有哪些差异？
皇甫晓飞：
第一个就是基础环境，我认为有差异。因为我们传统的集中式架构，像Oracle rock特别是12C以后，包括19C，它承载能力强，主要依靠的是硬件的能力，就是技术环境的能力。虽然现在好多用户在进行小机的下移，采用X86架构，也使用一些国产一体机。但即使是X86，它对硬件要求也蛮高的。分布式架构，我认为它是普通的PC环境的硬件为基础，利用分布式的一些一致性协议，能够保证数据的可靠性。因为它的架构差异，所以技术环境应该是有差异，能够节约成本，能够把用户的基础环境有效的利用起来，一是省钱，二是原有的一些服务器能够高效的利用起来。
第二个是扩容的区别。像在小机下，好多用户为什么从传统Oracle数据库迁移到别的数据库或者是进行升级、换平台。在一些小机下，不管是服务器的内存CPU，或者是存储，当数据量达到一定程度，业务达到一定峰值的时候，它是没法扩的。扩节点的话，有些能扩的，也是有限的。扩完之后，多个节点对一套Oracle来说，访问的仍然是同一份数据，多数架构是对节点有上限的数量要求。分布式数据库，我认为它对计算和存储节点的数量没有过多的限制，相对来说更灵活一些，当业务不足，进行扩容的时候，我感觉分布式数据库比较灵活。
第三个就是运维成本。对于用户来说，特别是一些决策者，领导肯定要考虑成本。我们基础环境的软件，以及软件服务费，几项综合对比，分布式数据库更经济。
Q4 OceanBase 有一套运维管理工具，OCP，能否谈谈这个工具设计的初衷和解决的问题？
鲍磊：
OCP（OceanBase 运维管理工具 OceanBase Control Platform）提供对 OceanBase 集群的图形化管理能力，包括数据库组件及相关资源（主机、网络和软件包等）的全生命周期管理、故障恢复、性能诊断、监控告警等。旨在协助客户更加高效地管理 OceanBase 集群，降低企业的 IT 运维成本和用户的学习成本。
通过OCP解决了 OceanBase 分布式数据库管理员日常繁琐的运维工作，通过可视化的交互界面来进行集群运维管理，如租户资源创建发布、扩缩容、集群observer 部署扩容，容灾搭建等场景。同时提供多集群异地灾备部署，通过运维跨多集群OCP集群的功能来实现OceanBase主备集群进行创建、删除、升级、日常切换、容灾切换工作。并提供了多维度分布式数据库特有指标监控告警、与传统数据库类似的SQL诊断、集群巡检等。
实际中，机房搬迁，可以通过OCP 白屏界面操作可轻松实现在线搬迁（加zone，减zone），弹性大促执行locality变更（如3F->5F），地域级故障降级容灾(如 5F->3F) 。
OCP本身也开放了一些相应的运维接口，这些接口可以给相应的客户做一些定制化的编排。OCP主要是把我们日常运维的在传统数据库上也遇到的问题，做一些流程化的交互式的管理。其实传统数据库DBA转型到分布式数据库DBA的话，实际上成本是比较低的。
Q5 您觉得企业在使用分布式数据库时，运维团队应具备怎样的能力？
皇甫晓飞：
我认为企业使用分布式数据库，在使用之前，运维团队要学习和掌握分布式数据库的原理、架构以及特点，作为一个理论支撑。这个学习不光是学理论，一些最佳实践、成功案例都要多学习。
第二，要熟练日常的一些运维操作，比如巡检、备份、性能优化、故障处理、切换，容灾环境的管理，包括数据同步。
第三，应该要掌握分布式数据库相关的运维工具，工具很重要，借助工具，提升运维能力和效率。
Q6 面对稳定性风险，多节点数据一致性问题，在运维管理工作方面应注意哪些方面？
鲍磊：
金融行业对数据一致性要求非常高，而又受监管要求对部署一般会涉及到同城异地机房的交付，这对于分布式数据库而言会是更高的挑战。OceanBase 作为分布式 paxos 协议工程实践代表， 在多节点一致性方面，挑战较集中式数据库较多。如 ：
1) 通过Multi-Paxos实现系统的高可用和数据的高可靠。需要支持跨地域部署，但多个副本（异地机房）之间的网络时延达可能到几十甚至数百ms；
2) 分区作为数据同步单位，单机支持百万分区情况下，需要支持日志高效写入和读取。
对于上述挑战，内核做了很多优化保障产品在多节点下稳定性：
- 成员管理
成员管理支持的功能如下：
add_member/remove_member， 支持加减成员。负载均衡发起的迁移、宕机引起的补副本操作，均需要通过上述功能修改Partition的成员组；
modify_quorum，修改paxos group的法定副本数。弹性大促执行locality变更（如3F->5F），地域级故障降级容灾(5F->3F)，均需要通过上述功能修改paxos group的法定副本数。
上述功能均提供了batch接口，允许将多个Partition的操作批量执行，极大的提升了相关操作的执行效率。
- 单机分布式一阶段
由于 OceanBase 以Patition为单位组织paxos group，每个Partition是独立的日志流，并允许以Partition为单位进行迁移复制。在标准的事务实现中，即使多个Partition的Leader在相同的Server，涉及多个Partition的事务仍需要执行两阶段提交，每个Partition至少需要写prepare/commit/clear三条日志，这是之前 1.x的实现。在OB 2.x 以上版本中，对于单机分布式事务，通过提前分配参与者log_id和prepare version并保存在日志之中，将事务状态信息由Trans Service维护下压到日志服务之中。事务提交时，通过batch_submit_log功能，将多个参与者日志的提交性能优化成和单分区事务提交性能一致。在故障恢复回放时，通过基于log_id查询事务提交状态的服务，避免在内存中维护事务上下文。上述功能相结合，极大的优化了单机多分区分布式事务的执行性能。
- 减少日志提交次数
1）将多个分区进行聚合，形成Partition Group，将分布式事务一阶段优化后每个分区一条日志优化成一个事务一条日志；
2）将一个Partition Group内部多个事务提交的日志进行聚合，减少PG内部所需要的日志数；
- 节点故障自愈
OceanBase 在线上实际运行过程中难免遇到各类故障（磁盘、网络故障，机器异常宕机等）。作为高可用的分布式数据库系统，必须能够在各种故障场景应对自如，保证RPO = 0，RTO尽量短。
1）非Leader 少数派replica宕机：由于paxos要求日志只需要同步到majority即可，对可用性无影响，RPO=0，RTO=0；
2）Leader 少数派 replica宕机：通过无主选举+paxos reconfirm，保证在lease过期后很短的时间内即选出新的Leader提供服务，且数据无任何丢失，RPO = 0， RTO < 30s;
3）非Leader 少数派replica网络分区，同样RPO=0,RTO=0;
4）Leader 少数派replica网络分区, RPO = 0， RTO < 30s;
5）多数派宕机，此时服务中断。我们需要重启宕机副本。2.x上OceanBase会提供极速重启特性，保证在此场景下可以在5分钟内恢复，RPO = 0， RTO < 5 minutes;
6）单机事务故障恢复实现同steal& no-force的落盘策略，在事务宕机恢复过程中，通过redo日志进行重做恢复已提交未落盘事务，通过旧版本来回滚已落盘的未提交事务修改；
7）对于分布式事务在参与者高可用情况下，协助者无状态即不写日志，协调者宕机恢复情况下通过询问参与者来恢复自己状态，进而恢复出整个分布式事务状态。
- 快速选举
通过虚拟组的方式实现有主连任，在正常工作场景下，单机十万分区选举实例消耗的CPU小于1个核。（虚拟组是一定数量具备特定相同特征分区的集合，同一个虚拟组内的分区paxos成员列表、leader、tenant相同，有主连任以虚拟组为单位执行，不必每个分区都发送连任消息，这样可以有效地减少rpc消息总量，达到降低CPU开销的目标。）
- 正确性保障
OceanBase 的日志服务实现了一套标准的Multi-Paxos协议，保证在少数派永久性故障的前提下，数据不丢失、服务持续可用、自动主备切换。同时由于Paxos在工程实践中采用日志的乱序回放，保证事务之间无依赖，同时对异地部署非常友好的，避免单个网络链路故障影响后续所有事务的response time 。另外为了保障multi-paxos数据正确性和一致性，OceanBase 日志服务模块提供了多层的Checksum校验。例如：
1）单条日志的checksum校验；
2）Group Commit后Block整体的checksum校验；
3）RPC packet的checksum校验；
4）log_id的累积checksum校验，每一条日志都校验当前Partition之前所有日志的正确性。
上述所说是从内核产品角度来保障多节点多机房一致性和正确性，由于跨地域网络的不确定性，架构方面我们也尽量推荐保障多数派的节点在同城部署，在网络带宽不足异地会去考虑放follower副本通过这个follower副本给下游的备库同步数据， 在金融领域，比较多的架构像同城三机房、两地三中心+备库、二地4中心五副本+备库等。
从运维DBA角度来说，数据库管理员关心的在分布式数据库场景下的一些指标是否正常，异常指标推送到短信平台，OCP会采集集群运行一些特有指标，比如clog同步情况、节点间rpc延时情况、时钟同步情况、leader副本健康情况、备集群同步位点、版本合并、异常路由、observer机器性能和健康指标的情况等。在几百个节点的分布式数据库集群的运维管理上，我们需要做好常见故障的自愈管理，容量水位管理，应急预案管理等。
Q7 如何更有效的运维大规模数据库集群？
皇甫晓飞：
第一，要有合理的运维分工。特别是金融行业，我们运维涉及多个部门，多个厂商，多个条件的人员。我们要结合本单位的实际情况，有一个合理的运维分工。可能在有些单位，就刚刚鲍老师讲的这些数据库、中间件以及主机，它可能在一个初始或者是一个人来管或者是一个组来管，有些客户，他粒度分得非常细，可能数据库都分好几个组，中间件也分好几个组，按不同的产品类型分不同的组。操作系统也按不同的操作系统类型，分不同的组和厂商。这样不同部门不同厂商，要一起来干活，达到很好的效果，所以分工要明确，要一个合理的分工。如果都是一个部门，一个组的，大家协作起来也很方便。但如果原有的分工，对于分布式数据库的运维有影响，我们也应该适时的进行调整。
第二，应该还有一个完善的运维制度。无论哪种数据库，我们运维都应该有相应的制度去指导我们的运维工作。主要是规范和流程，这个规范包括运维规范，开发规范，以及我们日常的一些常规的流程，这个金融行业应该做的都非常细，也非常好。
第三，应该要有专业的运维团队。团队人员的技能和综合素质都应该非常专业，要具备驾驭这种分布式数据库的能力。
Q8 从数据库内核、中间件、部署架构到业务，您觉得如何保障和提升整体的数据监控能力？
鲍磊：
IOE架构是金融行业银行核心标配，银行的各个系统（核心和渠道及业务）要实现互通，他们是通过企业服务总线ESB来进行业务之间连接、数据交换、格式转换、消息路由等。即SOA 架构。在互联网金融浪潮的冲击下、在云计算/云原生等新兴技术普及趋势下，传统金融行业客户也慢慢往云原生、分布式的架构下进行转变，新的架构下的运维人员也面临技术栈迭代更新，运维的思路也需要发生相应的转变。
同样当前云原生环境下业务架构下访问分布式数据库与当年集中数据库访问有一些不同，业务访问数据库路径错综复杂，比如单元化重构业务可能又会使用到数据中间件的产品，那么流量链路可能跨多个虚拟化节点及VPC网络，如果之间链路中任何一处环节抖动对敏感型交易系统的RT和TPS会有影响，但要分析找到根因处理起来相当棘手。
作为数据库管理员从分析问题思路上开始变迁，原来集中数据库DBA当收到反馈业务缓慢或者毛刺时候，可能DBA只需登录数据库查看下异常等待事件和会话就结束了，但真正问题的原因和问题段我们还是不清晰。云原生到时代到来，有个词汇时常被提及：业务的可观测性。在云上系统中，微服务和单元化带来了容量提升，高扩展、高可用性，却提升了全局系统的复杂度，加大了监控难度。
首先要根据业务自上而下设计可观测体系，分别从业务监控（核心交易）、应用监控（服务调用、qps、rt、jvm gc）、资源监控（虚拟化层、物理层cpu、内存、网络）视角依次推演。可观测的设计贯穿 metric、tracing、logging最终通过问题排查方法论和监控工具来快速发现、分析和解决问题，形成最佳实践。
根据metric、tracing、logging设计方向，业务监控需要关注设计 秒级/分钟级/TOP级业务指标，如：业务交易的总量、成功量、失败量、成功率、平均耗时等，最终以大盘趋势图/对比图的方式汇总呈现。实现应用日志监控采集，应用资源监控，最后把业务/错误日志数据和上下文traceId进行关联，当在应用出现问题时，能够通过调用链的traceid快速关联到业务日志，及时定位分析、解决问题。
上述所说可观测点是从应用端开始的自上而下的监控，区别与传统数据库管理员的运维能力外，分布式数据库由于节点过多链路较长，我们还需要全链路的诊断思路。同时还需要将业务trace_id贯串到数据访问层（数据中间件），目前 OceanBase 中间件产品obsharding一直在完善优化这个功能，在使用单元化场景中，将业务的tracid和中间件层traceid打通，在业务相关交易中进行贯串，可以计算出每个访问阶段耗时。在没有这个功能情况，我们之前按分段处理思路下通常需要借助tcpdump、arthas 等工具来协助分析。数据库侧的监控依托于OCP给的监控指标，如可疑sql、租户异常指标监控如租户memstore、租户cpu、租户会话、租户线程队列、锁等。
Q9 在针对分布式数据库的运维监控，是否有必要构建一个自动化体系？
皇甫晓飞：
与传统数据库相比，分布式数据库的服务器数量应该多了，在过去的那种方法就是增加服务器的数量，我增加运维人员能不能满足运维要求，这个从成本和效果上应该都不是最好的。所以分布式数据库，可以使用客户已有的运维平台，以及结合我们分布式数据库已有的工具或平台来进行自动化体系的建设。我认为建立自动化用体系是非常有必要的。
Q10 当业务链路长且场景多变时，如何预测和实现快速扩容？
鲍磊：
快速扩容就是可扩展性，是集中式数据库和分布式数据库都需要去满足的一个特性。在传统数据库，我们主要是通过纵向扩展的方式来应对业务的增长需求，比如增加一些容量，计算资源。对于分布式数据库来说，横向扩展是一个常规特性，跟集中数据库不太一样，我们可以以节点的为单位来进行扩容。
对于像 OceanBase 这种Share-Nothing的系统，横向扩容会带来一些非常好的线性扩展。同时我们还需要在此基础上做一些分布式的改造，避免一些分布式事物带来负面的影响。然后我们按需扩容或伸缩自由，是比较大的优势，当计算资源不足或单机故障，或机房搬迁的时候，我们都可以通过相应的工具产品去进行一些替换或者是搬迁，这块在大促前后提供到一个降本增效的能力。
OceanBase 通过一些分区级的负载均衡能力去实现系统的扩缩容，我们会确保系统的运行过程中，会对一些server进行一些规格的升级。比如以zone为单位，滚动升级每个zone下面每个OBsever的一些配置，对于集群的扩容，基本上是无缝的在线升级。
在大促的时候，银行业务量是日常的数倍，业务系统需要在大促前进行一些升降配，我们会提前通过OCP上的一些容量指标、监控指标，评估出扩容后的集群规模。就是以zone为单位，然后同等数量或者滚动的给每个zone去扩缩容，或者是给租户级别去进行一个租户规格的扩缩容，比如从三副本扩到五副本，或者给每个zone增加机器。还有会去做一些业务的读写拆分，把一些读的耗时比较长的请求，放到新增新扩出来只读副本上。等流量过去，到了常规流量的时候，我们又在线缩容。这块的话，有效的解决传统数据库在升降配的一些时间和存储容量大小上的不足。
这些动作，DBA可以通过OCP白屏进行一些列的操作，客户还可以根据OCP开放的接口，集成到编排工具产品中，将快速扩容的一些列子任务编排成任务流来运行。
