详解K-DB RAC集群下的锁机制管理(三) ——K-DB锁包含的信息以及运行机制

这是关于K-DB锁技术的最后一部分,此前,陆续介绍了K-DB的演进、基本架构、锁目录的存储以及同数据块映射关系的建立等。本文将介绍K-DB锁包含的信息和运行机制,也就是每条锁到底包含哪些信息,以及每一条锁是如何建立、执行和取消的。

K-DB锁包含的信息

不同数据库产品的锁记录的信息差异不大,通用数据库在集群架构下通常需要的锁信息如下。锁信息的复杂性更多与技术架构相关。集群架构的数据库锁,需要记录的信息远远超过了Active-Standby架构的数据库产品,K-DB锁纪录的信息主要包含以下几点:

  1. DataBlock address。锁是针对数据块的,所以锁中的信息需要记录数据块的物理地址。
  2. Instance id。在集群环境下,会存在多个实例,需要记录下具体的实例id,才能知道该数据块正在被哪个节点访问。
  3. Lock mode。节点在访问数据块时,需要根据读写需求,申请不同的锁模式。如果是读的话,一般是申请S锁(共享锁),如果是写入的话,需要申请X锁(独占锁)。
  4. Block state,也就是数据块的状态。在锁申请之后,数据块的状态也需要进行变化。在常用的数据块中,包括SCUR,XUR。在这里重点给大家介绍一个状态叫做PAST IMAGE 。因为这个状态在单节点中是没有的。如果一个数据块在某一个节点中被修改后,然后被传输到了其他节点,那么本节点存储的数据块状态为PI(Past Image)block。PI block 在本节点中保留了一份最新更新的数据块的内容。当某一个节点down机后,利用PI能够提升数据库的恢复速度,K-DB正是利用了这项技术使得故障恢复速度明显快于业界其他产品。
  5. Role,是关于全局数据的一致性的信息。 一个数据块可以同时在多个节点的缓存中存在,而且可以不一致。当数据库的缓存中,一个数据块最多只有一个节点与磁盘中的数据不一致时。这个的角色就是local。当2个或2个以上的节点与磁盘数据不一致时,这个数据块的角色升级为global。对比global角色,local角色的数据块的回写会更简单,按照单节点的处理方式即可。而global 方式的话,处理的更加的复杂,需要在多个节点中进行确认。

详解K-DB RAC集群下的锁机制管理(三) ——K-DB锁包含的信息以及运行机制

K-DB锁的运行及测试数据

数据库锁的运行可分为申请、使用和取消三个环节,其中申请环节最为复杂,其他环节较为简单。

CWLS——锁管理的核心

CWLS(Cluster Wait-lock Service)模块负责系统锁的批准、生成和执行,是系统锁管理的核心模块。当一个instacne 向数据块的master 节点申请锁时,master 节点通过cluster wait-lock service查看当前锁的使用情况。申请进程主要一共有2个队列,一个是已经分配的队列,一个是等待转换队列。分配成功的队列上的锁模式的兼容性,必然是兼容的,与之相反的是,等待转换队列的锁模式是不兼容的,需要等待。例如,2个节点同时申请对用一个数据块进行读取操作。那么它们需要申请的是读共享锁。这2个锁是兼容的,可以同时放在分配列表中。GLD 中会记录下这两个节点的锁信息——共享锁。之后第三个节点想要修改这个数据块,它需要申请的独占锁。master节点的CWS发现该模式与当前分配链表中的锁信息不兼容,此时它需要等待。先把它放在conver queue中等待。向grant queen中的正在持有锁的实例发送请求,要求它们将当前的锁进行降级为与他兼容的模式。


原文发布时间为:2016-08-03 

本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。



上一篇:还在重复写空指针检查代码?考虑使用 Optional 吧!


下一篇:阿里云数据库全新功能Redis读写分离,全维度技术解析