南大通用GBase 8a查看和清理故障恢复状态Failover的方法

GBase 8a在执行dml,ddl等数据变动业务时,为了避免发起节点出现故障,提供了failover机制来清理残余信息,保证集群一致性。针对一些特殊情况,特别是早期的版本,可能存在某些情况需要强行清理的情况。结合强行释放锁的操作,可以清理指定SQL占用的资源。本文提供的方案请慎重使用。

一般要配合锁的清理:GBase 8a查看和强行释放SQL持有锁的方法

参考

GBase 8a 集群的 failover和event的区别
GBase 8a不释放锁导致的SQL一直checking permissions卡住

查看failover方法

在数据库操作系统dbauser下(一般是gbase)执行 gcadmin showfailover

gcadmin showfailover
[gbase@rh6-1 ubas]$ gcadmin showfailover
+===================================================================================================================================================================================================+
|                                                                                          GCLUSTER FAILOVER                                                                                        |
+===================================================================================================================================================================================================+
+------------+------------+-----------+------------+-----------+------------------+-------+-------------------------------------------+-------------------------------------------+-----------------+
| commit  id |  database  |   table   |    scn     |   type    |   create  time   | state |              original node                |               takeover node               | takeover number |
+------------+------------+-----------+------------+-----------+------------------+-------+-------------------------------------------+-------------------------------------------+-----------------+
|  2359298   |   testdb   |    tt1    |  2359299   |    dml    |  20220218094731  |   3   |                10.0.2.201                 |                                           |        0        |
+------------+------------+-----------+------------+-----------+------------------+-------+-------------------------------------------+-------------------------------------------+-----------------+

如果当前没有failover信息,则显示

[gbase@rh6-1 ubas]$ gcadmin showfailover

gcadmin showfailover: no gcluster failover information now

[gbase@rh6-1 ubas]$

Failover输出信息解析

标签说明
commit idfailover 的唯一标识,64 位数字。
database数据库名。
table表名
scnscn 号。
type类型,包括ddl/dml/rebalance。
create time创建 failover 信息的时间
statefailover 对应的状态数字:
0: init初始化
1: add_res添加集群锁
2: set_info设置 failover 信息(触发了failover,有其它节点接管了,处理中)
3 :set_status设置分片状态(最常见的信息)
4 :set_rebalance_info设置 rebalance 信息
5 :set_rebalance_status设置 rebalance 状态
original node发起节点
takeover node当前接管节点,如果没有发生接管则显示为空
takeover numberfailover 的接管次数,gcware 通知 gcluster 接管后这个值就加1。

强行清理failover的方法

警告:FAILOVER机制是数据库内为了确保一致性的,如果强行清理,可能导致数据主副本不一致,数据无法读取等异常情况。

如果某个操作,已经人工确认没有问题(各个分片的数据,当前都是可以查询,没有主副本数据行数,表结构不一致等异常情况,或者已经决定删除重建该表时),只是为了删除数据库的内部重试,才需要强制清理failover。常见于某些长时间没有kill掉的DML、DDL类SQL, 但又不能通过重启一个节点解决,因为failover会被自动接管,后台继续执行。

再次提醒,一定确认安全,才可以做这个操作。

如下红色是手工输入的部分,其中的gcware.deletefailoverforce的参数是commit it, 就是show failover的第一个标签的内容。

[gbase@rh6-1 ubas]$ python

Python 2.6.6 (r266:84292, Oct 12 2012, 14:23:48)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gcware
>>> gcware.deletefailoverforce(2359298)

0
>>> quit()
[gbase@rh6-1 ubas]$

如果清理成功,返回0. 再次运行gcadmin showfailover确认其消失。

如果commit id不存在,则报错

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python_gcware/gcware.py", line 195, in deletefailoverforce
    return _gcware.deletefailoverforce(commitid);
Exception: deletefailoverforce: gcLckDeleteFailoverForce Error: [49]->[GC_AIS_ERR_NOT_EXIST_IN_SERVICE].

总结

本文方法只适合于非正常情况下的临时操作,特别是针对一些老版本集群,请慎重使用。