数据库工程师在部署KingbaseES高可用共享集群过程时，有时候会遇到文件损坏，系统无法启动的问题。
作为金仓数据库工程师的我在最近一次客户现场支持过程中，也遇到了同样的问题，经过多轮排查，结合丰富的产品手册，我最终找到了快速解决问题的路径。在这里我将经验分享出来，以便更多金仓数据库使用者查看。
该客户此前购买的国际巨头Oracle的数据库产品，现需要替换为金仓数据库产品。根据现场需要，我前往项目所在地帮助客户部署金仓KingbaseES高可用共享集群。
第一步：配置时钟同步
时钟同步可以采用ntpd同步，也可通过
timesyncd;
采用timesyncd，需要修改
/etc/systemd/timesyncd.conf， 配置时钟同步客户端，通过timedatectl管理;
查看命令如下：
timedatectl show-timesync;
第二步：配置共享磁盘
由于KingbaseES高可用共享集群使用多节点共享磁盘，因此需要采用DAS、NAS、SAN等存储。本次采用FC磁盘阵列作为共享磁盘，FC磁盘整阵列就是光纤磁盘阵列;
共享磁盘客户端制作多路径绑定，可以提高磁盘的可用性，有效防止磁盘故障、网络故障导致的数据丢失或损坏;
首先在配置安装multipathd时，修改/etc/multipath.conf(具体配置参见其他文章，不是本文重点)，systemctl restart multipathd启动;
在FC磁盘整列服务端划分磁盘，在磁盘客户端(也就是数据库服务端)，执行rescan-scsi-bus.sh后，在主机群可以找到新创建的盘;
这时候进行多路径聚合multipath –v2;
查看多路径绑定multipath –ll。
第三步：配置udev规则，固定磁盘名
01)udevadm info --query=all --name=/dev/dm-0
02)vim /etc/udev/rule.d/60-scsi.rules
03)ENV{ID_SERAIL}=="...",ENV{DM_WWN}=="..."RUN+="/bin/sh -c 'mknod/dev/chmpatha b $major $minor; chmod 0644 /dev/chmpatha; rm -f /dev/block/$major:$minor; ln -s /dev/chmpatha /dev/block/$major:$ninor'"
第四步：业务系统测试
安装完成后，需要进行简单功能测试和可用性测试，以便将问题尽早解决掉。首先我和技服进行了down机、断掉业务网和管理网、制造进程僵死等故障测试。
问题来了。在进行断网的测试中，发现数据库一直在不停地切换节点。查看日志，发现是文件系统损坏导致的数据库无法启动。
采用fsck的方法进行修复，
fsck -a /dev/mapper/mpatha
但是未能修复!客户表明2天内必须解决。
再次梳理日志，KingbaseES集群组件在报文件系统异常前，没有任何异常日志。在KingbaseES文件系统异常前，仅有kenel相关日志。根据一般经验，怀疑可能是双挂导致的磁盘损坏。
第五步：问题排查
继续分析集群各节点的挂载记录，发现一些mpatha磁盘在系统重启后，在另一节点莫名其妙的挂载上了，目前推断可能是双挂导致的文件系统损坏，但是无法继续敲定重启为何导致双挂?
没有办法，只有将磁盘重新格式化，继续进行复现测试，终于抓住了问题，在异常重启后的机器上出现一条挂载记录：
/dev/mappper/mpatha 1007G 146M 956G 1%/media/root/9g0oc559-2d0a-4e88-a1e7-1b1badc9a7
实际上磁盘在另外节点正在被数据库管理进程使用，显然是双挂，那么这条挂载记录怎么来的?
重新思考操作的每一步骤，最终发现了问题的根本原因：
第六步：问题根因
没错，是操作系统的自动挂载导致的双挂问题。
于是我们将"自动挂载"选项去掉，同时为了保险起见，将数据库服务端所在节点的图形界面关掉，在图形模式下使用如下命令可以切换到纯命令行模式：
systemctl isolate multi-user.target
如果需要每次重启都进入纯命令行模式，可以使用如下命令：
systemctl set-default multi-user.target
彻夜鏖战，终于解决了文件系统损坏的问题，让系统恢复了正常，获得客户高度认可，我内心还是很高兴的。
小结
如果服务器均部署在国产图形化Linux操作系统，在图形化界面，会默认设置自动挂载。在自动挂载时数据库实例盘双挂，会导致文件系统损坏。之后，将服务器“自动挂载”取消，同时使用命令“systemctl set-default multi-user.target ”设置默认为命令界面，防止误操作。这样就能快速恢复系统正常运行。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
