PG守护进程（Postmaster）——PostgreSQL 12恢复配置总结

最新推荐文章于 2024-12-16 14:49:23 发布

肥叔菌

最新推荐文章于 2024-12-16 14:49:23 发布

阅读量2.6k

点赞数 2

CC 4.0 BY-SA版权

分类专栏： # PostgreSQL 文章标签： postgresql 数据库 database

本文链接：https://blog.csdn.net/asmartkiller/article/details/121412144

PostgreSQL 专栏收录该内容

310 篇文章

订阅专栏

PostgreSQL V12中没有了recovery.conf。从向后兼容的观点来看，PostgreSQL v12中最大的变化是recovery.conf文件中的参数放到了postgresql.conf配置文件中。

本文主要介绍他们的变化以及如何适应。

放弃recovery.conf

在PG12以前，如果数据目录存在recovery.conf文件，当PG实例启动时将进入恢复模式（recovery或standby）,该文件包含了用于配置恢复的所有参数，例如：
standby_mode：确定这是正常的归档恢复还是standby模式
restore_command：此命令恢复已归档的WAL段
recovery_target*：此参数确定要恢复到的点
primary_conninfo：如何连接到流复制主服务器
长期以来，recovery.conf一直被认为是一个缺陷，因为配置参数分布在多个不同的文件中是不合理的，另外还不能使用ALTER SYSTEM命令对参数进行修改。

从v12开始，针对此问题进行了改进，把recovery.conf中的参数合到了postgresql.conf配置文件中，但在非恢复模式这些参数将被忽略。这个修改对PG新手来说更加的自然，但是对PG老油条估计得适应以下方面。

如何告诉PostgreSQL进入恢复模式？

在PG12以前，recovery.conf该文件的存在即触发恢复模式。
从PG12开始，由于该文件不存在，由下面两个新文件进行替换：

recovery.signal：告诉PostgreSQL进入正常的归档恢复
standby.signal：告诉PostgreSQL进入standby模式

如果两个文件都存在，则standby.signal优先。这些文件不需要包含任何数据，存在的任何数据将被忽略，只要存在就有意义。如果提升了备用数据库，则将完全删除standby.signal（而不是像recovery.conf那样重命名，变成recovery.done）。同样，如果正在进行时间点恢复，则一旦达到恢复目标，recovery.signal将被删除（除非将recovery_target_action设置为shutdown）。请注意：与recovery.conf一样，目录中缺少这些文件将导致PostgreSQL实例立即作为主实例启动，无论postgresql.conf是否包含复制配置。

恢复参数有哪些变化？

先前存储在recovery.conf中的恢复配置参数大部分没有变化，但以下情况除外。
standby_mode：先前的参数standby_mode已被删除，并已由上述standby.signal和recovery.signal文件代替。
trigger_file：参数trigger_file已重命名为promote_trigger_file。
在PG12以前，要将更改应用于recovery.conf，需要完全重启服务器。尽管这对PG12及以上版本也是正确的，但是现在可以通过SIGHUP更改以下恢复配置项：
archive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay
以下查询列出了所有以前的recovery.conf参数：

SELECT name,
       setting,
       category,
       short_desc,
       CONTEXT,
       pending_restart
  FROM pg_catalog.pg_settings
 WHERE category IN('Write-Ahead Log / Archive Recovery', 'Write-Ahead Log / Recovery Target')
    OR name IN ('primary_conninfo', 'primary_slot_name', 'promote_trigger_file', 'recovery_min_apply_delay')
 ORDER BY category,
          name;

恢复完成后参数会发生什么变化？

在PG12以前，恢复完成，recovery.conf被重命名为recovery.done，这有效地删除了恢复参数。
从PG12开始，恢复完成后将删除recovery.signal或standby.signal文件，但其中的参数postgresql.conf仍然保留。只要PostgreSQL不在恢复中，它们就会被忽略，但是最好用“#”注释禁用它们。这样可以避免以后出现令人讨厌的意外情况，例如在创建备用服务器时。
如果需要设置这些恢复参数建议使用ALTER SYSTEM，如果需要重置它们建议使用ALTER SYSTEM RESET。

