分布式数据库的全链路高可用解决方案

1. OceanBase 分布式数据库的高可用和稳定性之挑战蔡⻜志（花名：谷渐） OceanBase 开源内核技术负责人 2022.07

2.

3. 海量业务十年磨练，厚积薄发 • 自主研发，完整知识产权、核心能力100%掌控 • 原生分布式关系数据库，商用兼容，平滑迁移 • 企业级能力，支撑蚂蚁核心业务100%负载，外部开始规模商用 • 完整工具配套、服务支撑体系 2010 2013 支持集团产品立项第一个用户支持SQL 2016 支付宝账务核心账务核心交易支付 2019 2017 打破世界纪录多家金融客户互联网核心系统 Oracle 兼容公有云服务 2020 独立商业化 HTAP 引擎 TPC-C 7.07亿 2021 生态大拓展开源开放 TPC-H 30T 1526万 TPC-C 6100万金融核心业务分布式 NoSQL 存储 SQL引擎，三副本高可用分布式事务，强一致透明扩展，多地多活，全分布式

4. TPCC数字的背后可拓展高可用标准文档132⻚，审计流程12⻚，有资格的审计员全部参加数据库需要能够以最终报告tpmC值在稳定状态无任何人工干预前提下保持运行8小时以上，每隔半小时需要完成一次checkpoint 最严苛的测试场景：在使用超出标准要求的全量6000W tpmC压力下，强行销毁了一个云服务器节点，整体tpmC在两分钟内恢复到6000w并持续跑到测试时间结束针对OceanBase架构专设的D测试：连续杀掉了两台服务器节点，首先杀掉一个数据节点，等待tpmC恢复且稳定5分钟后，再次杀掉了rootserver leader节点，tpmC仍然快速恢复

5. 高可用架构一主多从共享存储 Group( Paxos || Raft)

6. 多副本只是高可用冰山一⻆多副本只是架构师或 DBA 最关注的高可用使用方式离全链路高可用还有非常⻓的距离

7. 高可用 – 全链路上每一处精细活全链路高可用面临的挑战非通断性故障影响业务的可用性？软件升级造成业务一定时间内不可用？ SQL占多过多资源，导致业务其他的请求时间变⻓？硬件问题或者程序问题，导致业务的数据错误？业务看到的高可用，才是真正的高可用

8. OceanBase架构方案 Writes Weak Reads Reads OBProxy OBServer OBServer OBServer SQL SQL SQL P1 P2 P1 P2 P1 P2 RS P4 RS P4 RS P4 OBServer OBServer OBServer SQL SQL SQL P5 P6 P5 P6 P5 P6 P7 P8 P7 P8 P7 P8 ZONE_1 ZONE_2 Paxos Group ZONE_3 对等服务端节点 • 无共享架构 • 每个节点有SQL、存储、事务引擎 • 按分区做数据分片扩展 • 多Zone多活高可用轻量客户端 • 无状态 • 资源占用少

9. OceanBase数据链路 Partition leader路由给用户返回结果 Writes OBProxy 访问P1 leader 返回结果，并返回partition hit OBServer1 OBServer2 OBServer3 客户端location cache有效， SQL SQL SQL 可以通过本地执行直接返回结果 P1 P2 P1 P2 P1 P2 RS P4 RS P4 RS P4

10. OceanBase数据链路 Partition leader切换，客户端还未更新location 给用户返回结果，并异步更新location Writes OBProxy 访问P1旧主返回结果，并返回partition miss OBServer1 OBServer2 OBServer3 客户端location cache失效， SQL SQL SQL 可以通过远程执行及时返回结果 P1 P2 RS P4 返回结果远程执行 P1 P2 P1 P2 RS P4 RS P4

11. OceanBase数据链路 Session信息同步 1. 2. 3. 4. 5. 6. Create connection Use database d1； Insert into t1 values(…); Insert into t2 values(…); Insert into t2 values(…); Insert into t1 values(…); OBProxy 1. 2. 3. 6. Create connection Use database d1; Insert into t1; Insert into t1; 4.1 create connection 4.2 use database d1; 4.3 insert into t2; 5. Insert into t2; OBServer1 OBServer2 OBServer2 SQL SQL SQL P1 P2 P1 P2 P1 P2 RS P4 RS P4 RS P4 服务端有session信息变更时，会在返回结果时 “顺带”把信息同步到ObProxy ObProxy保持一个用户链接，可能访问多个链接，并且在链接之间维持session信息，包括系统变量、用户变量、当前数据库等； ObProxy发生连接切换时，用户层面无感知

12. OceanBase数据链路读请求路由 LDC • 同机房 • 同城 server状态 • 合并 • 升级中 • 下线中 Weak read OBProxy 访问follower OBServer1 OBServer2 OBServer3 SQL SQL SQL P1 RS P2 P4 P1 RS P2 P4 P1 RS P2 P4 zone状态 • 只读zone • 下线中 server黑名单 • 活不可用 • 死不可用读zone优先、只限读zone、非合并优先等规则供业务按照自身特点配置

13. OceanBase数据链路 Stop server/zone 非通断性故障： IO 耗时变⻓网络延迟变⻓ Weak read OBProxy 访问leader 访问follower OBServer1 OBServer2 SQL SQL OBServer3（stopping） SQL P1 P2 P1 P2 P1 P2 RS P4 RS P4 RS P4 Stop server/zone: 1. 将leader全部切走； 2. 将server/zone状态修改成stopping；

