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

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 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];thenmkdirp{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 代码解读
目录
打赏
0
0
0
0
44
分享
相关文章
基于 ChunkServer 的数据备份与恢复方案
【8月更文第30天】在分布式文件系统中,数据的安全性和持久性是至关重要的。为了应对可能发生的硬件故障、网络中断等问题,需要有一套完善的备份与恢复方案。本文将详细介绍如何设计和实现一套基于 ChunkServer 的数据备份与恢复流程,确保数据的完整性和持久性。
116 0
将旧集群的数据备份迁移到新集群。
将旧集群的数据备份迁移到新集群。
166 1
6月27日阿里云故障说明
6月27日下午,我们在运维上的一个操作失误,导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题。故障于北京时间2018年6月27日16:21左右开始,16:50分开始陆续恢复。对于这次故障,没有借口,我们不能也不该出现这样的失误!我们将认真复盘改进自动化运维技术和发布验证流程,敬畏每一行代码,敬畏每一份托付。
10841 2
【YashanDB 知识库】OM 仲裁节点故障后手工切换方案和 yasom 仲裁重新部署后重新纳管数据库集群方案
本文介绍了一主一备数据库集群的部署步骤。首先在OM节点上传并解压软件包至指定路径,随后通过调整安装参数、执行安装和集群部署完成数据库设置。接着,在主备节点分别配置环境变量,并查看数据库状态以确认安装成功。最后,针对OM仲裁故障提供了手动切换方案,包括构造故障场景、关闭自动切换开关及使用SQL命令进行主备切换,确保系统高可用性。
【VSAN数据恢复】VSAN集群节点数据迁移失败的数据恢复案例
VSAN存储是一个对象存储,以文件系统呈现给在vSphere主机上。这个对象存储服务会从VSAN集群中的每台主机上加载卷,将卷展现为单一的、在所有节点上都可见的分布式共享数据存储。 对于虚拟机来说,只有一个数据存储,这个分布式数据存储来自VSAN集群中每一台vSphere主机上的存储空间,通过磁盘组进行配置,在单独的存储中存放所有的虚拟机文件。这种数据存储方式比较安全,当闪存盘或者容量盘出现故障的时候,数据会向其他节点转移,在转移过程中有可能出现故障。
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380服务器中3块SAS硬盘组建了一组raid。 服务器故障: RAID中多块磁盘出现故障离线导致RAID瘫痪,其中一块硬盘状态指示灯显示红色。服务器上运行的数据库在D分区,备份文件存放在E分区。由于RAID瘫痪,D分区无法识别,E分区可识别但是拷贝文件报错。管理员重启服务器,导致RAID中先离线的硬盘上线并开始同步数据,同步没有完成管理员意识到有问题,于是就强制关机了,之后就没有再动过服务器。
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
服务器数据恢复-raid5故障导致上层oracle数据库故障的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由24块FC硬盘组建的raid5磁盘阵列,linux操作系统+ext3文件系统,服务器上层部署有oracle数据库。 服务器故障&检测: raid5阵列中有两块硬盘出现故障掉线,导致服务器上层卷无法挂载,oracle数据库无法正常使用。 通过管理后台查看服务器中硬盘的状态,显示有两块硬盘处于离线状态。
服务器数据恢复—如何预防服务器故障?发生故障后如何恢复服务器数据?
服务器常见故障: 硬件故障:磁盘、板卡、电源故障等。 软件故障:操作系统崩溃、程序运行错误等。 入侵破坏:加密、删除服务数据等。 不可控力:浸水、火烧、倒塌等。 误操作:格式化、删除、覆盖等。

数据库

+关注