某客户多节点磁盘故障集群恢复

• 背景介绍：
  现场集群为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} ];then
	mkdir -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','performance_schema','gbase','gclusterdb','gctmpdb'); "  >  ${file}
if [ -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 -l`
		if [ $flag > 0 ]; then
			echo ${tbname} >> ${basedir}/checksumErrTablist.txt
		else   
			echo ${tbname} >> ${basedir}/checksumOkTablist.txt
		fi
		cnt=`gncli -ugbase -pgbase -Nse"select count(*) from ${tbname} where rowid%65536=1;"`
		if [ $? = 0 ]; then
			echo  ${tbname}_${cnt}>>${basedir}/scanRowidOkTablist.txt
		else
			echo  ${tbname}>>${basedir}/scanRowidErrTablist.txt
		fi
	done <  ${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，至此本次故障处理完成.