OceanBase DBA 进阶教程，手把手教你玩转开发与运维

加油

这个必须多回个赞

挺好

课程很棒 希望能提供课件下载

后续电子书会开放出来供大家下载滴

学习

学习了

希望能在每节课完成后就提供课间下载，这样大家可以保存起来，随时学习。

很棒

我说咋看内容这么熟悉，原来在这。。

打卡

打卡

打卡第一章 容灾架构设计

学习笔记

一、选举服务是高可用的基石。不同于OceanBase数据库之前的版本，在V4.x版本中，选举服务的粒度从分区变为日志流，分区挂载在日志流上。日志流的多个副本通过选举协议选择其中一个作为主副本(Leader) ，在集群重新启动时或者主副本出现故障时，都会进行这样的选举。此外，在V4.x版本中，选举服务也不再依赖 NTP或其他时钟同步服务来保证集群中各机器时钟的一致性，而是通过本地时钟以及经过改进的租约机制来保证一致性。选举服务由优先级机制来保证选择更优的副本作为主副本，优先级机制会考虑用户指定的Primary Zone，以及机器的异常状态等。

二、物理备库容灾是OceanBase数据库高可用解决方案的重要组成部分。物理备库容灾技术面向多个集群，多集群间传输事务日志，建立基于日志的物理热备服务。在OceanBase 数据库V4.2.x及以上版本，物理备库采用独立的主备库架构，主备关系存在于租户级别，主备之间通过网络直连或第三方日志服务建立传输渠道，只传输日志。不同于以前版本的集中式架构，独立主备库架构下，各个集群是是相互独立的，用户可以更加灵活地管理集群。租户级主备由于异步同步日志，仅支持最大性能模式，不支持最大保护和最大可用模式，容灾切换时需要保证数据强一致的场景可以采用多副本容灾方案或基于仲裁的容灾方案。

三、同城三中心三副本：面向具备一个城市三个机房的场景。同城三个机房组成一个集群(每个机房是一个Zone)，机房间网络延迟一般在0.5~2ms之间。能够防范少数派节点故障。能够防范单机房故障。无法防范城市级故障。

四、CAP理论‌（Consistency, Availability, Partition tolerance）是分布式系统设计中的一个重要理论，由Eric Brewer提出。它描述了在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个要素最多只能同时实现两个，无法三者兼顾。‌传统数据库无法打破“CAP理论”。但OceanBase数据库基于Paxos协议的多副本容灾技术真正做到了同城和异地的无损容灾，达到RPO = 0，RTO <8秒。通过 OceanBase数据库的多副本技术实现的容灾架构，应用只需要感知一个数据源，数据库内部复制的细节对应用完全透明。同时，它提供了单机级、机房级、甚至城市级故障的无损容灾能力，并且恢复时间小于8秒。

五、 基于日志异步复制的物理备库解决方案：该方案类似于传统数据库的主备复制解决方案。两个或多个集群之间，允许以租户为粒度，通过异步复制 Redo 日志来构建租户级别的主备关系，提供计划内无损切换和故障时有损切换两种容灾能力。该方案主要用于满足双机房或双地域场景下的容灾需求。主租户提供读写能力，备租户提供只读和容灾能力。在执行计划内无损切换时，主租户和备租户互换角色，不丢数据(RPO=0)，切换时间为秒级(RTO 为秒级)。当主租户所在的集群出现故障后，可以执行有损切换，将备租户切换为主租户。此时不能保证不丢数据，RPO大于0，切换时间为秒级(RTO为秒级)。

学习心得​

在深入学习 OceanBase 数据库的过程中，我对其高可用架构和容灾技术有了更为全面且深刻的认识。​

OceanBase 数据库 V4.x 版本在选举服务上做出了重大改进，选举粒度细化到日志流，分区依托日志流挂载。通过选举协议，日志流的多个副本中会诞生主副本，这一过程在集群重启或主副本故障时尤为关键。值得一提的是，V4.x 版本摒弃了对 NTP 等时钟同步服务的依赖，转而采用本地时钟搭配改进租约机制来确保一致性，同时引入优先级机制，综合 Primary Zone 用户设定与机器异常状态等因素，筛选出更优的主副本，这极大提升了选举服务的可靠性与稳定性，为整个数据库系统的高可用筑牢了根基。​

物理备库容灾作为 OceanBase 数据库高可用解决方案的核心构成，在 V4.2.x 及后续版本中，采用独立主备库架构，主备关系精确到租户级别，各集群相互独立，给予用户更灵活的管理空间。但因采用异步同步日志，仅支持最大性能模式，在需数据强一致的容灾切换场景下，需借助多副本容灾或基于仲裁的容灾方案。这种架构设计虽有一定限制，却也在特定场景下提供了高效的容灾手段。​

同城三中心三副本方案，针对拥有同城三个机房的场景，三个机房构建成一个集群，机房间网络延迟处于 0.5 - 2ms，能有效应对少数派节点故障与单机房故障，但无法抵御城市级灾难。这让我意识到在不同应用场景下，需因地制宜选择合适的架构方案，以平衡成本与风险。​

OceanBase 数据库打破了传统数据库无法突破的 “CAP 理论” 禁锢，基于 Paxos 协议的多副本容灾技术实现了同城和异地的无损容灾，达到 RPO = 0，RTO < 8 秒，对应用隐藏了数据库内部复制细节，提供了全方位的故障无损容灾能力，恢复时间极短，这无疑是其在分布式系统设计领域的重大技术突破。​

基于日志异步复制的物理备库解决方案，类似传统数据库主备复制，以租户为粒度构建主备关系，具备计划内无损切换和故障时有损切换能力，适用于双机房或双地域场景，在不同故障场景下保障数据的可用性与一致性。​

学习 OceanBase 数据库让我对分布式数据库的高可用和容灾技术有了全新认知，其先进的技术理念与灵活多样的解决方案，为构建可靠、高效的数据库系统提供了丰富思路与实践指导，在未来的工作与学习中，我将持续深入探索其更多应用可能。​

学习建议

在学习 OceanBase 数据库时，建议先从基础架构入手，深入理解日志流、分区与副本之间的关联，通过实际操作选举服务相关的模拟场景，如集群重启或主副本故障，直观感受选举机制的运行逻辑。对于物理备库容灾和同城三中心三副本等复杂架构，可结合具体案例分析，绘制架构图来梳理数据流向与故障应对策略。在掌握理论知识后，积极参与开源社区讨论，参考实际项目中的应用经验，尝试搭建小型测试环境，亲身体验 OceanBase 数据库在不同场景下的高可用和容灾效果，从而加深对技术的理解与运用能力。

值得在这里单独发篇帖子让更多的小伙伴学习一下：https://ask.oceanbase.com/

需要按照指定格式来进行打卡哟，光发打卡两字是无效打卡滴 ：
格式示例： 打卡第X章 + 学习笔记/心得/建议 + 通过课后习题截图

根据打卡格式完善一下打卡内容哈，让更多小伙伴们看到你的思考
格式示例： 打卡第X章 + 学习笔记/心得/建议 + 通过课后习题截图

不得了，大本营被发现了