比如如果我掌握了单副本拉起的非标准操作。对于官方来说，这并不会作为选项提供给客户，而且从官方态度来看是禁止的，那是不是不太合适分享出去。
在开源的角度看是没问题的吧,如果是企业版官方可能要发个免责声明了
这得看官方声明那些吧
1 个赞
-
我理解社区里分享的所有东西，都是非公开的技巧，官方公开的技巧也轮不到咱们来给大家分享。
-
你的言论不代表官方，我个人理解完全可以分享出来。实在担心的话，在开始或者结尾处说清楚这是你的个人观点，与 OceanBase 无关啥的就好了，让大家出了问题别赖上官方人员。
-
多数派出了故障，如果还没有备份或者备库，只能死马当成活马医。官方跟将死之人说他只能等死，你站出来说 “还有救”，就算你的单副本拉起没能成功救活他，也是命中该然，怕个锤子？万一你这个小陈胜举大计成功了，吊打官方，那多威风！
以上言论仅代表我的个人观点，与 OceanBase 无关。
4 个赞
搞啊，想跟大佬们多学习
1 个赞
必须分享啊，期待！
1 个赞
感谢分享
1 个赞
相关的都可以分享吧，也是基于ob的一种探索吗，担心的话就末尾或者开头价格，仅用于个人demo，强烈不建议生产实际使用
支持，越来越丰富了，现在社区
paxos 和 raft 协议决定了多数派故障下无法选主成功。假设选出少数派成员中的一个也是不能保证这个新主数据能恢复到老主完全一致。ob和tidb都是如此，有些国产数据库也有多副本，能少数派存活提供服务，那就不是使用paxos或raft协议而是自定义的qurum 机制。
ob的少数派拉起技术一不保证一定拉起成功二个拉起成功也不保证数据不丢。ob的多数派故障应对方案就是搭建ob备集群（v3）或ob备租户（v4）。这个就跟oracle rac 方案还要搭配一个dg备库才能完全保障客户数据库的高可用。
ob的dg方案是原厂保障支持的，除了dg还要有备份，这样才高枕无忧。ob不支持少数派拉起技术就是为了断掉一些不合理的部署方案的使用想法。一些不合理的部署方案如果出现故障后传出来的信息就是变形失真的负面信息。拿传统数据库打个比方：在发生故障时说oracle会丢数据，大部分人是不信的；说mysql不丢数据，大部分人也是不信的。技术上是有其原因的。ob的这个坚守在目前是有意义的。
1 个赞
是的梅老师，我能理解官方的考虑。一，实际的客户现场不一定都能按照最佳的实践去做。二，完整的备份和备库基本是生产的必要选项，但对于ocp的meta库这类环境，大部分客户应该再去搭建备库和备份的很少，我当时确认这个点，也是要给自己一个可选择的方案。
金融行业客户 ocp 多是三副本。非金行业有不用三副本的。 如果ob集群规模很小，ocp 和 metadb 就单副本 我觉得也合理。 新的 ocp 版本好像还限制了 metadb 的一些运维操作。
metadb 上的应用就是 ocp 自身，ocp 稳定的话这个 metadb 基本也稳定。metadb 面临的风险比业务 ob 面临的风险要小很多。所以我认为 metadb 不需要做备库。或者说大部分客户的ocp 的ob应该是不做备库的，只有极少数 ocp 做了主备可用区的那种会有2个独立的metadb 且保持元数据同步，这是一种ocp和metadb 的高可用方案。只有对ocp和metadb 高可用要求非常高的客户（还得是金融客户）才会选择这种。
对于大部分客户而言，如果ocp和metadb 真挂了，影响也有限。业务 ob的使用并不受影响。ocp和metadb 重搭一下就可以，然后再接管现有 ob 集群。不过这个做法在业务ob集群规模和租户规模很大的时候会非常痛苦，因为有一堆主机和租户凭据要维护。所以平时 ocp要把主机和数据库的凭据导出备份一下，以备不时之需。 这种业务ob和租户规模很大的情形下，那还是建议 ocp和metadb 也采取三节点部署。不折腾的情况下，ocp的metadb 自身的可用性还是非常高的。
1 个赞
是的，正常情况下不会发生这种情况。这算是个超极端的场景 