当前位置: 首页 > news >正文

PostgreSQL12恢复配置总结

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_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以前,使用这些参数中的最后一个,而忽略了之前的参数。

http://www.jsqmd.com/news/913868/

相关文章:

  • Fluent PBM后处理详解:Discrete vs. Continuous方法下,Number Density、n(L)、n(V)到底该选哪个?
  • CVE-2018-8174漏洞复现实验报告
  • 防火墙配置与外网访问
  • 别再为找不到引导盘发愁了!手把手教你解决Dell服务器安装CentOS7时的‘dracut’报错
  • 从51到STM32:为什么我建议你先学标准库再碰HAL库(附江科协视频推荐)
  • QTableView 简单使用(笔记)
  • 别再为投稿PDF乱码发愁了!Pattern Recognition Letters投稿文件类型选择全解析
  • 别再手动调资源了!Spark动态资源分配(Dynamic Allocation)在YARN/K8s上的保姆级配置指南
  • 从《原神》血条到VR菜单:拆解Unity Canvas三种渲染模式在真实项目里的应用
  • 如何快速提升GitHub访问速度:免费浏览器插件终极指南
  • Java打印避坑指南:用PDFBox和AWT精准控制纸张与边距(附完整代码)
  • 微信如何创建群投票|西瓜评选零门槛靠谱教程 - 投票小程序
  • 告别手动!为你的Unity项目打造一个AssetPostprocessor自动图片导入配置器
  • 三菱FX3U PLC串口通讯实战:从RS/RS2指令到Modbus RTU读取编码器数据
  • 群晖Docker跑OpenWrt旁路由,保姆级避坑指南(含macvlan网络配置详解)
  • 别再硬编码了!SAP MB51报表增强的优雅解法:利用隐式增强与自定义表动态扩展ALV
  • 破四唯、给企业放权、建黑名单——2026浙江职称评审迎来最严改革
  • 别再乱勾选MicroLIB了!STM32串口打印printf的两种配置方式详解(附避坑指南)
  • 从‘感觉’到‘算法’:智能家居中的模糊控制实战(以空调温控为例)
  • Jetson Orin Nano 修复 JetPack MISSING 与 OpenCV CUDA
  • TVA 对 CV 的代际超越逻辑(9)
  • Unity 2020.3 实战:从零到一打造你的第一个记忆翻牌游戏(附完整源码)
  • UE5 GAS实战:手把手教你为RPG角色创建生命值与法力值AttributeSet(含网络同步与预测配置)
  • 医疗器械无菌包装密封性测试:从破坏性抽检到无损全检的体系升级
  • 保姆级教程:用西门子博途V15给S7-1500 PLC配置Modbus TCP服务器(含DB块指针详解)
  • 防锈后生锈原因 工序间防锈 操作偏差 过程管控
  • TypeScript 编程中的模块系统:ESM 与 CommonJS 互操作
  • 从Matlab到边缘设备:手把手教你将训练好的U-Net模型导出为ONNX并在OpenCV DNN中部署
  • 别再死记硬背了!用“3-8译码器”和“数据选择器”的例子,彻底搞懂CPU地址总线和存储寻址
  • 从Fbank到WavLM:PyTorch声纹识别项目中的音频特征提取全攻略(附性能对比)