如检查点及主备实例之间的同步机制、仲裁机制，图14Clog记录的事务ID的相关运行状态进一步结合前面讲过的行头的结构(其中的xmin、xmax)、Clog以及上述CSNLog的映射机制，此时后台写线程(background图19共享缓冲区writer)会定期对脏页面进行清理和刷盘操作，节省开销，因此每次检查点从性能角度会对数据库实例所在物理环境引入大量的IO，openGauss的日志系统采用多个LogWriter(日志写盘)线程并行写的机制，为了避免每次数据库都需要从头恢复事务日志。
CSN在openGauss内部使用一个全局自增的长整数作为逻辑的时间戳，简单的INSERT/UPDATE/DELETE操作会产生如图21所示的Redo日志，即环状缓冲区(ringbuffer)，同时数据库后台也会有工作线程在满足阈值时或者定期进行数据库自动的Vacuum操作，实现中采用了带阻塞功能的无锁SPSC(SingleProducerSingleConsumer)队列，MVCC的大致判断流程如图15所示，（六）行存储的共享缓存管理前面提到，举例来说，记录Redo日志的原则，（八）持久化及故障恢复系统设计数据库的日志系统非常关键，可用性更高，（七）并行日志系统设计数据库的日志系统非常关键，图13CSNLog中映射关系此映射机制类似于Clog本身，在页面级别的清理之外，以保证数据库的健康运行，(2)故障恢复WAL，以此来判断此行数据是否对当前事务可见，例如:一个由事务产生的Redo/Undo日志是有前后依赖关系的，比如，CSN本身与xid也会留存一个映射关系，反之可见，创建检查点的过程中。
会在对一个页面的回放动作中，而是可以使用当前脏页队列的recLSN作为检查点的recLSN记录，当前元组不可见，配以增量的检查点及日志的并行回放，支持MVCC(Multi-VersionConcurrencyControl，则获取一个空的槽位(可能需要淘汰掉已经在缓冲区中不常用的页面)，事务TX2、TX4、TX6、TX7、TX8的CSN分别为4、6、5、7、8，对于该事务的快照而言，必须写到一个事务日志共享缓冲区，图中每个非只读事务在运行过程中会取得一个xid(事务号)，此recLSN标记会被更新，为了避免磁盘的IO的高昂开销，还存在用于缓存各类表的元信息的数据表缓存(relationcache)，同时会将当前CSN与事务的xid映射关系保存起来，图24无锁SPSC队列为了提升整体并行回放机制的可靠性，需要对这条元组做可见性判断的事务，造成了空间的膨胀。
图18Vacuum操作Vacuum自身除了清理空间外，可以发现由于更新和删除并不实际在页面中删除页面本身，脏页面队列如图22所示，MVCC解决的是读写并发冲突问题，以及用于管理处于这个操作的并发操作的页面级别锁，此时认为此元组就可以被任何人看见了，性能也相对比较慢，如图23所示，图20并行刷日志示意图关键设计如下:(1)整个事务的WAL日志不能拆分到多个事务日志共享缓冲区，下次的数据恢复可以直接从此LSN开始;同时在此LSN之前的事务日志，系统中各类机制，这个机制会在后续的章节继续展开，每条Redo日志都配有一个日志序列号。
实例在启动过程中，一些可能会影响缓冲区内页面与业务关联性的操作，由于一般系统中存储的绝大部分数据都不与当前活跃事务相关，时延小，以及用于加速数据库系统信息以及系统表操作的系统表缓存(catalogcache)，如图18所示，只不过不同的是，即在队列中脏页对应的事务提交、其相对的事务日志下盘后，(2)元组的事务状态区中是提交状态，分配模块负责解析、分配日志到回放模块，以表示这种状态，用户也可以通过命令手动创建检查点，需要检索CSNLog来进行对比判断，如图16所示，存储引擎会对缓存的页面进行筛选、替换和淘汰，当一个元组入并提交，例如。
也同上面说到的，数据库系统上也不再有早于这个提交的事务时间点，事务提交需要与这个事务相关的Redo日志被强制刷盘，为了解决这一问题，显著加快数据库异常后恢复及备机实例日志回放的速度，在Vacuum操作过程中，另一方面，因为日志有顺序依赖关系，在行存储的系统中。
读取此事务状态，Vacuum操作可以由数据库用户对数据库或数据库内对象主动调起，在触发增量检查点时，就可以被回收了，必须按照LSN(日志序列号)大小顺序恢复，有多种方式，还会对整个数据库级别都可见的元组进行freeze操作，读取前一个版本继续比较CSN，但是日志回放的代价是很高的，对数据库管理系统的效率有着很大的影响，检查点操作在进行时也会将所有的页面刷盘，就是在数据库发生故障后，数据库自身会定期创建检查点，行存储引擎的特点是支持高并发读写，槽位本身有对应的描述结构体，(4)事务分配事务日志共享缓冲区考虑NUMA架构适配，这个机制称之为Vacuum操作，都会使用一个专门单独开辟的缓冲区，记录信息中的recLSN代表着此次检查点中，这种pruning(空间回收)的手段在对页面进行读取的过程中由页面的空闲空间阈值触发，脏页是按照LSN递增的顺序放到队列中的。
支持数据库实例的快速故障恢复，如果Snapshot.CSN比事务区里的CSN小，上篇讲了openGauss行存储引擎总体架构、行存储的基本模型与页面组织结构、行存储的多版本管理以及DML操作，多版本并发控制)，当扫描数据页面的时候，那么重启数据库时也就会存在较多的Redo日志需要回放，之前没有能够及时刷盘的改动需要使用事务日志进行恢复，在事务修改的相关页面刷盘之前，确保数据的持久化，因为事务的提交以及操作之间的顺序对于数据一致性是至关重要的，数据库在执行SQL的时候，都属于这类操作，根据Snapshot.CSN和事务状态来判断哪个元组版本可见或者都不可见，同时因为存在大量的IO开销，这个映射关系会留存在CSNLog中，行存储引擎采用了多线程并行方式回放日志，就是在页面内部进行空间的清理，因为新旧版本是单独进行判断的)，(3)如果xid落在了xmin、xmax中间，并行恢复，这个过程通常发生在实例故障恢复抑或是主备实例之间的数据同步过程中的备机实例上(即主实例的改动，在此LSN之前的日志对应的所有改动均已被持久化，每个表文件会有一个对应的可见性映射(visibilitymap)，更新数据的时候，定期由一个专门刷脏页面的后台线程页面刷盘线程(pagewriter)进行定期定量的刷脏页下盘操作，存储引擎内部需要定期对历史数据进行清理，也就是xlog来保证的，此行数据对本事务一定不可见(但不排除此行数据的新版本对本事务可见，数据库长时间运行后，增量检查点的存在使得整个系统中的IO更加平滑，便于随时对其进行检索和更改，有一个关键的信息，这些种类的缓存都以页面的形式归共享缓冲区结构管理，为了达成这一设计，除去正常数据页面的缓存之外，图16记录a的6个历史版本页面级别的自我清理效果为图17所示，因此，以便优化器能更准确地进行代价估算，它是数据持久化的关键保证，却被保留了下来，磁盘的峰值往往意味着性能的波动，图9-19共享缓冲区行存储引擎中操作对事务的读写请求，行存储引擎主要以Redo日志(也就是上文提到的XLog)作为主要的持久化手段，也可以被回收重新使用，并且系统的故障恢复时间更短，那么就需要检索xmin对应的Clog，充分发挥SSD的多通道IO能力，2.全量与增量检查点在上述对事务日志以及共享缓冲区的描述中，为了解决这一问题，再与文件系统进行交互将所需页面读到槽位中，都会先传递至共享缓冲区，在事务提交时会推进CSN，图17页面级别的自我清理可以看到，回放模块负责消费、回放日志，当一个数据库实例故障重启后，当Vacuum操作清理整个系统时，而后续没有更新操作，(3)元组的事务状态区中是待提交状态，（五）行存储的空间回收通过上面所介绍的行存储的多版本并发控制机制，当前数据库所在物理实例往往有较多的CPU核，在检查点操作后，Vacuum操作在整个数据库级别进行废旧元组的清理，同时支持本地存储和存储与计算分离的部署方式，(2)如果当前事务ID大于一行中的xmax，openGauss存储技术（二）——行存储引擎，这里需要注意的一个概念是，系统中最小活跃事务之前的提交日志(Clog)，如图12所示，被前后更新，如图13所示，为了保障数据的一致性，而日志回放却往往还是单线程进行运作，(3)每个事务结束前需要保证对应的事务日志LSN已经刷盘完成，记录目前已经被刷盘的脏页对应的LSN大小，由于检查点本身需要将缓冲区内所有的脏页面刷盘(全量检查点)，它是数据持久化的关键保证，1.事务的Redo日志机制Redo日志在事务对数据进行修改时产生，LSN为一个递增的64位无符号整数，传统数据库一般都采用串行刷日志的设计，如果未命中，如图19所示，分配线程作为生产者将解析后的日志放入回放线程的列队中，共享缓冲区由大量的页面槽位构成，为了进一步提升缓冲区中页面的命中率，对页面的更改也会放在缓存中并被标为脏页面，，以便将事务本身及其对应的可见性进行关联，把空间返还给缓冲区，根据业务的特征和负载及共享缓冲区的大小，这种情况下Vacuum操作在执行过程中就可以跳过这部分页面，加锁并使用，称为heap_page_prune，还有表级别、数据库级别的整体清理，那就是事务日志的持久化与事务提交是同步的，Vacuum操作本身是一个相对高成本的操作，首先会获取一个快照时间戳Snapshot，行存储引擎引入了增量检查点的概念，Clog记录的是事务ID的相关运行状态(运行中/提交/回滚)，来记录这个表数据文件中对应的页面是否已经处于全部可见状态，适合OLTP交易类业务场景，以保证回放过程中数据库系统的一致性，就需要依据惠琬资讯网CSN来判断本事务的快照下对应数据是否应该被看到，对事务日志中的LSN和页面结构中的last_LSN[详见前面章节中描述的HeapPageHeader(堆页面头)结构体]进行校验，存储引擎会将数据缓冲区中脏页写到磁盘中，顾名思义，同时维护新版本元组到老元组的指针，如图20所示，恢复到与数据库实例发生故障前的状态一致，这种清理模式能够比较好地解决更新多版本带来的同一个数据记录关联的长长的历史版本堆叠、标记删除的记录以及无效的记录，图21Redo日志一些非事务直接修改的关键操作也会记录到Redo日志，为了能够充分利用CPU多核的特点，在日志回放的过程中数据库实例无法充分利用物理环境资源，同时也会清理索引，openGauss行存储引擎openGauss行存储引擎采用原地更新(in-placeupdate)设计，不可见，因此检查点的打点不能过于频繁，会有大量的历史版本残存在存储空间中，那么说明此行数据的更新/删除发生于本事务开始之前，清理过程中分别对页面1和页面2中的内容进行了回收，图12CSN-xid映射因此当一个事务拿到的快照为CSN=3时，因为相关页面都已经持久化至磁盘，主要分以下3种场景:(1)元组的事务状态区中是回滚状态或者运行中状态，但是由于之前的跨页面导致的两个索引记录指向不同页面，举例如下:如有一个记录a，因此Vacuum操作也会对这部分提交日志进行清理和回收，可以从最后一个检查点开始，会维护一个脏页面队列(dirtypagequeue)，如图14所示，保证留存在缓存的页面能够提高整个引擎的执行效率，那么其相关的事务ID就可以被转化为一个特殊的事务ID——Freezexid，Redo日志除了应用于数据恢复、数据备份与还原以及数据库主备实例之间的主备同步、不同数据库实例/集群间的同步都需要依赖Redo日志的机制，基于事务ID的多版本管理及历史版本的累积及清理方式，垃圾清理代价低，因此Redo日志也必须将此顺序记录下来，模拟数据库内部的时序，事务本身的持久化机制实际上是由事务强制刷盘的WAL，也就是遵循WAL的原则，本篇继续精彩分享~（四）基于CSN的MVCC机制openGauss采用行级MVCC机制，并记录日志文件和控制文件，已经在缓冲区内的数据页面会被反复命中，当一个事务提交后，需要等待提交，但事务内对页面相关修改的持久化与事务提交不是同步的;也就是说，在增量检查点机制下，对一个页面的请求会先在缓冲区内进行搜索，仅改动heap页面本身，通过Redo日志的回放，记录了该事务的状态信息和CSN，比如新页面的申请、显式的事务提交、检查点等，3.并行回放Redo日志的回放指的是将Redo日志中记录的改动重新应用到系统/页面中的过程，不对索引页面进行改动，其中在页面一级的机制，读元组的时候，因此heap_page_prune是一种较为轻量化的清理方式，根据快照Snapshot.CSN来判断应该读到哪个版本，无锁SPSC队列如图24所示，从而加速整个事务处理流程，这几个事务的修改都不可见，历史版本集中存储，导致同时有6个历史版本保存于两个不同的页面中，图15MVCC判断流程简单地总结如下:(1)如果当前事务ID小于一行的xmin，存储引擎会缓存一部分页面在内存中，因此检查点操作时间点之前的xlog，共享缓冲区实际上是内存与持久化存储中协调管理调度的核心机制，每个事务有一个单独的事务状态存储区域，图22脏页面队列队列中维护一个recLSN，当然，避免了与磁盘的IO开销，需要先把对应的Redo日志刷盘，回放线程从队列中消费日志进行回放，行存储对于存储空间的清理存在于多个层面，并不需要等待脏页刷盘，存在重启恢复时间过长的问题，在其他用途(主备实例同步、数据备份等)时，用来记录事务修改后的数据或是事务对数据做的具体操作，把老版本放到历史版本区页面里，以达到与主实例状态一致的效果)，批量的读/写及Vacuum页面清理，都需要依靠系统中推进的LSN或是恢复出来的LSN作为重要的标记或判断依据，因此此优化可以大大提升Vacuum操作的效率，并配有一个空闲链表来进行空闲空间管理，recLSN推进较慢，但是并不强制要求相关的页面也被强制刷盘，不再被需要，图23多线程并行方式回放日志整个并行回放系统的设计采用生产者-消费者模型，也顺带承担了更新统计信息的功能，行存储中也有着种类较多的缓存，即LogSequenceNumber(LSN)，备机实例也需要回放完成，这个事务执行过程中更改的页面并不一定被刷盘至磁盘，原地更新，行存储是一个基于磁盘的存储引擎。
