MOT持久性

持久性是指长期的数据保护（也称为磁盘持久化）。持久性意味着存储的数据不会遭受任何形式的退化或损坏，因此数据不会丢失或损坏。持久性可确保在有计划停机（例如维护）或计划外崩溃（例如电源故障）后数据和MOT引擎恢复到一致状态。

内存存储是易失的，需要电力来维护所存储的信息。另一方面，磁盘存储是非易失性的，这意味着它不需要电源来维护存储的信息，因此不用担心停电。MOT同时使用这两种类型的存储。内存中存储了所有数据，同时将事务性更改持久化到磁盘，并保持频繁的定期MOT检查点，以确保在关机时恢复数据。

用户必须保证有足够的磁盘空间用于日志记录和检查点操作。检查点使用单独的驱动器，通过减少磁盘I/O负载来提高性能。

参考MOT关键技术了解如何在MOT引擎中实现持久化。

若要设置持久性：

为保证严格一致性，请在postgres.conf配置文件中将参数sync_commit配置为On。

MOT的WAL重做日志和检查点开启持久性，下面将详细介绍。

MOT日志记录：WAL重做日志

为保证持久性，MOT全面集成openGauss的WAL机制，通过openGauss的XLOG接口持久化WAL记录。这意味着，每次MOT记录的添加、更新和删除都记录在WAL中。确保了可以从这个非易失性日志重新生成和恢复最新的数据状态。例如，如果向表中添加了3行，删除了2行，更新了1行，那么日志中将记录6个条目。

MOT日志记录和openGauss磁盘表的其他记录写入同一个WAL中。

MOT只记录事务提交阶段的操作。

MOT只记录更新的增量记录，以便最小化写入磁盘的数据量。

在恢复期间，从最后一个已知或特定检查点加载数据；然后使用WAL重做日志完成从该点开始发生的数据更改。

WAL重做日志将保留所有表行修改，直到执行检查点（如上所述）。然后可以截断日志，以减少恢复时间和节省磁盘空间。

注意：为确保日志IO设备不会成为瓶颈，日志文件必须放在具有低延迟的驱动器上。

MOT日志类型

支持两个同步事务日志选项和一个异步事务日志选项（标准openGauss磁盘引擎也支持这些选项）。MOT还支持同步的组提交日志记录与NUMA-aware优化，如下所述。

根据您的配置，实现以下类型的日志记录：

• 同步重做日志记录

  同步重做日志记录选项是最简单、最严格的重做日志记录器。当客户端应用程序提交事务时，事务重做条目记录在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上运行，每个线程只写在各自运行的核的槽位上。

  2. 在事务完成并且客户端应用程序发送Commit命令之后，事务重做日志条目将与同组的其他事务一起序列化。

  3. 当特定一组事务满足配置条件后，如重做日志（MOT）小节中描述的已提交的事务数或超时时间，该组中的事务将被写入磁盘的WAL中。当这些日志条目被写入日志时，发出提交请求的客户端应用程序正在等待响应。

  4. 一旦NUMA-aware组中的所有事务缓冲区都写入日志，该组中的所有事务都将对内存存储执行必要的更改，并且通知客户端这些事务已完成。

     总结

     组同步重做日志记录选项是一个极其安全和严格的日志记录选项，因为它确保了客户端应用程序和WAL重做日志条目的完全同步，从而确保了总的持久性和一致性，而且绝对不会丢失数据。此日志记录选项可防止客户端应用程序在事务尚未持久化到磁盘时将事务标记为成功的情况。

     该选项的磁盘写入次数比同步重做日志记录选项少，这可能意味着它更快。缺点是事务被锁定的时间更长。在同一NUMA内存中的所有事务都写入磁盘的WAL重做日志之前，它们一直处于锁定状态。

     是否使用此选项取决于事务工作负载的类型。例如，此选项有利于事务较多的系统。而对于事务少的系统而言，磁盘写入量也很少，因此不建议使用。

• 异步重做日志记录

  异步重做日志记录选项是最快的日志记录方法，但是它不能确保数据不会丢失，某些仍位于缓冲区中且尚未写入磁盘的数据在电源故障或数据库崩溃时可能会丢失。当客户端应用程序提交事务时，事务重做条目将记录在内部缓冲区中，并按预先配置的时间间隔写入磁盘。客户端应用程序不会等待数据写入磁盘。它将继续进行下一个事务。这就是异步重做日志记录最快的原因。

  当客户端应用程序提交事务时，事务重做条目记录在WAL重做日志中，如下所示：

  1. 当事务正在进行时，它存储在MOT内存中。

  2. 在事务完成并且客户端应用程序发送Commit命令后，事务重做条目将被写入内部缓冲区，但尚未写入磁盘。然后更改MOT数据内存，并通知客户端应用程序事务已提交。

  3. 后台运行的重做日志线程按预先配置的时间间隔收集所有缓存的重做日志条目，并将它们写入磁盘。

     总结

     异步重做日志记录选项是最快的日志记录选项，因为它不需要客户端应用程序等待数据写入磁盘。此外，它将许多事务重做条目分组并把它们写入一起，从而减少降低MOT引擎速度的磁盘I/O数量。

     异步重做日志记录选项的缺点是它不能确保在崩溃或失败时数据不会丢失。已提交但尚未写入磁盘的数据在提交时是不持久的，因此在出现故障时无法恢复。异步重做日志记录选项对于愿意牺牲数据恢复（一致性）而不是性能的应用程序来说最为适用。

配置日志

标准openGauss磁盘引擎支持两个同步事务日志选项和一个异步事务日志选项。

配置日志记录

1. 在postgres.conf配置文件中的synchronous_commit = On参数中指定是否执行同步或异步事务日志记录。
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重做日志条目的数量，以此缩短数据库的恢复时间。检查点还减少了保存所有日志条目所需的存储空间。

如果没有检查点，那么为了恢复数据库，所有WAL重做条目必须从开始时间进行重放，可能需要几天或几周的时间，这取决于数据库中的记录数量。检查点记录数据库的当前状态，并允许丢弃旧的重做条目。

检查点在恢复方案（特别是冷启动）中是必不可少的。首先，从最后一个已知或特定检查点加载数据；然后使用WAL完成此后发生的数据更改。

例如，如果同一表行被修改100次，则日志中将记录100个条目。当使用检查点后，即使表行被修改了100次，检查点也可以一次性记录。在记录检查点之后，可以基于该检查点执行恢复，并且只需要播放自该检查点之后发生的WAL重做日志条目。