MOT管理

下面介绍MOT管理。

MOT持久性

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

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

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

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

若要设置持久性：

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

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

MOT日志记录：WAL重做日志

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

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

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

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

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

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

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

MOT日志类型

支持两个同步事务日志选项和一个异步事务日志选项（标准MogDB磁盘引擎也支持这些选项）。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数量。

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

配置日志

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

配置日志记录

1. 在postgres.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重做日志条目的数量，以此缩短数据库的恢复时间。检查点还减少了保存所有日志条目所需的存储空间。

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

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

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

MOT恢复

MOT恢复的主要目标是在有计划停机（例如维护）或计划外崩溃（例如电源故障后）后，将数据和MOT引擎恢复到一致状态。

MOT恢复是随着MogDB数据库其余部分的恢复而自动执行的，并且完全集成到MogDB恢复过程（也称为冷启动）。

MOT恢复包括两个阶段：

检查点恢复：必须通过将数据加载到内存行并创建索引，从磁盘上的最新检查点文件恢复数据。

WAL重做日志恢复：从检查点恢复中使用检查点后，必须通过重放之后添加到日志中的记录，从WAL重做日志中恢复最近的数据（在检查点中未捕获）。

MogDB管理和触发WAL重做日志恢复。

• 配置恢复。
• 虽然WAL恢复以串行方式执行，但可以将检查点恢复配置为以多线程方式运行（即由多个工作线程并行运行）。
• 在mot.conf文件中配置Checkpoint_recovery_workers参数，见恢复（MOT）中的描述。

MOT复制和高可用

由于MOT集成到MogDB中，并且使用或支持其复制和高可用，因此，MOT原厂功能即支持同步复制和异步复制。

MogDB gs_ctl工具用于可用性控制和数据库操作。这包括gs_ctl切换、gs_ctl故障切换、gs_ctl构建等等。

有关更多信息，请参见MogDB参考指南。

• 配置复制和高可用性。
• 请参考MogDB相关文档。

MOT内存管理

规划和微调请参见MOT内存和存储规划和MOT配置。

MOT VACUUM清理

使用VACUUM进行垃圾收集，并有选择地分析数据库，如下所示。

• 【Postgres】

  在Postgres中，VACUUM用于回收死元组占用的存储空间。在正常的Postgres操作中，删除的元组或因更新而作废的元组不会从表中物理删除。只能由VACUUM清理。因此，需要定期执行VACUUM，特别是在频繁更新的表上。

• 【MOT扩展】

  MOT不需要周期性的VACUUM操作，因为新元组会重用失效元组和空元组。只有当MOT的大小急剧减少，并且不计划恢复到原来大小时，才需要VACUUM操作。

  例如，应用程序定期（如每周一次）大量删除表数据的同时插入新数据，这需要几天时间，并且不一定是相同数量的行。在这种情况下，可以使用VACUUM。

  对MOT的VACUUM操作总是被转换为带有排他表锁的VACUUM FULL。

• 支持的语法和限制

  按规范激活VACUUM操作。

  VACUUM [FULL | ANALYZE] [ table ];

  只支持FULL和ANALYZE VACUUM两种类型。VACUUM操作只能对整个MOT进行。

  不支持以下Postgres VACUUM选项：

  • FREEZE

  • VERBOSE

  • Column specification

  • LAZY模式（部分表扫描）

    此外，不支持以下功能：

  • AUTOVACUUM

MOT统计

统计信息主要用于性能分析或调试。在生产环境中，通常不打开它们（默认是关闭的）。统计信息主要由数据库开发人员使用，数据库用户较少使用。

对性能有一定影响，特别是对服务器。对用户的影响可以忽略不计。

统计信息保存在数据库服务器日志中。该日志位于data文件夹中，命名为postgresql-DATE-TIME.log。

有关详细的配置选项，请参阅统计（MOT）。

MOT监控

监控的所有语法支持基于Postgres的FDW表，包括下面的表或索引大小。此外，还存在用于监控MOT内存消耗的特殊函数，包括MOT全局内存、MOT本地内存和单个客户端会话。

表和索引大小

可以通过查询pg_relation_size来监控表和索引的大小。

例如：

数据大小

select pg_relation_size('customer');

索引

select pg_relation_size('customer_pkey');

MOT全局内存详情

检查MOT全局内存大小，主要是数据和索引。

select * from mot_global_memory_detail();

结果如下。

numa_node  | reserved_size        | used_size
----------------+----------------+-------------
-1            | 194716368896      | 25908215808
0             | 446693376         | 446693376
1             | 452984832         | 452984832
2             | 452984832         | 452984832
3             | 452984832         | 452984832
4             | 452984832         | 452984832
5             | 364904448         | 364904448
6             | 301989888         | 301989888
7             | 301989888         | 301989888

其中，

• -1为总内存。
• 0-7为NUMA内存节点。

MOT本地内存详情

检查MOT本地内存大小，包括会话内存。

select * from mot_local_memory_detail();

结果如下。

numa_node  | reserved_size      | used_size
----------------+----------------+-------------
-1            | 144703488       | 144703488
0             | 25165824        | 25165824
1             | 25165824        | 25165824
2             | 18874368        | 18874368
3             | 18874368        | 18874368
4             | 18874368        | 18874368
5             | 12582912        | 12582912
6             | 12582912        | 12582912
7             | 12582912        | 12582912

其中，

• -1为总内存。
• 0-7为NUMA内存节点。

会话内存

会话管理的内存从MOT本地内存中获取。

所有活动会话（连接）的内存使用量可以通过以下查询。

select * from mot_session_memory_detail();

结果如下。

sessid                   | total_size | free_size | used_size
----------------------------------------+-----------+----------+----------
1591175063.139755603855104 | 6291456    | 1800704   | 4490752

其中，

• total_size：分配给会话的内存。
• free_size：未使用的内存。
• used_size：使用中的内存。

DBA可以通过以下查询确定当前会话使用的本地内存状态。

select * from mot_session_memory_detail()
 where sessid = pg_current_sessionid();

结果如下。

MOT错误消息

错误可能由多种场景引起。所有错误都记录在数据库服务器日志文件中。此外，与用户相关的错误作为对查询、事务或存储过程执行或数据库管理操作的响应的一部分返回给用户。

• 服务器日志中报告的错误包括函数、实体、上下文、错误消息、错误描述和严重性。
• 向用户报告的错误被翻译成标准PostgreSQL错误码，可能由MOT特定的消息和描述组成。

错误提示、错误描述和错误码见下文。该错误码实际上是内部代码，不记录也不返回给用户。

写入日志文件的错误

所有错误都记录在数据库服务器日志文件中。以下列出了写入数据库服务器日志文件但未返回给用户的错误。该日志位于data文件夹中，命名为postgresql-DATE-TIME.log。

表 1 只写入日志文件的错误

返回给用户的错误

下面列出了写入数据库服务器日志文件并返回给用户的错误。

MOT使用返回码（Return Code，RC）返回Postgres标准错误代码至封装。某些RC会导致向正在与数据库交互的用户生成错误消息。

MOT从内部返回Postgres代码（见下文）到数据库包，数据库封装根据标准的Postgres行为对其做出反应。

说明: 提示信息中的%s、%u、%lu指代相应的错误信息（如查询、表名或其他信息）。 - %s：字符串 - %u：数字 - %lu：数字

表 2 返回给用户并记录到日志文件的错误