锁介绍

锁是一种数据库的信号量管理机制，作用是保证SQL执行上不同事务的隔离性。

事务的四个特性（ACID）：

• Atomicity：原子性，要求一个包含多个操作的事务的结果，要么全部提交，要么全部不提交；
• Consistency：一致性，要求事务提交后，数据库从一个一致状态转化到另一个一致状态，或事务失败回滚后，数据库恢复到事务执行前的一致状态。这里举的最多的例子就是多个用户银行转账，假设这些用户的总余额是500元，那么不管如何转账，有多少并发事务执行，结束后总余额应该还是500元。
• Isolation：隔离性，要求多个事务并发执行时，一个事务不会看到其他事务的中间结果。
• Durability：持久性，要求事务提交后，该事务对数据库的更改就持久化保存在数据库中；

当一个query发起时，在Hologres中其经过的链路如下：Frontend解析SQL，Query Engine生成执行计划等，然后Storage Engine读取数据，整个链路的锁有两种：

• FE Locks(前端锁)：Frontend为接入层，兼容Postgres协议，因此锁也会兼容Postgres的部分锁，主要用来管理FE元数据信息。
• BE Locks(后端锁）：Backend是指Query Engine和Fixed Plan，将会享有Hologres自带的锁，主要用于管理Storage Engine的schema和数据

下面将会对Hologres两种锁的具体介绍。

FE Locks

Hologres接入层Frontend兼容PostgreSQL，因此在接入层的锁与PG兼容。PostgreSQL提供了几种锁模式来控制并发的数据访问：Table-level Lock，Row-level Lock，Advisory Lock。 目前Hologres兼容的是Table-level Lock和Advisory Lock

说明：Hologres目前不支持显示的设置锁命令以及Advisory Lock相关的 UDF

Table-level Locks

1、锁分类

Table-level Lock是指表锁，表锁包含的锁种类有：

2、锁超时时间

FE Locks没有默认超时时间，需要业务设置超时时间，防止锁等待时间过长。

3、锁冲突关系

锁之间的冲突关系如下表所示，其中叉号表示冲突，表示一个操作拿着锁，其余操作都需要等锁：

Advisory Locks

大部分情况业务无需额外关注，因此本文不再做详细介绍。

BE Locks

1、锁分类

在Hologres中，BE Locks锁（后端锁）分类如下：

2、超时设置

BE Locks超时时间默认为5min，超过该时间则报错

3、锁冲突关系

BE Locks的冲突关系如下，其中叉号表示冲突，表示一个操作拿着锁，其余操作都需要等锁：

锁的作用范围

锁的作用范围

根据锁的分类，不同的锁作用范围不同，其中：

1、FE Locks

FE Locks只会作用在表对象上，无关数据，要么成功或者卡住，卡住就代表有锁冲突，在等待锁。

2、BE Locks

BE Locks会作用在数据或者表结构上，因此在作用范围上会分为表数据锁、行数据锁、表结构（schema）锁，其中：

• 表数据锁：代表整个表的数据都需要拿锁，如果多个任务同时都需要拿表锁，会造成任务等待锁现象，从而任务延迟
• 行数据锁：行锁是指整行数据拿锁，在执行效率上会更高，其中走fixed plan的Query都是行锁或者表schema
• 表schema锁：表结构锁，当事务需要读取或修改表结构时申请Schema锁，绝大部分的事务都会申请Schema锁。目前主要有如下类型的Schema锁：

• SchX：Schema排他锁，用于DDL语句，目前只有DROP TABLE；
• SchU：Schema更新锁，用于修改表结构的DDL语句（ALTER TABLE或set_table_property）；
• SchS：Schema稳定锁，用于DML语句，确保数据插入期间表结构不会发生改变；
• SchE：Schema存在锁，用户DML和DQL语句，确保读写数据期间表不会被删除；      

说明：

1、SchU是DDL锁更细粒度的管控，允许ALTER TABLE期间DQL正常运行，无需等待；SchX是最粗粒度的DDL排他锁，所有的DDL、DML、DQL都会等待；

2、如果start query耗时较长，则可能在等待BE Locks。

在Hologres中，其中常见命令作用的锁范围如下：

说明：

1、非fixed plan的写入/更新/删除都为bulkload

2、create index命令目前是指创建json相关索引，见文档。

3、DDL命令包括CREATE、DROP、ALTER等

事务相关的锁说明

Hologres 目前仅支持 DDL 的显式事务，并不支持单纯的 DML 的事务，也不支持 DDL 和 DML 混合的事务：

1. Hologres 不支持嵌套子事务
2. 单纯的 DML 事务虽然语法上可以通过，但是实际不支持原子提交和回滚。

如下DML即使 insert 成功，如果之后的 update 失败了，insert 的数据也不会被回滚。

begin;insertinto t1(id, salary)values(1,0);update t1 set salary =0.1where id =1;commit;

3. 纯 DDL事务可以按预期的方式工作

其中任何一行 DDL 命令失败则会整个事务被回滚。 比如下面第4行 alter 命令失败时，前面 create 和 drop 动作会被回滚。

begin;createtable t1(i int);droptable if exists t2;altertable t1 add column n text;commit;

4. DDL 和 DML 命令混合的事务会被禁止

如下示例，当事务中包含DDL和DML时，DML命令就会报错。

begin;createtable t1(i int);update t1 set i =1where i =1;ERROR:UPDATEin ddl transaction isnot supported now.

5. 显式事务中任何一个命令获得的锁都只会在整个事务结束（提交或回滚）时才统一释放

如下示例，当对父表做alter操作时，会同时获取父表（login_history）和子表（login_history_202001）的 ACCESS EXCLUSIVE锁， 但是这个命令执行完不会立即释放对应的锁，而是要等待最后的第 10 行的 commit 执行完（不管成功还是失败）才会释放锁。若是一直不commit，则会一直拿着锁，这时若有其他对这个表的DDL操作，则会锁表并报错。

-- suppose we have three tablescreatetable temp1(i int, t text);createtable login_history(ds text, user_id bigint, ts timestamptz) partition by list (ds);createtable login_history_202001 partition of login_history for valuesin('202001');begin;altertable login_history_s1 add column user_id bigint;droptable temp1;createtable tx2(i int);commit;

锁排查

上面介绍的两种锁，FE Locks在实际业务中是最常见也最容易引起问题的锁。当锁住时，可以通过系统表查询锁住的表以及SQL，下面将会具体介绍如何操作。

在具体的锁排查介绍之前，先了解需要用到的Postgres系统视图或者表，通过这些信息的结合来查出锁信息：

• pg_stat_activity: 查看当前实例正在运行的SQL。
• pg_locks: 查看当前实例正在运行中的进程或者正在等待的锁。

步骤1：查询运行时间较长的Query（可选）

通过pg_stat_activity查看运行时间较长的Query以及对应的状态，若是有Query长时间不结束，可能是这个表可能已经有其他的操作被拿锁，导致这个Query等锁。

说明：客户端可以通过参数设置 application_name，更容易排查问题。 例如在通过命令行 psql 连接时，可以通过环境变量 PGAPPNAME 来指定： PGAPPNAME=mac-sql psql -h holo-url -p 80 -d postgres

select datname, pid, application_name, wait_event_type, state, backend_xid, backend_start, xact_start, query_start, query from pg_stat_activity where backend_type in('client backend');

步骤2：查询是否有锁

通过查询是否有锁，排查长时间运行的query是否被锁住。通过以下命令查看是否有锁，f代表false，表示当前 pid 进程正在等待其他进程释放锁。

-- 查看所有在等的锁，持有的锁，及持有/等待的进程等信息select*from pg_locks where granted ='f';

若是知道哪个query运行时间比较长，可以通过pid反查是否有锁住,若是出现“f”则说明在等待锁：

select*from pg_locks where pid =<pid>;

步骤3：排查哪个进程在拿锁

通过步骤2查看知道哪个pid进程在等锁，根据其oid（即表关系）通过以下查看是否有拿锁，t代表true，代表正在拿锁。

-- 查看拿到了表锁的进程信息select pid from pg_locks where relation =<OID>and granted ='t';

步骤4：排查拿锁的query

通过步骤3结果的PID，查询真正拿锁的query

select*from pg_stat_activity where pid =<PID>;

步骤5：释放锁

找到拿锁的query之后，可以直接将query进行kill，以释放锁

select pg_cancel_backend(<pid>);

常见问题

报错：internal error: Cannot acquire lock in time, current owners: [(Transaction =302xxxx, Lock Mode = SchS|SchE|X)]."

报错原因：执行query的表有被其他query拿住BE Locks（如报错Lock Mode = SchS|SchE|X，则为Schema稳定锁、Schema存在锁、排他锁），导致query等BE Locks超时（5min）从而报错

解决办法：报错中的transaction id即Transaction =302xxxx对应query id，可以通过transaction id在慢query日志或者活跃Query中查对应拿锁的query。

报错：ERROR: Operation timed out: Wait schema version timeout.: Server current target schema version:xxx is late from request schema version: yyy

报错原因：执行DDL后，会先在Frontend（FE）节点执行，再异步在Storage Engine（SE）执行，当FE执行DDL结束后会对节点Version（版本）进行更新，若SE的DDL还没执行完成，导致SE的版本比FE的版本低，此时query会等待SE执行DDL，如果超过5min后SE仍然没有执行完成，就会报错等待schema版本超时。

解决办法：

• 先Kill掉等锁的DML，然后重试Query
• 重启实例（极端手段）

报错：The requested table name: xxx (id: 10, version: 26) mismatches the version of the table (id: 10, version: 28) from server

报错原因：执行DDL后，会先在Frontend（FE）单个节点执行，再异步在Storage Engine（SE）执行。SE已经完成DDL并更新版本，但是因为FE节点较多，节点间Replay未完成，导致部分FE节点的版本低于SE，而Query正好在版本较低的FE中执行，从而出现报错。

解决办法：

• 多重试几次query
• 若是超过几分钟还报错建议重启实例（极端手段）

报错：internal error: Cannot find index full ID: 86xxx (table id: 20yy, index id: 1) in storages or it is deleting!

报错原因：执行DROP Table或者Truncate Table时，对这个表进行DML/select，DROP/Truncate需要拿DDL大锁，导致query需要等锁，直到发现表被Drop了从而报错

解决办法：执行DROP/Truncate时，不对表进行Query