KingbaseES Create Index Concurrently 过程探究
前言:
我们知道Oracle 可以通过create index online 在线创建索引,而不影响其他会话修改数据,但Oracle 实际在online 创建索引的最后一步,实际还是需要进行锁升级,申请表级的S锁,因此,最后还是有可能堵塞其他会话。而KingbaseES 的两阶段创建索引的机制,则不会对增删改操作有任何影响。以下我们通过观察创建索引过程中会话持有锁及等待的情况,来看下整个过程。
一、KingbaseES 非 Concurrently 创建索引
过程及锁申请如下:
可以看到,正常创建索引的过程需要一直持有 ShareLock 锁,而 ShareLock 与 RowExclusiveLock 冲突,增删改操作无法进行。
二、KingbaseES 以 Concurrently 创建索引
过程及锁持有如下:
注意点:
- 会话A 模拟了两次事务(这两次事务间隔时间很长),主要是为了验证 concurrently 创建索引的两次读取数据的过程。
- 会话A 在结束第1个事务后,会话B 才能开始扫描表(所有create index 开始时活动事务结束后),并建立索引。
- 会话 A 在结束第1 个事务后,立即开启事务2 , 此时 会话B 才开始建索引,也就是先于 B (在会话B 需要取得snapshot2前),这样会话B 又得等待。
- 可以看到,在创建过程中会话B 的virtualtransaction 会变动(两个值)
在并发索引构建中,需要在两个虚拟事务中发生两次表扫描。在每一次表扫描之前,索引构建必须等待已经修改了 表的现有事务终止。在第二次扫描之后,索引构建必须等待任何持有早于第二次扫描的快照的事务终止。然后该索引最终能被标记为准备好使用,并且CREATE INDEX命令终止。 不过即便那样,该索引也不是立刻可以用于查询:在最坏的情况下,只要早于索引构建开始时存在的事务存在,该索引就无法使用。
具体阶段如下:
- 开启 virtualtransaction1,拿到当前snapshot1。
- 扫描A表前,等待所有snapshot1前所有修改过A表的事务结束。
- 扫描A表,并建立索引。
- 结束 virtualtransaction1。
- 开启 virtualtransaction2,拿到当前 snapshot2。
- 再次扫描A表前,等待snapshot2前所有修改过A表的事务结束。
- 在snapshot2之后启动的事务对A表执行的DML,会修改索引。
- 再次扫描A 表,根据xmin or xmax ,在snapshot1到snapshot2之间变更的记录,合并到索引。
- 上一步更新索引结束后,等待任何持有早于第二次扫描的快照的事务结束(比如某repeatable read事务读取了该表 )。
- 结束索引创建。索引可见。
KINGBASE研究院