【 使用环境 】生产环境
【 OB or 其他组件 】obd
【 使用版本 】
【问题描述】当前obd只部署在一台中控机上,存在单点故障问题,现需要新增部署在另外一台中控机上,并且可正常管理当前所纳管集群,该如何操作
【复现路径】
【附件及日志】
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
【 使用环境 】生产环境
【 OB or 其他组件 】obd
【 使用版本 】
【问题描述】当前obd只部署在一台中控机上,存在单点故障问题,现需要新增部署在另外一台中控机上,并且可正常管理当前所纳管集群,该如何操作
【复现路径】
【附件及日志】
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
根据您的描述,您希望通过在第二个中控机上也部署 obd 以消除单点故障问题。然而,在 OceanBase 的官方文档和当前的社区实践中,并没有直接支持在多个中控节点间进行 obd 的高可用性部署或自动切换的功能。obd 本身的设计是作为集中式管理工具来使用的,主要运行于单一节点。但是,您可以通过一些间接的方法来达到一定程度上的高可用性和容灾效果。
.obd 目录(该目录通常位于用户的家目录下),它包含了所有关于 obd 管理的集群的信息。如:cp -r ~/.obd /path/to/backup/.obd_$(date +%Y%m%d)
.obd 文件夹,并使用相同版本的 obd 安装包重新安装 obd。.obd 后,请确保所有必要的依赖环境一致(例如 Python 版本、其他系统库等)。对于更复杂的高可用性需求,可以考虑将 .obd 目录放置在一个网络文件系统(NFS)或其他形式的共享存储上,这样两台服务器都可以访问相同的配置信息。此方案要求更加复杂的架构设计以及对网络稳定性的较高要求。
注意:以上方法并不保证无缝过渡或者实时冗余支持;在实际生产环境中实现此类方案前应充分测试,并且考虑到可能存在的风险。
目前通过官方提供的工具和指南,直接实现 obd 的双节点或多节点高可用部署并非易事。推荐采用上述提到的手动备份结合快速恢复的方式,作为一种相对简单的灾难恢复策略。如果您所在的组织对于自动化和即时接管有着更高的需求,则建议探索第三方的监控与切换机制或是自定义脚本来实现这一目标。同时,保持关注OceanBase官方后续是否会有相关更新和支持。
详情请参考:
obd还要考虑单点故障,可用性要求的巨高啊
OB本身的1-1-1架构或3-3-3架构不就是高可用么,为啥要部署两个obd呢
obd没必要啊,这个只是管理集群的。
你还不如部署多个ocp呢,接管ob集群
赞赞赞
直接用ocp岂不是更好
操作系统定期做快照 。有问题恢复快照。不过你这种的建成灾备不是更好 。
66
非常有深度的一篇好文,点赞支持。
了解了解
受教了。
666
好好学习!!!
obd的环境依赖,observer机器的可达性与配置文件管理,原则上,理论上应该可以实现一个standby的机器。
+1
也是个不错的主意
OBD 是管理工具非运行时组件,不支持双活。高可用方案:① 元数据目录 rsync 到备机 + 定时同步;② 备机安装同版本 OBD,主故障后手动切换接管集群。OBD 本身不存集群运行时数据,切换只需元数据一致即可继续管理。