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

蔡飞志(花名:谷渐)OceanBase开源内核技术负责人7产品立项第一个用户独立商业化打破世界纪录支付宝账务TPC-C7.07亿Oracle产品立项第一个用户独立商业化打破世界纪录支付宝账务TPC-C7.07亿Oracle兼容公有云服务TPC-C6100万核心账务核心交易支付金融核心业务分布式事务,强一致分布式NoSQL存储 SQL引擎,三副本高可用海量业务十年磨练,厚积薄发••自主研发,完整知识产权、核心能力100%掌控•企业级能力,支撑蚂蚁核心业务100%负载,外部开始规模商用•原生分布式关系数据库,商用兼容,平滑迁移•完整工具配套、服务支撑体系支持集团支持支持SQL多家金融客户互联网核心系统生态大拓展生态大拓展开开源开放TPC-H30T1526万透明扩展,多地多活,全分布式TPCC背后标准文档132页,审计流程12页,有资格的审计员全部参加数据库需要能够以最终报告tpmC值在稳定状态无任何人工干预前提下保持运行8小时以上,每隔半小时需要完成一次checkpoint最严苛的测试场景:在使用超出标准要求的全量6000WtpmC压力下,强行销毁了一个云服务器节点,整体tpmC在两分钟内恢复到6000w并持续跑到测试时间结束针对OceanBase架构专设的D测试:连续杀掉了两台服务器节点,首先杀掉一个数据节点,等待tpmC恢复且稳定5分钟后,再次杀掉了rootserverleader节点,tpmC仍然快速恢复Group(Paxos||Raft)离全链路高可用还有非常长全链路高可用面临的挑战SQL占多过多资源,导致业务其他的请求时间变长2硬件问题或者程序问题,导致业务的数据错误2业务看到的高可用,才是真正的高可用OBServerP1P2OBServerP1P2OBServerOBServerZONE_1ZONE_2WritesReadsWeakReadsOBProxyOBServerOBServerOBServerZONE_3PaxosGroup•无共享架构•每个节点有SQL、存储、事务引擎•按分区做数据分片扩展•无状态Writes访问P1leaderWrites访问P1leaderOBServer3tionleader给用户返回结果OBProxyOBServerOBServer1返回结果,并返回partitionhitOBServer2客户端locationcache有效,可以通过本地执行直接返回结果WritesOBServer1WritesOBServer1回结果程执行Partitionleader切换,客户端还未更新location给用户返回结果,并异步更新locationOBProxy访问P1访问P1旧主OBServerOBServer2OBServer3客户端locationcache失效,可以通过远程执行及时返回结果OBServer1OBServer1OBServer2connectionconnectiontotvaluestotvaluestotvaluestotvalues OBProxyconnectionUsedatabaseconnectionUsedatabased1;Insertintot1;4.2usedatabased1;4.3insertintot2;5.Insertintot2;OBServer2服务端有session信息变更时,会在返回结果时“顺带”把信息同步到ObProxyObProxy保持一个用户链接,可能访问多个链接,并且在链接之间维持session信息,包括系统变量、用户变量、当前数据库等;ObProxy发生连接切换时,用户层面无感知Weakreadserver状态OBProxy访问followerOBServer2OBServer3•只读Weakreadserver状态OBProxy访问followerOBServer2OBServer3•只读zone•下线中zone状态单•活不可用•死不可用由•同机房•同城••合并•升级中•下线中OBServerOBServer1读zone优先、只限读zone、非合并优先等规则供业务按照自身特点配置OBServer2OBServer2访问leader访问followerOBServer3(stopping)Stopserver/zoneWeakreadOBProxyOBServerOBServer1非通断性故障:Stopserver/zone:1.将leader全部切走;2.将server/zone状态修改成stopping;OBServer2OBServer2访问leader访问followerOBServer3(upgrading)upgradeserver/zoneWeakreadOBProxyOBServerOBServer1和stopserver类似upgradeserver/zone:1.将leader全部切走;2.将server/zone状态修改成upgrading;最佳实践:1.先升一台server;2.再升一个zone;3.依次升级其他zone;ObProxy升级和ObServer版本解耦•标准的Mysql协议通信•标准的虚拟表来交互;•Capacityflag;•路由回退;优化ObProxy的资源占用•zerocopy;•全异步模型;•SimpleParser;ObProxy和ObServerObProxy态运行单线程QPS在5W以上部署在业务的机器上,和业务APP一起升级系统资源(CPU、网络、磁盘等)被挤占UserorDBApplicationtionnPlanCacheUserorDBApplicationtionnPlanCacheSQLSQLstatementSQLCompilerFastParserschemadStmtCostEstimatorstoragetocacheFastParserschemadStmtCostEstimatorstoragetocacheResolverCodeGeneratorSQL的流程比较多通常对结果影响比较大的是数化…………Idx1)*/ Outline(/*+index(t1基于计划缓存实现:SPM:计划演进ACS:自适应计划匹配Outline:计划绑定neOutline本质是不需要业务修改代码,在服务端直接给业务SQL增加Hint•流量控制•设置选择的索引•控制查询并发•控制查询超时时间面向资源组的隔离机制面向资源组的隔离机制•单独的“大查询队列”•租户内存资源单独预留•租户独立线程池•租户线程绑定cpu限制资限制资源使用•事务超时•RPC超时•链接超时•查询超时•网络超时•限制运行时间超过一定阈值的查询的CPU使用•限制“大”查询执行并发度系统保证了能快速容灾恢复;SQL也保证了响应时间可控;血的教训:技术交流:钉钉33254054•读取最小单位是微块,写最小单•读取时,会校验微块校验和•迁移/备份时,会校验宏块校验和•后台周期性巡检宏块校验和校验和校验和列4-4列校验和列1-0列2-0列3-0列1-1列2-1列3-1列1-3列2-3列3-3列校验和列校验和列校验和列校验和列校验和列校验和索引-1•合并时:•索引列列校验和和主表列的列校验和•副本之间的行校验和和列校验和进行比较一个神奇的函数-right_to_die_or_duty_to_live程序出现异常时,当前线程保留现场,其他线程继续提供服务•主备库•异步复制提供更高的可用性•物理备份•逻辑备份提供更高的回退能力可以恢复到特定的时间点••在数据链路层屏蔽容灾切换对于业务的影响•在SQL层,通过执行计划绑定、读写分离、资源隔离等方式,降低SQL出问题的概率,减少对于业务的影响•在存储、系统等层次,通过程序自检、数据闪回、备份恢复等方式,降低软件问题导致的业务不可用时间;分布式事务分布式调度独立部署公有分布式事务分布式调度独立部署公有云一体化架构:原生分布式+HTAP+两种兼容模式Oracle兼容MySQLOracle兼容SQL优化引擎存储过程HTAP引擎(SQL