GBase 8a在执行时。为避免并发冲突保证一致性,会持有一些锁来保证自己需要的资源在执行期间不会出现问题。锁在SQL执行完毕后会自动释放掉。在某些特殊场景下,特别是一些老版本集群,出现需要强行释放掉锁的需求,比如SQL长时间无法结束,而该SQL持有的锁又导致其它的SQL无法正常运行,同时环境又不能重启节点服务时,可以考虑本文的方法强行释放SQL持有的锁。
对于DDL,DML类的SQL,一般要配合failover清理
构造锁的测试场景
如下通过lock table语句构造了一个持有锁的SQL场景,连接节点为201。
集群版本:8.6.2.43-R33.129391
[root@rh6-1 ~]# gcadmin
CLUSTER STATE: ACTIVE
CLUSTER MODE: NORMAL
=================================================================
| GBASE COORDINATOR CLUSTER INFORMATION |
=================================================================
| NodeName | IpAddress |gcware |gcluster |DataState |
-----------------------------------------------------------------
| coordinator1 | 10.0.2.201 | OPEN | OPEN | 0 |
-----------------------------------------------------------------
=============================================================
| GBASE DATA CLUSTER INFORMATION |
=============================================================
|NodeName | IpAddress |gnode |syncserver |DataState |
-------------------------------------------------------------
| node1 | 10.0.2.201 | OPEN | OPEN | 0 |
-------------------------------------------------------------
| node2 | 10.0.2.202 | OPEN | OPEN | 0 |
-------------------------------------------------------------
gbase> lock table t1 write;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
gbase> show processlist;
+-----+-----------------+-----------+--------+---------+-------+-----------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+-----------------+-----------+--------+---------+-------+-----------------------------+------------------+
| 1 | event_scheduler | localhost | NULL | Daemon | 42262 | Waiting for next activation | NULL |
| 258 | root | localhost | testdb | Query | 0 | NULL | show processlist |
+-----+-----------------+-----------+--------+---------+-------+-----------------------------+------------------+
2 rows in set (Elapsed: 00:00:00.00)
查看SQL持有的锁
通过SQL查看锁
可以通过show detail processlist查看SQL当前持有的锁,需要的锁等信息。详情请参考