在使用pg_basebackup工具时，如果使用了"–write-recovery-conf"选项会怎样？

在PG12中，选项仍然存在,但是它不再是创建recovery.conf文件，而是添加恢复配置参数。
与其将参数添加到postgresql.conf，不如和ALTER SYSTEM一样将其添加到postgresql.auto.conf。

如果我在PG12中使用recovery.conf进行恢复会发生什么？

PostgreSQL 12数据目录中的存在recovery.conf，将导致PostgreSQL实例拒绝启动，并出现以下错误：
FATAL: using recovery command file “recovery.conf” is not supported

如何调整我的备份脚本？

备份不受更改的影响。因此，您的备份脚本无需修改。
执行归档恢复或设置备用服务器的脚本必须进行修改。主要困难将是添加必要的恢复参数。
我的建议是将参数添加到postgresql.auto.conf，因为如前所述，该文件是为自动编辑而制作的。
这是bash要添加的一些示例代码recovery_target_time：

sed -i "/^recovery_target/d" $PGDATA/postgresql.auto.conf
sed -i "$ a recovery_target_time = '2020-05-19 13:00:00'" $PGDATA/postgresql.auto.conf

首先删除所有以"recovery_target"开头的选项，然后添加参数。
启动服务器之前，请不要忘记执行以下操作：
touch $PGDATA/recovery.signal
我建议您在恢复完成后再次删除恢复参数。

我正在使用一些第三方备份软件-我该怎么办？

到现在为止，任何值得其使用的专用PostgreSQL备份软件都应该已经适应了这些更改，升级到当前版本。
PostgreSQL v12对最广泛使用的程序的支持：
pgBackRest：支持2.18版以上的v12
pg_probackup：支持从2.2.5版本开始的v12
Barman：支持2.9版以上的v12

有哪些需要注意的事项？

从表面上看，与管理其它参数一样，但是在行为上发生了一些潜在的改变。

ALTER SYSTEM设置始终优先处理
如果恢复设置存储在postgresql.conf中，并且有人通过执行ALTER SYSTEM来更改设置，则ALTER SYSTEM设置的参数（并写入postgresql.auto.conf）将始终优先。如果随后尝试更新postgresql.conf中的复制设置，并且未考虑设置也可能存在于postgresql.auto.conf中的可能性，则可能引起混乱，这也是上面再三建议写入postgresql.auto.conf文件
恢复配置设置甚至可以在主服务器上出现
任何已配置的恢复配置设置（例如primary_conninfo）都将由PostgreSQL读取，并且可以正常显示，但是它们的存在并不表示该节点是否为备节点。
没有固定的位置可以配置恢复参数
众所周知recovery.conf只有一个文件，可以写入恢复设置，这可以确保在服务器启动时可以读取它们。但从PG12开始，恢复设置可以位于具有常规PostgreSQL配置文件的任何位置。由于最后读取的配置参数具有优先权，因此有可能会忽略前面的参数，并且使用错误的设置会错误地启动PostgreSQL。编写恢复配置设置（例如pg_basebackup或repmgr）并且需要确保最后读取这些设置，因此需要将它们添加到postgresql.auto.conf文件中。
信号文件混乱的风险
由于已将standby_mode参数替换为创建两个信号文件之一，并且由于standby.signal的优先级高于recovery.signal，因此存在需要恢复时，设置了recovery.signal，但同时存在standby.signal文件导致恢复错误。
只能指定recovery_target类中的一个参数
如果PostgreSQL配置中存在多个recovery_target\recovery_target_lsn\recovery_target_name\recovery_target_time\recovery_target_xid之一，则实例将发出致命错误在启动时：
FATAL: multiple recovery targets specified
DETAIL: At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, recovery_target_xid may be set.
在PG12以前，使用这些参数中的最后一个，而忽略了之前的参数。