MOT 持久性
持久性是指长期的数据保护（也称为磁盘持久化）
。持久性意味着存储的数据不会遭受
任何形式的退化或损坏，
因此数据不会丢失或损坏。
持久性可确保在有计划停机
（例如维护）
或计划外崩溃（例如电源故障）后数据和MOT 引擎恢复到一致状态。
内存存储是易失的、
需要电力来维护所存储的信息。
另一方面，
磁盘存储是非易失性的，
这意味着它不需要电源来维护存储的信息，因此不用担心停电。MOT 同时使用这两种类型
的存储。
内存中存储了所有数据，
同时将事务性更改持久化到磁盘，
并保持频繁的定期MOT
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
465
检查点，以确保在关机时恢复数据。
用户必须保证有足够的磁盘空间用于日志记录和检查点操作。
检查点使用单独的驱动器，
通过减少磁盘I/O 负载来提高性能。
参考MOT 关键技术了解如何在MOT 引擎中实现持久化。
若要设置持久性：
为保证严格一致性，请在postgresql.conf 配置文件中将参数sync_commit 配置为on。
MOT 的WAL 重做日志和检查点开启持久性，下面将详细介绍。
MOT 日志记录：WAL 重做日志
为保证持久性，MOT 全面集成GBase 8c 的WAL 机制，通过GBase 8c 的XLOG 接口
持久化WAL 记录。这意味着，每次MOT 记录的添加、更新和删除都记录在WAL 中。确保
了可以从这个非易失性日志重新生成和恢复最新的数据状态。例如，如果向表中添加了3
行，删除了2 行，更新了1 行，那么日志中将记录6 个条目。
MOT 日志记录和GBase 8c 磁盘表的其他记录写入同一个WAL 中。
MOT 只记录事务提交阶段的操作。
MOT 只记录更新的增量记录，以便最小化写入磁盘的数据量。
在恢复期间，从最后一个已知或特定检查点加载数据；然后使用WAL 重做日志完成从
该点开始发生的数据更改。
WAL 重做日志将保留所有表行修改，直到执行检查点（如上所述）。然后可以截断日
志，以减少恢复时间和节省磁盘空间。
为确保日志IO 设备不会成为瓶颈，日志文件必须放在具有低延迟的驱动器上。
MOT 日志类型
支持两个同步事务日志选项和一个异步事务日志选项。MOT 还支持同步的组提交日志
记录与NUMA-aware 优化，如下所述。
根据您的配置，实现以下类型的日志记录：
同步重做日志记录
同步重做日志记录选项是最简单、
最严格的重做日志记录器。
当客户端应用程序提交事
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
466
务时，事务重做条目记录在WAL 重做日志中，如下所示：
(1)
当事务正在进行时，它存储在MOT 内存中。
(2)
事务完成后，客户端应用程序发送Commit 命令，该事务被锁定，然后写入磁盘上的
WAL 重做日志。当事务日志条目写入日志时，客户端应用程序仍在等待响应。
(3)
一旦事务的整个缓冲区被写入日志，
就更改内存中的数据，
然后提交事务。
事务提交后，
通知客户端应用程序事务完成。
总结
同步重做日志记录选项是最安全、
最严格的，
因为它确保了客户端应用程序和每个事务
提交时的WAL 重做日志条目的完全同步，从而确保了总的持久性和一致性，并且绝对不会
丢失数据。
此日志记录选项可防止客户端应用程序在事务尚未持久化到磁盘时将事务标记为
成功的情况。
同步重做日志记录选项的缺点是，
它是三个选项中最慢的日志机制。
因为客户端应用程
序必须等待所有数据都写入磁盘，并且磁盘写入过于频繁导致数据库变慢。
组同步重做日志记录
组同步重做日志记录选项与同步重做日志记录选项非常相似，
它确保完全持久性，
绝对
不会丢失数据，并保证客户端应用程序和WAL 重做日志条目的完全同步。不同的是，组同
步重做日志记录选项将事务重做条目组同时写入磁盘上的WAL 重做日志，而不是在提交时
写入每个事务。使用组同步重做日志记录可以减少磁盘I/O 数量，从而提高性能，特别是在
运行繁重的工作负载时。
MOT 引擎通过根据运行事务的核的NUMA 槽位自动对事务进行分组，使用NUMA 感
知优化来执行同步的组提交记录。
有关NUMA-aware 内存访问的更多信息，请参阅NUMA-aware 分配和亲和性。
当一个事务提交时，一组条目记录在WAL 重做日志中，如下所示：
(1)
当事务正在进行时，
它存储在内存中。
MOT 引擎根据运行事务的核的NUMA 槽位对桶
中的事务进行分组。
在同一槽位上运行的所有事务都被分组在一起，
并且多个组将根据
事务运行的核并行填充。
这样，
将事务写入WAL 更为有效，
因为来自同一个槽位的所有缓冲区都一起写入磁盘。
注意：每个线程在属于单槽位的单核/CPU 上运行，每个线程只写在各自运行的核的槽
位上。
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
467
(2)
在事务完成并且客户端应用程序发送Commit 命令之后，
事务重做日志条目将与同组的
其他事务一起序列化。
(3)
当特定一组事务满足配置条件后，如重做日志（MOT）小节中描述的已提交的事务数
或超时时间，该组中的事务将被写入磁盘的WAL 中。当这些日志条目被写入日志时，
发出提交请求的客户端应用程序正在等待响应。
(4)
一旦NUMA-aware 组中的所有事务缓冲区都写入日志，该组中的所有事务都将对内存
存储执行必要的更改，并且通知客户端这些事务已完成。
总结
组同步重做日志记录选项是一个极其安全和严格的日志记录选项，
因为它确保了客户端
应用程序和WAL 重做日志条目的完全同步，从而确保了总的持久性和一致性，而且绝对不
会丢失数据。
此日志记录选项可防止客户端应用程序在事务尚未持久化到磁盘时将事务标记
为成功的情况。
该选项的磁盘写入次数比同步重做日志记录选项少，
这可能意味着它更快。
缺点是事务
被锁定的时间更长。在同一NUMA 内存中的所有事务都写入磁盘的WAL 重做日志之前，
它们一直处于锁定状态。
是否使用此选项取决于事务工作负载的类型。例如，此选项有利于事务较多的系统。而
对于事务少的系统而言，磁盘写入量也很少，因此不建议使用。
异步重做日志记录
异步重做日志记录选项是最快的日志记录方法，
但是它不能确保数据不会丢失，
某些仍
位于缓冲区中且尚未写入磁盘的数据在电源故障或数据库崩溃时可能会丢失。
当客户端应用
程序提交事务时，
事务重做条目将记录在内部缓冲区中，
并按预先配置的时间间隔写入磁盘。
客户端应用程序不会等待数据写入磁盘。
它将继续进行下一个事务。
这就是异步重做日志记
录最快的原因。
当客户端应用程序提交事务时，事务重做条目记录在WAL 重做日志中，如下所示：
(1)
当事务正在进行时，它存储在MOT 内存中。
(2)
在事务完成并且客户端应用程序发送Commit 命令后，
事务重做条目将被写入内部缓冲
区，但尚未写入磁盘。然后更改MOT 数据内存，并通知客户端应用程序事务已提交。
(3)
后台运行的重做日志线程按预先配置的时间间隔收集所有缓存的重做日志条目，
并将它
们写入磁盘。
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
468
总结
异步重做日志记录选项是最快的日志记录选项，
因为它不需要客户端应用程序等待数据
写入磁盘。此外，它将许多事务重做条目分组并把它们写入一起，从而减少降低MOT 引擎
速度的磁盘I/O 数量。
异步重做日志记录选项的缺点是它不能确保在崩溃或失败时数据不会丢失。
已提交但尚
未写入磁盘的数据在提交时是不持久的，
因此在出现故障时无法恢复。
异步重做日志记录选
项对于愿意牺牲数据恢复（一致性）而不是性能的应用程序来说最为适用。
配置日志
标准GBase 8c 磁盘引擎支持两个同步事务日志选项和一个异步事务日志选项。
配置日志记录
(1)
在postgresql.conf 配置文件中的sync_commit (On = Synchronous)参数中指定是否执行同
步或异步事务日志记录。
(2)
在重做日志章节中的mot.conf 配置文件里，将enable_redo_log 参数设置为True。
如果已选择事务日志记录的同步模式（如上文所述，synchronous_commit = on），则在
mot.conf 配置文件中的enable_group_commit 参数中指定Group Synchronous Redo Logging 选
项或Synchronous Redo Logging 选项。如果选择Group Synchronous Redo Logging，必须在
mot.conf 文件中定义以下阈值，决定何时将一组事务记录在WAL 中。
group_commit_size：一组已提交的事务数。例如，16 表示当同一组中的16 个事务已由
它们的客户端应用程序提交时，则针对16 个事务中的每个事务，在磁盘的WAL 重做
日志中写入一个条目。
group_commit_timeout：超时时间，单位为毫秒。例如，10 表示在10 毫秒之后，为同
一组由客户端应用程序在最近10 毫秒内提交的每个事务，在磁盘的WAL 重做日志中
写入一个条目。
有关配置的详细信息，请参阅MOT 持久性中的重做日志。
MOT 检查点
检查点是一个时间点。在这个时间点，表行的所有数据都保存在持久存储上的文件中，
以便创建完整持久的数据库镜像。这是一个数据在某个时间点的快照。
检查点减少了为确保持久性而必须重放的WAL 重做日志条目的数量，以此缩短数据库
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
469
的恢复时间。检查点还减少了保存所有日志条目所需的存储空间。
如果没有检查点，
那么为了恢复数据库，
所有WAL 重做条目必须从开始时间进行重放，
可能需要几天或几周的时间，
这取决于数据库中的记录数量。
检查点记录数据库的当前状态，
并允许丢弃旧的重做条目。
检查点在恢复方案（特别是冷启动）中是必不可少的。首先，从最后一个已知或特定检
查点加载数据；然后使用WAL 完成此后发生的数据更改。
例如，如果同一表行被修改100 次，则日志中将记录100 个条目。当使用检查点后，即
使表行被修改了100 次，检查点也可以一次性记录。在记录检查点之后，
可以基于该检查点
执行恢复，并且只需要播放自该检查点之后发生的WAL 重做日志条目。