曾经接触过很多 OceanBase 社区版的用户，大家在准备进行 POC 测试前的技术交流中，第一波儿问题往往就是 OceanBase 的高可用容灾架构如何设计。
数据库系统在应用架构中承担了数据存储和查询的功能，对企业数据安全和保障业务连续性至关重要，高可用和容灾确实也是数据库系统架构设计中首要考虑的因素。
因此《OceanBase 4.x DBA 进阶教程》的第一部分内容，就是 “容灾架构设计”。
OceanBase 数据库具备多样化的服务高可用技术，包括集群内的多副本容灾，以及集群间的物理备库容灾。“容灾架构设计” 这一章节会为大家介绍：基于多副本的高可用解决方案、 基于日志异步复制的物理备库解决方案，以及会对常用的几种容灾部署方案进行一个简单的总结。希望能够对大家有所帮助~
《OceanBase 4.x DBA 进阶教程》已经根据大家的意见开始整理，本帖推荐的内容链接详见：“容灾架构设计”。
如果大家对本章节的内容有任何问题或者建议，欢迎在本帖中留言，我们会第一时间回复大家！
如果大家对这本手册有任何建议，或者有任何希望加入这本手册中的内容，欢迎在
《OceanBase 4.x DBA 进阶教程》用户意见收集 这个帖子中留言评论，我们会直接根据大家在问卷中的选择以及对内容大纲提出的建议，来完善这本运维开发手册~
点赞 
mark
4.x版本不再支持主备最大保护，我觉得是一种退步。重要的行业或单位，都不允许丢数据的。
从严格的acid 上看, 如果需要做到强一致, 只有使用类似paxos 这样的一致性协议, 才能保障强一致.
如果需要真正意义上的不丢数据, 建议使用paxos 更多副本的架构(或者使用仲裁副本的方案, 减少成本), 比如5副本, 在3地5中心的设计.
今天主备库的方案在同步时会有位点信息, 会保证数据同步过来, 而且用到非常多的同步优化技术, 保障了同步效率比传统数据库例如mysql, pg 更快的同步性能.
4.x 最新版本已经使用proxy 透明代理主备库的方案, 可以让应用使用一个链接地址, 底层可以做无缝切换.
[quote=“longda, post:11, topic:35611854”]
5副本, 在3地5中心的设计。
增加了成本，小公司很难承担。
今天主备库的方案在同步时会有位点信息, 会保证数据同步过来, 而且用到非常多的同步优化技术, 保障了同步效率比传统数据库例如mysql, pg 更快的同步性能.
也仅仅是快，不是说不会丢失数据。
4.x 最新版本已经使用proxy 透明代理主备库的方案, 可以让应用使用一个链接地址, 底层可以做无缝切换.
你说的这个，是类似vip地址么？
哈哈，你用的是商业版本呀！直接去用仲裁副本吧！
进阶教程是针对社区版本的，没有把商业版特有的几种功能也拿来一起为大家介绍，实在不好意思~ 
社区版和商业版的功能区别详见：https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001428510
今天听说 2025 财年规划了重新支持最大保护模式的主备库，对使用 4.x 版本的社区版用户来说是好消息。
不过对你们商业版的用户来说，还是 2F1A 的仲裁副本更合适些。
