背景
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.rpm2、执行一下 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.sh2、执行一下 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: UNCHNAGE5、尝试执行
obd cluster list
obd cluster display xxx如果上面的命令可以正常执行，可以尝试 obd cluster edit-config xx修改参数 memory_limit 来进一步确认。
