问题描述
客户使用6.0.0LTS版本数据库，进行扩容，扩容执行失败
问题定位
一、节点ip对应多个hostname
1.扩容失败报错如下：
根据报错信息查看代码，在相应位置添加日志打印，发现是ip和hostname的映射有问题，因此在通过ssh远程执行命令时报错。
如果也是使用6.0.0版本的用户，可以排查一下是否也需要修改，查看是否也存在该问题。（该问题一般是由于在一台服务器上起了多了业务，除了数据库外。有其他业务也创建了互信，但是记录的ip hostname与数据库记录的不同导致），通过查看文件即可确认，如下所示：
cat /etc/hosts
2.查看社区OM仓，发现已经有相关的修改pr
https://gitee.com/opengauss/openGauss-OM/pulls/954/files
https://gitee.com/opengauss/openGauss-OM/pulls/969/files，该pr中SshTool.py脚本的修改
3.通过git工具将修改apply到6.0.0LTS版本中
4.编译OM
cd openGauss-OM
sh build.sh -3rd /xxxxxx/binarylibs 路径为3方库路径，3方库可在openGauss-server的readme中找到
编译好的报就在package目录下面
5.本地验证
两种场景下验证：
1）已安装的环境，替换OM包验证
5.1 下载官网安装包安装1主2备环境
192.168.0.19/20/21
5.2 缩容21节点，成功
gs_dropnode -U lzf_sdr -G lzf_sdr -h 192.168.0.21
5.3 修改/etc/hosts文件，是192.168.0.21对应多个hostanme，改为
192.168.0.21 test
192.168.0.21 sdr-0006
192.168.0.21 test
5.4 清理21节点数据库
gs_uninstall --delete-data -L
rm -rf /data2/lzf_sdr/omm; rm -rf ENVFILE
5.5 在19节点执行扩容，预期应该失败
结果：失败
5.6 修改om代码，重新编译，并且替换OM安装包
替换OM的两个文件，重新解压om包，解压之后会自动覆盖之前的script目录
5.7 拷贝xml文件（原来的xml不要删），清理掉删除21节点信息
在主节点重新执行preinstall，-X指定的为新的xml文件。通过preinstall将之前安装的OM脚本替换掉
结果：执行成功
5.8 执行扩容，执行成功
2）重新安装
只需替换掉安装包中OM包，安装之后进行扩容测试即可
6.验证无问题之后发给客户
二、bclinux系统安装openGauss失败
安装包发给客户之后，客户环境进行验证，客户反映执行安装仍然失败
1、报错如下：
问题如下：在扩容节点上找不到文件ENVFILE；
扩容节点执行预安装gs_preinstall失败
2、问题定位
2.1 在扩容节点上找不到文件ENVFILE问题：
2.1.1 首先查看预安装命令以及报错的路径是否正常，常看之后无异常
2.1.2 查看代码发现，在预安装失败后，失败节点会自动清理环境变量问题，所以该报错是预安装失败导致
2.2 预安装失败问题
2.2.1 根据图中报错，会将结果重定向到gs_local.log日志中，查看该日志，未发现异常（主节点日志正常，待扩容节点无该日志生成）
2.2.2 查看gs_expersion扩容工具的日志，在$GAUSSLOG/om路径下，在该日志下发现异常，报错：不支持bclinux系统安装（忘记截图了...）
2.2.3 之前帮助客户定位过该问题，给客户提供过安装包以及修改方式；咨询客户对接的同事，发现安装时是手动改的om脚本，没有把修改同步到安装包里面（之前对接的客户同事离职了，新同事按照文档改的）。而在扩容的时候，om工具会向扩容节点将安装包传到扩容节点（不是发送的他们修改后的脚本，是发送的安装包），因此确认是该问题导致。
2.2.4 重新编译OM，将两个问题的修改都同步到6.0.0LTS版本中，验证后发给客户。
3、其他问题
其间还出现了一个问题，缺少.so文件
3.1 查看是否存在该文件
find / -name libffi.so*
结果如下：
3.2 该问题为.so文件的版本不一致，查找资料发现libffi.so.7与libffi.so.6兼容，因此可以创建软连接解决
ln -s /usr/lib/libffi.so.7 /usr/lib/libffi.so.6
三、扩容后扩容节点启动失败问题
客户验证，之前的问题并未报错，但是在最后一步拉起扩容节点的时候，拉起失败
1、报错如下
2、问题定位
2.1 查看数据库状态，如下
初步确认该节点cm_server和数据库进程启动都存在问题
2.2 到对应节点上面进行查看
ps ux
查看该节点进程启动情况，发现cm相关的cm_agent、cm_server、om_monitor进程以及数据库进程都没有，因此需要查看om_monitor日志
前情提要：数据库启动顺序如下
定时任务 -> om_monitor -> cm_agent -> cm_server、数据库、自定义资源
（crontab -l查看定位任务无异常，因此需要查看om_monitor日志）
om_monitor日志中找到报错（忘记截图了，截一下对应的代码），发现是设置打开的最大句柄数不够，最小需要640000：
查看命令
ulimit -n 或 ulimit -a
2.3 解决方法
修改/etc/security/limits.conf 文件，进行配置
omm soft as unlimited
omm hard as unlimited
omm soft nproc unlimited
omm hard nproc unlimited
修改之后，该节点会自动拉起（需要等待一段时间，定时任务1分钟一次拉起om_monitor）
问题总结
至此，该问题终于解决。（o(╥﹏╥)o）
