在GBase 8c数据库中，truncate操作用于快速删除表中的所有数据，但保留表结构。通常情况下，truncate操作执行速度较快，但在一些特殊情况下，可能会出现truncate卡住的现象。本文将介绍GBase 8c truncate卡住的故障问题背景，以便读者了解并解决此类问题。

此类问题可能是由以下原因导致的：

  • 锁等待：在进行truncate操作时，如果有其他事务正在访问表，可能会导致锁等待。这种情况下，需要检查是否有长时间未提交的事务，或者是否存在死锁现象。
  • 系统资源竞争：当系统资源（如CPU、内存、磁盘IO等）竞争激烈时，truncate操作可能无法获得足够的资源来执行，从而导致卡住。这种情况下，需要检查系统资源使用情况，优化资源配置或扩容。
  • 网络问题：GBase 8c数据库集群各个节点之间需要进行通信。如果网络出现问题，可能导致truncate操作无法正常执行。这种情况下，需要检查网络状况，确保网络畅通。
  • 数据库参数设置不当：GBase 8c数据库中有一些参数会影响到truncate操作的执行，如并发度、事务隔离级别等。如果这些参数设置不当，可能导致truncate操作卡住。这种情况下，需要检查数据库参数设置，进行合理调整。
  • 存储引擎问题：GBase 8c支持多种存储引擎，不同存储引擎在处理truncate操作时可能存在差异。如果使用的存储引擎存在bug或者性能问题，可能导致truncate操作卡住。这种情况下，可以尝试切换存储引擎，或者升级存储引擎版本。

下面我们通过一个简单的测试例子，来模拟truncate被卡住的现场问题。

（1）会话一：手动开启事务，查询表t1，不做commit。

begin;
select *from t1;

例如返回如下信息：

id | c1
---+---
 1 | 1
(1 row)

（2）会话二：执行truncate表t1，命令被卡住。

truncate table t1;

查询锁信息

select * from pgxc_relation_locks where relname = ‘t1’;

例如返回如下信息：

南大通用GBase 8c TRUNCATE卡死故障分析_系统资源

理论解析两个会话过程应为：

  • 会话一

mode：AccessShareLock，select命令执行时会在表上申请一个AccessShareLock，由于是在事务中执行的查询，所以该锁会一直持续到事务结束。

granted：hold lock，持有锁状态。

  • 会话二

mode：AccessExclusiveLock，ACCESS EXCLUSIVE锁会与所有锁冲突，通常情况下DDL语句会申请改类型锁。

granted：acquire lock，申请锁状态。

（3）查询锁信息

select * from pgxc_locks;

例如返回如下信息：

南大通用GBase 8c TRUNCATE卡死故障分析_存储引擎_02

根据上图，可以根据查询结果直观看出：会话二被会话一阻塞。block_query可以看出阻塞的语句是会话一执行的查询，且block_pid是会话一的pid。

这种情况下，解决truncate被卡住的方法是结束会话一，执行命令：

select pg_terminate_backend(140290346104576);

总之，GBase 8c truncate卡住的故障问题可能由多种原因导致，需要根据具体情况进行分析和解决。在解决此类问题时，可以结合数据库日志、系统资源监控等信息，找出问题根源并进行修复。同时，也可以通过优化数据库配置、调整系统资源分配等方式，提高GBase 8c数据库的性能和稳定性。