并行日志系统设计
数据库的日志系统非常关键，它是数据持久化的关键保证。传统数据库一般都采用串行刷日志的设计，因为日志有顺序依赖关系。例如:一个由事务产生的 Redo/Undo日志是有前后依赖关系的。openGauss的日志系统采用多个Log Writer(日志写盘)线程并行写的机制，充分发挥SSD的多通道IO 能力，如图20所示。
关键设计如下:
整个事务的 WAL日志不能拆分到多个事务日志共享缓冲区，必须写到一个事务日志共享缓冲区。
故障恢复 WAL，并行恢复，必须按照 LSN(日志序列号)大小顺序恢复。
每个事务结束前需要保证对应的事务日志 LSN 已经刷盘完成。
事务分配事务日志共享缓冲区考虑 NUMA 架构适配。
（八）持久化及故障恢复系统设计
数据库的日志系统非常关键，它是数据持久化的关键保证。基于事务ID 的多版本管理及历史版本的累积及清理方式，行存储引擎主要以 Redo日志(也就是上文提到的 XLog)作为主要的持久化手段，配以增量的检查点及日志的并行回放，支持数据库实例的快速故障恢复。
1.事务的Redo日志机制
Redo日志在事务对数据进行修改时产生，用来记录事务修改后的数据或是事务对数据做 的 具 体 操 作。比 如，简 单 的INSERT/UPDATE/DELETE 操 作 会 产 生 如图21所示的 Redo日志。
一些非事务直接修改的关键操作也会记录到 Redo日志，比如新页面的申请、显式的事务提交、检查点等。记录 Redo日志的原则，就是在数据库发生故障后，可以从最后一个检查点开始，通过 Redo日志的回放，恢复到与数据库实例发生故障前的状态一致。
Redo日志除了应用于数据恢复、数据备份与还原以及数据库主备实例之间的主备同步、不同数据库实例/集群间的同步都需要依赖 Redo日志的机制。为了保障数据的一致性，在事务修改的相关页面刷盘之前，需要先把对应的 Redo日志刷盘，也就是遵循 WAL的原则。
因为事务的提交以及操作之间的顺序对于数据一致性是至关重要的，因此 Redo日志也必须将此顺序记录下来。每条 Redo日志都配有一个日志序列号，即 Log Sequence Number(LSN)。在行存储的系统中，LSN 为一个递增的64位无符号整数。系统中各类机制，如检查点及主备实例之间的同步机制、仲裁机制，都需要依靠系统中推进的LSN 或是恢复出来的 LSN 作为重要的标记或判断依据。
原文链接：https://blog.csdn.net/GaussDB/article/details/116012521
