暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

分布式数据库学习Note185:OceanBase社区版中,节点宕机是什么?

欢迎访问OceanBase官网获取更多信息:https://www.oceanbase.com/


当数据库因为硬件问题导致提供数据库服务异常,出现节点宕机时,需要对故障机器采取应急措施。本文主要介绍节点宕机的应急处理方法。

应急处理方法

  • 对于已知的机器硬件故障,应直接替换故障机器。

    首先要确保集群中有足够的冗余资源(OBServer机器),可以代替故障节点进行工作。具体操作请参见 故障 OBServer 节点替换

  • 非硬件故障,未知原因的 observer 进程退出。

    对于这类场景,比如 core dump 场景,应急处理办法也是先尝试拉起恢复。

对于无法第一时间确认是否因硬件故障导致的节点宕机(例如网络抖动、掉电等其他原因),此时用户可能希望不是立即替换该节点,而是修复其他问题后再次尝试拉起 observer,此时需要注意server_permanent_offline_time 参数的设置。在 OceanBase 数据库中,server_permanent_offline_time 配置项的名称为"永久下线时长",是用来控制"集群中某个节点不可用多长时间后,OceanBase 将其踢出成员列表"。例如,假设某个 OB 集群中 server_permanent_offline_time 的值为 2h,那么意味着当某台节点宕机后,在 2 小时内如果可以恢复,那么拉起后的 OB 节点数据依然有效,只需追平宕机期间落后的增量数据即可。但是如果宕机超过 2 小时,那么节点再次拉起后,节点中的所有副本都会被清空(被 RS 踢出 Paxos 成员列表),其上的全部数据都需要从其他副本重新拉取。


欢迎访问OceanBase官网获取更多信息:https://www.oceanbase.com/

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论