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(注意可用版本为12-15,16版本已经删除此参数可以使用pg_ctl promote 或 pg_promote() )。在PG12以前要将更改应用于recovery.conf需要完全重启服务器。尽管这对PG12及以上版本也是正确的但是现在可以通过SIGHUP更改以下恢复配置项archive_cleanup_commandpromote_trigger_filerecovery_end_commandrecovery_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_timesed -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版以上的v12pg_probackup支持从2.2.5版本开始的v12Barman支持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以前使用这些参数中的最后一个而忽略了之前的参数。