背景介绍：
现场集群为6个节点（3coor+6data，一主一备），客户巡检时发现集群多个节点raid存在磁盘故障，更换磁盘后其中3个节点无法挂载或者文件系统无法访问（后了解为工程师操作失误导致），其中一个节点3、5修复失败，数据完全丢失，节点6由存储专家恢复到windows服务器（整个/opt目录）！
处理过程：
1、准备一台新服务器，用于检查恢复到windows的数据是否可用。由于服务器资源不足，考虑到节点5数据已完全格式化，现场直接修改节点5、节点6交换IP后，将节点6恢复数据拷贝到节点5！
2、检查恢复目录挂载情况，修改目录属组
3、启动gbase服务gcluster _services gbase start ,或者/opt/gnode/server/bin/gbase start
启动失败，排查发现，目录恢复拷贝后，数据库目录权限完全改变，和正常节点逐一核对文件和目录权限，并调整
find /opt/gnode -type d -exec ls -dl {} \;
find /opt/gnode -type d -exec ls -fl {} \;
.…
4、启动正常，查看节点库表完整性
show databases;
select table_schema,table_name from information_schema.tables;
通过脚本确认表数据文件是否完整(进行全表扫描，并对表数据文件进行checksum校验)，脚本参考如下：
checkTabIntegrity.sh
!/bin/bash
file=/opt/checksum/tblist.txt
basedir=/opt/checksum
if [ ! -d basedir];thenmkdir−p{basedir}/log
fi
gncli -ugbase -pgbase -Nse "select table_schema||'.'||table_namefrom information_schema.tables where TABLE_TYPE='BASE TABLE' and table_schema not in('information_schema','performanceschema','gbase','gclusterdb','gctmpdb'); " > fileif[−z{file} ]; then
while read tbname
do
checksum ${tbname%%.} ${tbname##.} >basedir/log/{tbname%%.*} ${tbname##.} .log
flag=`cat basedir/log/{tbname%%.} _${tbname##.} .log | grep '[CHECKSUM_ERROR]' | wc -lif [ $flag > 0 ]; then echo ${tbname} >> ${basedir}/checksumErrTablist.txt else echo ${tbname} >> ${basedir}/checksumOkTablist.txt fi cnt=gncli -ugbase -pgbase -Nse"select count() from tbnamewhererowid? = 0 ]; then
echo {tbname}_{cnt}>>basedir/scanRowidOkTablist.txtelseecho{tbname}>>basedir/scanRowidErrTablist.txtfidone<{file}
fi
说明：
对于rowid扫描通过的表，基本可以确认数据可以正常查询，如果checksum校验异常，gbase通过同步事件，即gc_sync_client命令进行自动同步恢复时会报错CHECKSUM_ERROR，导致数据文件同步恢复失败，需尝试scp 分片文件手动同步，refresh table tablename后进行测试，如果不成功，只能考虑数据导出或者重建表；
对于rowid扫描失败，checksum则必然出现错误，则说明表数据文件有丢失或者损坏，导致数据丢失，可根据需要查询确认可恢复的数据量（该过程比较繁琐）；
checksum异常，说明文件恢复前后不一致，并不一定说明表数据丢失，只是正常的gc_sync_client事件进程无法正常同步恢复，需手动scp恢复确认；
只有当checksum和全表扫描通过才能基本确认恢复的表数据是完整的，并且可以通过事件自动同步恢复。
5、最终扫描完成后发现部分表主备分片都损坏，对于这部分分片损坏的表，向客户说明，经客户同意后重建损坏分片,保留正常分片数据。
6、最后采用节点替换方式恢复节点3和节点5，至此本次故障处理完成.
AI 代码解读
