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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 Tair(兼容Redis),内存型 2GB
简介: gbase 数据 某客户多节点磁盘故障集群恢复

背景介绍:
现场集群为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','performanceschema','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 -lif [ $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,至此本次故障处理完成.
相关文章
|
5月前
|
存储 运维 Python
基于 ChunkServer 的数据备份与恢复方案
【8月更文第30天】在分布式文件系统中,数据的安全性和持久性是至关重要的。为了应对可能发生的硬件故障、网络中断等问题,需要有一套完善的备份与恢复方案。本文将详细介绍如何设计和实现一套基于 ChunkServer 的数据备份与恢复流程,确保数据的完整性和持久性。
65 0
|
运维 测试技术
6月27日阿里云故障说明
6月27日下午,我们在运维上的一个操作失误,导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题。故障于北京时间2018年6月27日16:21左右开始,16:50分开始陆续恢复。对于这次故障,没有借口,我们不能也不该出现这样的失误!我们将认真复盘改进自动化运维技术和发布验证流程,敬畏每一行代码,敬畏每一份托付。
10799 2
|
8月前
|
存储 缓存 安全
【VSAN数据恢复】VSAN集群节点数据迁移失败的数据恢复案例
VSAN存储是一个对象存储,以文件系统呈现给在vSphere主机上。这个对象存储服务会从VSAN集群中的每台主机上加载卷,将卷展现为单一的、在所有节点上都可见的分布式共享数据存储。 对于虚拟机来说,只有一个数据存储,这个分布式数据存储来自VSAN集群中每一台vSphere主机上的存储空间,通过磁盘组进行配置,在单独的存储中存放所有的虚拟机文件。这种数据存储方式比较安全,当闪存盘或者容量盘出现故障的时候,数据会向其他节点转移,在转移过程中有可能出现故障。
|
7月前
|
数据挖掘 数据库
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380服务器中3块SAS硬盘组建了一组raid。 服务器故障: RAID中多块磁盘出现故障离线导致RAID瘫痪,其中一块硬盘状态指示灯显示红色。服务器上运行的数据库在D分区,备份文件存放在E分区。由于RAID瘫痪,D分区无法识别,E分区可识别但是拷贝文件报错。管理员重启服务器,导致RAID中先离线的硬盘上线并开始同步数据,同步没有完成管理员意识到有问题,于是就强制关机了,之后就没有再动过服务器。
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
|
6月前
|
存储 运维 监控
|
8月前
|
运维 Oracle 关系型数据库
服务器数据恢复-raid5故障导致上层oracle数据库故障的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由24块FC硬盘组建的raid5磁盘阵列,linux操作系统+ext3文件系统,服务器上层部署有oracle数据库。 服务器故障&检测: raid5阵列中有两块硬盘出现故障掉线,导致服务器上层卷无法挂载,oracle数据库无法正常使用。 通过管理后台查看服务器中硬盘的状态,显示有两块硬盘处于离线状态。
|
存储 数据挖掘
Vsan数据恢复—vSAN逻辑架构出现故障的数据恢复案例
一台存储采用了VSAN分布式存储架构,存储内共有24块硬盘存储数据。 这台vSAN存储设备关机重启。经过数据恢复工程师的检测,发现vSAN逻辑架构出现故障,上层虚拟机瘫痪,存储内的数据丢失。
|
定位技术 网络架构 UED
主从副本架构可能存在风险
主从副本架构可能存在风险
158 0
|
存储 运维 NoSQL
数据复制系统设计(3)-配置新的从节点及故障切换过程详解
1.3 配置新的从节点 有时需考虑新增一个从节点: 提高容错能力 或替换失败的副本节点
148 0
|
监控 容灾 安全
系统总出故障怎么办?
系统总出故障怎么办?
114 0