VastbaseG100

基于openGauss内核开发的企业级关系型数据库。

Menu

运行过程故障

正常情况下,HAS服务启动后,使用${has_home}/bin/sd_hasctl 工具 list命令查看如下:

  • 如运行过程中备库发生故障,主库不受影响;

  • 运行过程中主库发生故障,备库将自动挂载存储设备并启动数据库对外提供服务。原主库问题解决后重新启动将以备库身份加入

以下描述HAS运行过程中可能需要人工介入的故障问题。

switchover失败

问题描述:

执行switchover,提示如下图所示的错误信息。

原因分析:

主节点收到switchover请求后,会先检查挂载点目录除了本节点数据库实例进程使用外,是否还有其他进程在使用,如果有,则提示switchover失败,提示信息如上图所示。

解决方法:

1、查看数据库进程,获取进程号<vastbase pid>。

ps -ef|grep vastbase

2、通过lsof检查正在使用的进程,输出如下图所示。

lsof <mount point>|grep -v <vastbase pid>

  • 第一列COMMAND表示占用挂载点目录的命令或程序名称。

  • 第二列PID表示表示占用挂载点目录的进程号。

  • 第三列USER表示占用挂载点目录的进程拥有者。

  • 第九列NAME表示占用进程打开文件的确切名称。

3、结束步骤2的进程,结束进程的方式根据实际的进程选择合理的退出方式。

  • 对于只读的占用进程(cd命令,tail命令等),例如通过cd命令进到挂载点目录,可以通过正常的方式退出该目录或者通过kill -9 <pid>结束该进程,其中为步骤2中的第二列PID。
  • 对于读写的占用进程(vi命令等),不建议通过kill -9 来结束进程,应该通过vi工具的退出方式结束该进程,否则会造成编辑的数据丢失问题。

switchover过程中HAS进程停止或宕机

问题描述:

如果在switchover过程中,某个节点意外停止进程或宕机,仲裁盘中的switchover标记有可能并未被更改回最初状态。该情况下需要停止HAS服务并使用${has_home}/bin/sd_hasctl工具的隐藏命令clear将状态手动清除。

解决方法:

1、查看仲裁设备信息。

cat ${arbitrator_path}

其中,arbitrator_path为仲裁设备路径。如图所示,仲裁设备数据中switch_status一项为3,并未改为0。

2、停止剩余节点has服务。

systemctl stop has

3、使用${has_home}/bin/sd_hasctl 工具对仲裁设备进行清理。

${has_home}/bin/sd_hasctl –c ${config_path} clear  

其中config_path为yml配置文件路径。

4、重新启动步骤2中停止的HAS服务,该节点即可正常提供服务。