安装OceanBase的机器如果出现故障，应该如何处理

背景        

           OBD（OceanBase Deployer），是OceanBase社区版的专属安装部署工具。它支持命令行或白屏界面部署，将复杂的配置流程标准化，大大降低了集群部署的难度。

有用户在使用过程中提出问题——“当我所在的OBD机器发生永久故障时，该如何应对？”这里我们将分享一些经验来解决这个问题。在深入探讨之前，我们设定一些基本定义，以方便理解：原OBD所在的机器称为A，新安装的OBD所在的机器则称为B。关于在机器B上安装OBD，我们需要区分非all-in-one和all-in-one两种使用场景下的不同操作。

事前处理：

非 all-in-one 环境：

1、在机器B上安装同版本的 obd

sudo yum install ob-deploy-2.7.0-5.el7.x86_64.rpm

2、执行一下 obd cluster list ，默认用户家目录下没有.obd目录/子目录及其文件，执行后会自动生成。

all-in-one 环境：

1、在机器B上安装同版本的 all-in-one，这里以 oceanbase-all-in-one 为例 ocp-all-in-one 也是一样的步骤。

tar -xzf oceanbase-all-in-one-*.tar.gz
cd oceanbase-all-in-one/bin/
./install.sh
source ~/.oceanbase-all-in-one/bin/env.sh

2、执行一下 obd cluster list ，默认用户家目录下没有.obd目录/子目录及其文件，执行后会自动生成。

安装 rsync 和 inotify-tools

在A/B机器上安装 rsync
sudo yum install -y rsync
 
在A机器上安装 inotify-tools
sudo yum install -y inotify-tools

编写 inotify-watcher 脚本

在机器A上创建一个 Bash 脚本（例如 sync.sh），该脚本利用 inotifywait 监听指定目录的变化，并触发 rsync 进行同步。

#!/bin/bash
 
# 指定要监视的源目录
SOURCE_DIR="/home/heshun.lxd/.obd"
 
# 指定目标服务器和目录
DESTINATION_SERVER="${主机B_IP}:/home/heshun.lxd/.obd"
 
while true; 
do
  # 使用 inotifywait 监控源目录的变化，这里只监听修改和新增文件事件
  inotifywait -r -m $SOURCE_DIR -e modify,create,delete,move |
  while read path action file; 
  do
    echo "Change detected: $action on $file"
    # 执行rsync同步，仅同步比目标目录中对应文件新的或被修改的文件
    rsync -avzu --delete --progress --backup --update "$SOURCE_DIR/" "$DESTINATION_SERVER"
  done
done

脚本说明：

inotifywait -r -m $SOURCE_DIR -e modify,create,delete,move

-r 或 --recursive：表示递归地监视指定目录 $SOURCE_DIR 及其所有子目录。这意味着任何在该目录及其子孙目录下的文件或子目录发生改变时，都会被监控到。

-m 或 --monitor：持续监听模式。它会一直运行并报告发生的事件，而不是执行一次就退出。

$SOURCE_DIR：这是要监视的源目录路径变量。

-e 或 --event：指定需要关注的特定事件类型。

modify：当文件内容被修改时触发事件。

create：当有新文件或目录创建时触发事件。

delete：当文件或目录被删除时触发事件。

move：当文件或目录被移动（重命名）时触发事件。

while read path action file，其中 path，action 和 file 是三个变量，它们分别用来接收由 inotifywait 输出的事件信息中的目录路径、事件动作和文件名。

整个脚本的功能：每当 $SOURCE_DIR 目录及其子目录中的文件发生修改、创建、删除或移动时，inotifywait 都会输出相应的事件信息，并且由于使用了 -m 参数，它会持续监听这些事件的发生，而不仅仅是检测一次。

给脚本授权并执行

chmod +x sync.sh
nohup ./sync.sh &

测试：

在B机器上可以通过obd维护原A机器上使用obd部署的环境。

事后处理

如果在A机器永久故障前，没有在B机器上提前做好备份/同步，当A机器永久故障后，此时可以尝试：

1、如果记得A机器上部署的obd版本，最好下载并安装该版本的obd，如果不记得，可以尝试安装最新版本的obd.

2、执行一次 obd cluster list

3、在 ～/.obd/cluster 目录下创建一个目录，目录名即是原obd部署时指定的 deploy_name 名字。

4、在第3步创建的目录下创建2个文件 config.yaml 和 .data （注意是隐藏文件）。

   4.1 config.yaml 建议在其他机器上部署一个同版本的observer/obproxy/ocp-server 按需选择需要的组件，然后将对应的配置文件拿过来修改为需要在机器B上通过obd来管理原机器A上管理的环境。

   4.2 .data  name名字和第3步创建的目录名保持一致。文件内容中涉及的组件需要和4.1步骤中能对应的上，其中：

•  hash字段：通过 obd mirror list local 或者 obd mirror list oceanbase.community.stable 对应同组件同版本的md5值。
•  version字段：通过 obd mirror list local 或者 obd mirror list oceanbase.community.stable 对应同组件同版本的version值。
•  确认所有组件是正常运行的，status字段设置: STATUS_RUNNING ，
•  config_status字段设置: UNCHNAGE

.data 文件示例：

name: ob430
components:
  oceanbase-ce:
    hash: c4a03c83614f50c99ddb1c37dda858fa5d9b14b7
    version: 4.3.0.1
  obproxy-ce:
    hash: 0490ebc04220def8d25cb9cac9ac61a4efa6d639
    version: 4.2.3.0
status: STATUS_RUNNING
config_status: UNCHNAGE

5、尝试执行

obd cluster list 
obd cluster display xxx

如果上面的命令可以正常执行，可以尝试 obd cluster edit-config xx修改参数 memory_limit 来进一步确认。