14. OceanBase数据链路 upgrade server/zone 和stop server类似 Weak read OBProxy 访问leader 访问follower OBServer1 OBServer2 SQL SQL OBServer3 （upgrading） SQL P1 P2 P1 P2 P1 P2 RS P4 RS P4 RS P4 upgrade server/zone: 1. 将leader全部切走； 2. 将server/zone状态修改成upgrading；最佳实践： 1. 先升一台server； 2. 再升一个zone； 3. 依次升级其他zone；

15. OceanBase数据链路 ObProxy升级和ObServer版本解耦 • 标准的Mysql协议通信 • 标准的虚拟表来交互； • Capacity flag； • 路由回退；优化ObProxy的资源占用 • zero copy； • 全异步模型； • Simple Parser； ObProxy和ObServer 的升级计划互相不依赖部署在业务的机器上，和业务APP一起升级 ObProxy稳态运行内存在50M以内单线程QPS在5W以上

16. 系统保证了能快速容灾恢复意味着业务高可用了吗？

17. SQL延迟变高系统资源（CPU、网络、磁盘等）被挤占同样对业务影响比较大

18. OceanBase-SQL调优 User or DB Application SQL statement SQL的流程比较多通常对结果影响比较大的是计划的选择 SQL Compiler Parser SQL Execution Fast Parser Parse Tree Resolver Stmt Query Transformer Xformed Stmt 命中 Plan Cache C1 C2 未命中 Optimizer n schema Cost Estimator Logical Plan Add to cache Physical Plan Code Generator storage

19. OceanBase-SQL调优快速参数化

20. OceanBase-SQL调优 Plan cache PCV PCV PCV PCV … PS PS PS … ACS PCV_v1 PCV_v2 PCV_v3 Outline（/*+index（t1 Idx1）*/ 基于计划缓存实现： SPM：计划演进 ACS：自适应计划匹配 Outline：计划绑定

21. OceanBase-SQL调优 outline Outline本质是不需要业务修改代码，在服务端直接给业务SQL增加Hint • 流量控制 • 设置选择的索引 • 控制查询并发 • 控制查询超时时间

22. OceanBase-SQL调优资源管理限制资源使用面向资源组的隔离机制 • 事务超时 • 单独的“大查询队列” • RPC 超时 • 租户内存资源单独预留 • 链接超时 • 租户独立线程池 • 查询超时 • 网络超时 • 限制运行时间超过一定阈值的查询的 CPU 使用 • 限制“大”查询执行并发度 • 租户线程绑定cpu

23. OceanBase-SQL调优读写分离

24. 系统保证了能快速容灾恢复； SQL也保证了响应时间可控；意味着业务高可用了吗？

25. 血的教训: 当磁盘数据不可信时？当网络数据不可信时？当程序出现 bug ? 技术交流: 钉钉33254054

26. OceanBase的数据可靠性 • 读取最小单位是微块, 写最小单位是宏块 • 读取时, 会校验微块校验和 • 迁移/备份时, 会校验宏块校验和 • 后台周期性巡检宏块校验和

27. OceanBase的数据可靠性主表索引列1-0 列2-0 列3-0 列4-0 索引-0 RID-0 列1-1 列2-1 列3-1 列4-1 索引-1 RID-0 列1-2 列2-2 列3-2 列4-2 索引-2 RID-0 列1-3 列2-3 列3-3 列4-3 索引-3 RID-0 列1-4 列2-4 列3-4 列4-4 索引-4 RID-0 列校验和列校验和列校验和列校验和校验和 • SSTable 累计行校验和 • SSTable 列校验和 • 合并时: • 索引列列校验和和主表列的列校验和进行比较 • 副本之间的行校验和和列校验和进行比较

28. OceanBase的数据可靠性一个神奇的函数 - right_to_die_or_duty_to_live 程序出现异常时，当前线程保留现场，其他线程继续提供服务

29. OceanBase的数据可靠性误删数据？ MVCC多版本支持数据闪回

30. OceanBase的数据可靠性热备冷备 • 主备库 • 物理备份 • 异步复制 • 逻辑备份提供更高的可用性提供更高的回退能力

31. OceanBase的数据可靠性

32. OceanBase的数据可靠性可以恢复到特定的时间点

33. 小结 • • • 在数据链路层屏蔽容灾切换对于业务的影响在SQL层，通过执行计划绑定、读写分离、资源隔离等方式，降低SQL出问题的概率，减少对于业务的影响在存储、系统等层次，通过程序自检、数据闪回、备份恢复等方式，降低软件问题导致的业务不可用时间；

34. 一体化架构：原生分布式 + HTAP + 两种兼容模式 MySQL 兼容 Oracle 兼容 HTAP 引擎（TP+AP） SQL 优化引擎一套 HTAP 引擎同时支持 TP 和 AP 业务统 SQL 执行引擎存储过程单机分布式一体化架构分布式存储分布式事务同城三机房双机房主备分布式调度两地三中心三地五中心灵活的部署模式专有云独立部署一SQL界面，共享数据单机分布式一体化架构，兼具单机性能易用基于 Paxos + 数据同步的灵活的容灾架构单机房三副本一套产品兼容主流的数据库，保证平滑迁移公有云性，以及分布式可扩展性，全局强一致性支持最高级别容灾模式，也支持经典模式灵活部署，无缝适配云化架构和经典架构

35. 开源开放期望共建

36.

37. 感谢聆听, 欢迎加入社区钉钉群微信交流 https://github.com/oceanbase https://open.oceanbase.com