GBase 8a发生主副本都损坏状态为1的几种原因

本文根据实际项目情况,介绍几种GBase 8a数据库集群,主副本都损坏或标志datastate为1的原因。

DDL操作

比如加列,删表等。集群默认机制是只要任何一个管理节点成功,就视同成功,其它所有不成功的管理和计算节点,记录event并后续尝试。

如此也就造成了有出现主副本均设置为1的情况。

但此类问题,只要DDL重试成功了,会自动恢复。具体的原因需要看gcrecovery.log里,恢复日志的内容。

一般来说,DDL报错出现event,除非文件系统及硬件损坏,更常见的是有查询在使用这个表,导致ddl无法拿到表锁,超过参数table_lock_wait_timeout后,gcluster local如果50s没有持到单机锁,就会报错记ddlevent(gnode层也是这个逻辑)。

同时出现文件操作类故障

比如最大文件数量设置过小(1024),导致多个节点同时发生文件或网络无法操作(too many open file),调度节点也无法完成回滚等操作,只能全部设置不一致标记。

主备文件系统全部损坏

机房大面积断电,某品牌服务器,有超过1/3的机器出现文件系统故障,从message能看到报错信息。现场是1+2副本,依然有多组主备全部损坏,最终文件系统重做,这部分数据丢失。

一份数据标识不一致后,副本出现不可自主恢复故障

1+1副本,由于网络超时,一台机器的分片被设置为不一致状态,数据库会自动从副本同步。

在等待同步,或者正在同步过程中,副本节点出现不可自主恢复性故障,比如磁盘满了、文件系统损坏,宕机或断电出现数据没有正确刷到磁盘上(虚拟机或云环境常见,物理机RAID卡带电池没发现)等情况,集群记录了event,导致副本的数据也不可访问。

处理方案

修复好=数据完全恢复,与故障前无任何差别,不是能读能写就算修复好了。

可修复的故障

包括网络不同,宕机后自动恢复,参数类问题修改后重启等。

在gnode层查询主备分片哪个可用, GBase 8a数据库如何查看数据或数据文件是否正常

将可用的(包括你人工选择认为更准确的),清理掉该IP对应的event, 数据库会自动向另一个同步。

不可修复的故障

包括文件系统不可完全恢复,硬件丢失或损坏。

主副本都修复好了

参考前面可修复故障,选择其中一个为好的,清掉event,让数据库自动或手工同步。

主副本部分能修复好

将好的节点event清理掉,故障节点更换新的服务器,做节点替换。

主副本全部永久损坏,无法修复或修复后数据丢失

1、集群现有工具无法自动恢复,只有重建集群,所有数据丢失。

2、未损坏的节点的计算层(gnode)依然可以查询,可以手工将每个计算节点的每张表的数据导出为文本文件,新集群搭建完成后将数据加载导入。

3、如果修复后的节点,只是数据丢失,表结构还在,可以将主副本的数据都truncate掉,变成空表,丢失这个分片的数据。清理掉event。

参考