8.5. 设置 PostgreSQL 以运行 Debezium 连接器

PostgreSQL 的逻辑解码使用复制插槽。要配置复制插槽，请在 postgresql.conf 文件中指定以下内容：

wal_level=logical
max_wal_senders=1
max_replication_slots=1

这些设置指示 PostgreSQL 服务器，如下所示：

保证复制插槽可以保证保留 Debezium 所需的所有 WAL 条目，即使在 Debezium 中断期间也是如此。因此，务必要密切监控复制插槽以避免：

如需更多信息，请参阅 PostgreSQL 文档用于复制插槽。

设置 PostgreSQL 服务器以运行 Debezium 连接器需要数据库用户可以执行复制。复制只能由具有适当权限的数据库用户执行，并且仅对配置的数量的主机执行。

虽然默认情况下，超级用户具有必要的 REPLICATION 和 LOGIN 角色，如 Security 中所述，最好不要为 Debezium 复制用户提供升级特权。相反，创建一个具有最低所需权限的 Debezium 用户。

来自为表创建的 publications 的 PostgreSQL 源表的 Debezium 流改变事件。出版物包含一组过滤的更改事件，这些事件由一个或多个表生成。每个发布中的数据会根据发布规格进行过滤。规范可由 PostgreSQL 数据库管理员或 Debezium 连接器创建。要允许 Debezium PostgreSQL 连接器创建发布并指定要复制到它们的数据，连接器必须使用数据库中的特定权限运行。

有几个选项可用于确定如何创建发布。通常，在设置连接器前，最好为要捕获的表手动创建发布。但是，您可以以允许 Debezium 自动创建发布的方式配置您的环境，并指定添加到其中的数据。

Debezium 使用 list 和 exclude list 属性来指定如何在发布中插入数据。有关启用 Debezium 创建发布的选项的更多信息，请参阅 publication.autocreate.mode。

要使 Debezium 创建 PostgreSQL 发布，它必须以具有以下权限的用户运行：

要向发布添加表，用户必须是表的所有者。但是，由于源表已存在，您需要一种与原始所有者共享所有权的机制。要启用共享所有权，您可以创建一个 PostgreSQL 复制组，然后将现有的表所有者和复制用户添加到组中。

对于 Debezium 指定捕获配置，必须将 publication.autocreate.mode 的值设置为 过滤。

要启用 Debezium 复制 PostgreSQL 数据，您必须将数据库配置为允许使用运行 PostgreSQL 连接器的主机进行复制。要指定允许使用数据库复制的客户端，请在基于 PostgreSQL 主机的身份验证文件 pg_hba.conf 中添加条目。有关 pg_hba.conf 文件的更多信息，请参阅 PostgreSQL 文档。

在某些情况下，PostgreSQL 磁盘空间可以被 WAL 文件使用，以激增或增加通常的比例。这种情况下有几个可能的原因：

由于复制插槽只能由单个连接器使用，因此每个 Debezium 连接器都需要创建一个唯一的复制插槽。虽然当连接器没有激活时，Postgres 可能会允许其他连接器消耗复制插槽 - 这可能会导致数据丢失，因为插槽将只发出每个更改 [请参阅 more]。

除了复制插槽外，Debebe 使用发布来流传输事件，在使用 pgoutput 插件时。与复制插槽类似，发布在数据库级别，并定义为一组表。因此，您需要为每个连接器有一个唯一的发布，除非连接器可用于同一组表。有关启用 Debezium 创建发布的选项的更多信息，请参阅 publication.autocreate.mode

有关如何为每个连接器设置唯一的复制插槽名称和发布名称，请参阅 slot.name 和 publication.name。

当升级 Debezium 使用的 PostgreSQL 数据库时，您必须执行特定的步骤来防止数据丢失，并确保 Debezium 继续操作。通常，Debezium 能够应对网络故障和其他中断导致的中断。例如，当连接器监控的数据库服务器停止或崩溃时，在连接器重新建立与 PostgreSQL 服务器的通信后，它会继续从日志序列号(LSN)偏移记录的最后位置读取。连接器从 Kafka Connect offsets 主题检索有关最后一次记录的偏移信息，并查询配置的 PostgreSQL 复制插槽以获取具有相同值的日志序列号(LSN)。

要使连接器启动和捕获 PostgreSQL 数据库中的更改事件，必须存在复制插槽。但是，作为 PostgreSQL 升级过程的一部分，复制插槽会被删除，在升级完成后不会恢复原始插槽。因此，当连接器重启并请求复制插槽的最后已知的偏移时，PostgreSQL 无法返回信息。

您可以创建新的复制插槽，但您必须有超过创建新插槽才能防止数据丢失。新的复制插槽只能为创建插槽后发生的更改提供 LSNs；无法为升级前发生的事件提供偏移量。当连接器重启时，它会首先从 Kafka offsets 主题请求最后已知的偏移量。然后，它会向复制插槽发送请求，以返回从偏移主题中检索的偏移信息。但是，新的复制插槽无法提供连接器从预期位置恢复流所需的信息。然后，连接器会跳过日志中任何现有更改事件，且只从日志中的最新位置恢复流。这可能导致静默数据丢失：连接器没有为跳过的事件发出记录，而不提供任何信息来指示这些事件已被跳过。

有关如何执行 PostgreSQL 数据库升级以便 Debezium 能够继续捕获事件，同时最大程度降低数据丢失的风险，请参阅以下步骤。