Postgres复制槽

replication slots

当 PostgreSQL 使用 replication slots（复制槽）时，如果不谨慎使用或配置，可能会导致归档日志 (WAL 日志) 堆积，从而影响系统的正常运行。以下是一些可能导致这种情况发生的原因：

1. 复制槽未及时释放：

   • 如果业务使用了复制槽，但没有及时释放，就会导致归档日志堆积。
   • 复制槽是用于流复制的一种机制，如果某个槽一直处于活动状态，那么 PostgreSQL 就会保留相关的归档日志，以确保在复制槽重新连接时可以继续传递日志。

2. 未启用归档清理：

   • PostgreSQL 默认会保留所有的归档日志，不会自动清理。
   • 如果业务没有设置自动归档清理（archive_cleanup_command），并且没有定期手动清理归档日志，可能会导致 WAL 日志文件堆积。

3. 归档命令失败：

   • 如果通过归档命令将 WAL 日志推送到远程位置（如归档到远程存储），但这个过程失败，可能会导致归档日志堆积。
   • 应确保设置了合适的错误处理和监控机制，以便在归档失败时能够及时发现和解决问题。

4. 备份频繁且未清理：

   • 如果频繁执行基于归档的备份，但没有相应的清理策略，也可能导致堆积的归档日志。
   • 应考虑制定备份和清理策略，以确保系统稳定。

为了解决这个问题，您可以执行以下步骤：

• 检查正在使用的复制槽，并确保它们在不再需要时得到适时释放。
• 设置合适的 archive_cleanup_command，以自动清理不再需要的归档日志。
• 定期检查归档过程是否正常工作，特别是推送到远程存储的情况。
• 考虑合适的备份和清理策略，确保系统的可用性和性能。

使用姿势

正确使用 PostgreSQL 复制槽是确保流复制正常运行的关键部分。以下是一些建议，帮助业务正确使用复制槽：

1. 仔细选择复制槽的名称：

   • 复制槽的名称应该是唯一的，易于识别，并与业务或目的相关。
   • 避免使用可能引起混淆的通用名称。

2. 在业务开始时创建槽，在结束时释放槽：

   • 在业务开始进行流复制时，创建相应的复制槽，以便 PostgreSQL 保留 WAL 日志。
   • 在业务结束时释放槽，以确保 PostgreSQL 不再保留相应的 WAL 日志。

3. 使用合适的复制槽模式：

   • PostgreSQL 提供两种复制槽模式：physical 和 logical。选择合适的模式取决于业务需求。
   • physical 模式用于流复制，而 logical 模式用于逻辑复制。

4. 设置合适的 max_replication_slots：

   • 在 PostgreSQL 配置文件中设置 max_replication_slots 参数，以限制系统中的复制槽数量。
   • 确保为业务设置足够的复制槽数量，以满足并发流复制的需求。

show max_slot_wal_keep_size;

5. 定期监控复制槽的状态：

   • 使用 pg_stat_replication 视图和其他监控工具，定期检查复制槽的状态。
   • 确保复制槽正常运行，没有异常或延迟。

6. 备份复制槽状态和位置信息：

   • 在业务进行流复制之前，定期备份复制槽的状态和位置信息。
   • 这有助于在需要时恢复到先前的流复制状态。

7. 考虑业务的高可用性需求：

   • 如果业务对高可用性有要求，可以考虑使用复制槽以支持流复制中的热备份和故障转移。

8. 合理设置复制槽的 wal_level：

   • wal_level 参数定义了写入 WAL 的详细程度。为了支持流复制，应将 wal_level 设置为 logical 或 replica。

9. 合理设置其他相关参数：

   • 根据业务需求，确保正确设置了 max_wal_senders、max_wal_size、min_wal_size 等相关参数。

10. 文档化复制槽的使用：

• 为了团队的清晰理解和未来的维护，文档化复制槽的使用方法、目的和相关配置。

总体而言，正确使用 PostgreSQL 复制槽需要理解业务需求，并根据需求进行适当的配置和监控。合理的设置和管理复制槽将有助于确保流复制的可靠性和稳定性。

pg_logical_slot_peek_changes

pg_logical_slot_peek_changes is a function in PostgreSQL that provides the ability to peek changes from the logical replication slot. This means you can view the changes without actually consuming them (removing them from the replication slot).

Here’s the syntax:

SELECT * FROM pg_logical_slot_peek_changes(
    slot_name name, 
    upto_lsn pg_lsn, 
    max_changes integer, 
    options text[] DEFAULT '{}'
);

Parameters:

• slot_name: The name of the existing logical replication slot.

• upto_lsn: Get changes up to this Log Sequence Number (LSN). Use NULL to get all available changes.

• max_changes: Maximum number of changes to fetch. If NULL all changes are fetched (this could potentially consume a lot of memory on the client).

• options: An optional array of parameters for the output plugin.

Example

SELECT * FROM pg_logical_slot_peek_changes('my_replication_slot', NULL, NULL, NULL);

This will return all available changes from ‘my_replication_slot’ without actually consuming them.

Remember to replace 'my_replication_slot' with the name of your actual replication slot.

Logical decoding and replication slots are a complex topic related to replication and change data capture in PostgreSQL. Make sure you completely understand these concepts before using them.