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

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 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 的数据备份与恢复流程,确保数据的完整性和持久性。
68 0
|
5月前
|
存储 运维 负载均衡
构建高可用的 ChunkServer 系统
【8月更文第30天】在分布式文件系统中,ChunkServer(也称为 DataNode)负责存储文件的数据块(chunks)。为了保证系统的高可用性和数据冗余,需要设计一种可靠的 ChunkServer 部署方案。本文将探讨如何设计和实现一个高可用的 ChunkServer 系统,并通过具体的代码示例来展示其实现细节。
87 0
|
5月前
|
运维 监控 定位技术
故障转移和自动恢复
故障转移和自动恢复
171 1
|
8月前
|
存储 缓存 安全
【VSAN数据恢复】VSAN集群节点数据迁移失败的数据恢复案例
VSAN存储是一个对象存储,以文件系统呈现给在vSphere主机上。这个对象存储服务会从VSAN集群中的每台主机上加载卷,将卷展现为单一的、在所有节点上都可见的分布式共享数据存储。 对于虚拟机来说,只有一个数据存储,这个分布式数据存储来自VSAN集群中每一台vSphere主机上的存储空间,通过磁盘组进行配置,在单独的存储中存放所有的虚拟机文件。这种数据存储方式比较安全,当闪存盘或者容量盘出现故障的时候,数据会向其他节点转移,在转移过程中有可能出现故障。
|
6月前
|
存储 运维 监控
|
存储 数据挖掘
Vsan数据恢复—vSAN逻辑架构出现故障的数据恢复案例
一台存储采用了VSAN分布式存储架构,存储内共有24块硬盘存储数据。 这台vSAN存储设备关机重启。经过数据恢复工程师的检测,发现vSAN逻辑架构出现故障,上层虚拟机瘫痪,存储内的数据丢失。
|
定位技术 网络架构 UED
主从副本架构可能存在风险
主从副本架构可能存在风险
160 0
|
存储 运维 NoSQL
数据复制系统设计(3)-配置新的从节点及故障切换过程详解
1.3 配置新的从节点 有时需考虑新增一个从节点: 提高容错能力 或替换失败的副本节点
151 0
|
Kubernetes 网络安全 调度
关于K8s中工作节点扩容、隔离、恢复的一些笔记
写在前面 分享一些K8s中Node扩容、隔离、恢复的笔记 博文主要是通过 kubeadm做节点扩容的一个Demo 理解不足小伙伴帮忙指正
341 0
|
消息中间件 JSON 运维
【kafka运维】分区副本重分配、数据迁移、副本扩缩容 (附教学视频)
【kafka运维】分区副本重分配、数据迁移、副本扩缩容 (附教学视频)
【kafka运维】分区副本重分配、数据迁移、副本扩缩容 (附教学视频)