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

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介: 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,至此本次故障处理完成.
相关文章
|
数据采集 C语言
单片机开发之ADC0808/9信号采集
本文主要介绍了单片机开发之ADC0808/9信号采集
871 0
单片机开发之ADC0808/9信号采集
|
XML Java BI
JXLS 实现复杂数据报表的 导入导出功能
JXLS 实现复杂数据报表的 导入导出功能
1572 0
JXLS 实现复杂数据报表的 导入导出功能
使用postman测试接口时需要先登录怎么办
使用postman测试接口时需要先登录怎么办
3949 0
使用postman测试接口时需要先登录怎么办
|
5月前
|
数据采集 人工智能 搜索推荐
完蛋啦,爆火Github项目,用微信聊天记录打造专属AI数字分身,我都不敢相信!!
WeClone 是一个基于微信或 Telegram 聊天记录微调大语言模型的开源项目,可打造专属 AI 数字分身。支持文本、图片等多模态数据,具备语言风格迁移和语音克隆功能,实现“说话像你”的AI角色。项目提供完整训练流程,支持本地部署,保护隐私,适用于个人数字分身、纪念机器人、客服助手等场景。
806 0
|
数据采集 存储 JSON
基于qwen2.5开源大模型 处理 环境、社会及治理 相关资料
基于Qwen-2.5开源大模型,本方案旨在处理环境、社会及治理(ESG)相关资料,涵盖数据分析、决策辅助和报告生成等任务。方案详细描述了从数据准备、模型功能设计到部署优化的全过程,并列举了多种应用场景,如企业合规审查、投资评估支持等,旨在为企业、机构和研究者提供全面的ESG资料处理解决方案。
590 0
|
存储 分布式计算 Hadoop
Hadoop的HDFS数据均衡
【6月更文挑战第13天】
707 3
QObject的setUserData和setProperty——Qt
QObject的setUserData和setProperty——Qt
465 0
|
存储 SQL 数据库
【教程】宝塔default.db占用空间几十g解决方法|宝塔占用磁盘空间特别大解决方法|宝塔磁盘被占满怎么清理
在宝塔面板7.9.0中,用户发现数据盘持续占满,通过`folder size`工具发现`BtSoft\panel\data`下的`default.db`和`system.db`文件占用大量空间,尤其是`default.db`。由于这是SQLite数据库文件,用户使用SQLite Developer打开并发现`boce_list`表包含大量访问记录,可能是宝塔面板未定期清理所致。用户直接清空表后,使用`VACUUM`命令整理数据库以回收空间,成功将`default.db`从18G减至3M,解决了磁盘占用问题。
|
机器学习/深度学习 存储 算法
基于YOLOv8深度学习的农作物幼苗与杂草检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测
基于YOLOv8深度学习的农作物幼苗与杂草检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测