GBase 8a在执行dml,ddl等数据变动业务时，为了避免发起节点出现故障，提供了failover机制来清理残余信息，保证集群一致性。针对一些特殊情况，特别是早期的版本，可能存在某些情况需要强行清理的情况。结合强行释放锁的操作，可以清理指定SQL占用的资源。本文提供的方案请慎重使用。
一般要配合锁的清理：GBase 8a查看和强行释放SQL持有锁的方法
目录导航
参考
GBase 8a 集群的 failover和event的区别
GBase 8a不释放锁导致的SQL一直checking permissions卡住
查看failover方法
在数据库操作系统dbauser下(一般是gbase)执行 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 id | failover 的唯一标识，64 位数字。 |
| database | 数据库名。 |
| table | 表名 |
| scn | scn 号。 |
| type | 类型，包括ddl/dml/rebalance。 |
| create time | 创建 failover 信息的时间 |
| state | failover 对应的状态数字： 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 number | failover 的接管次数，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].
总结
本文方法只适合于非正常情况下的临时操作，特别是针对一些老版本集群，请慎重使用。