在PostgreSQL 9.4.1中的切换和回切中是否为强制性参数recovery

编程入门 行业动态 更新时间:2024-10-26 21:35:43
本文介绍了在PostgreSQL 9.4.1中的切换和回切中是否为强制性参数recovery_target_timeline ='latest'?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧! 问题描述

我已经按照以下步骤进行了切换和切回。

I have followed below steps for switchover and switchback.

步骤1:-从10.xx10断开应用程序服务并执行以下操作

Step 1:- Disconnect application services from 10.x.x.10 and do the following

@Master(10.xx10)

pg_ctl -D / DATA_VEC / pgdata stop --mode = fast

@DR(20.xx20)

将DR提升为读写模式

步骤2:-从新的主服务器启动主服务器作为DR

Step 2:- Start master as DR from new primary

@Master(10.xx10) 创建 recovery.conf

standby_mode = 'on' primary_conninfo = 'user= password= host=20.x.x.20 port=9999 trigger_file = '/tmp/node1' restore_command = 'cp /DATA_VEC/restore/%f "%p"'

pg_ctl -D /DATA_VEC/pgdata start

升级新的备用数据库后,旧的主数据库未与新的主服务器(旧的备用数据库)同步日志

after promotion new standby, old primary not getting syncing with new primary server(old standby) Logs from DR server which was primary.

2019-12-01 18:46:56 IST LOG: database system was shut down in recovery at 2019-12-01 18:46:53 IST 2019-12-01 18:46:56 IST LOG: entering standby mode cp: cannot stat `/DATA_VEC/restore/00000002.history': No such file or directory 2019-12-01 18:46:56 IST LOG: 2019-12-01 18:46:56 IST LOG: restored log file "00000002000000000000000C" from archive 2019-12-01 18:46:57 IST LOG: consistent recovery state reached at 0/C000090 2019-12-01 18:46:57 IST LOG: record with zero length at 0/C000090 2019-12-01 18:46:57 IST LOG: database system is ready to accept read only connections 2019-12-01 18:46:57 IST LOG: started streaming WAL from primary at 0/C000000 on timeline 2 2019-12-01 18:46:57 IST LOG: replication terminated by primary server 2019-12-01 18:46:57 IST DETAIL: End of WAL reached on timeline 2 at 0/C000090. 2019-12-01 18:46:57 IST LOG: restored log file "00000002000000000000000C" from archive 2019-12-01 18:46:57 IST LOG: record with zero length at 0/C000090 2019-12-01 18:46:57 IST LOG: restarted WAL streaming at 0/C000000 on timeline 2 2019-12-01 18:46:57 IST LOG: replication terminated by primary server 2019-12-01 18:46:57 IST DETAIL: End of WAL reached on timeline 2 at 0/C000090.

@Master(10.xx10)

Pg_xlog内容

-bash-4.1$ cd pg_xlog -bash-4.1$ ll total 65552 -rw------- 1 postgres postgres 302 Dec 1 12:52 00000002000000000000000A.00000028.backup -rw------- 1 postgres postgres 16777216 Dec 1 13:52 00000002000000000000000B -rw------- 1 postgres postgres 16777216 Dec 1 14:28 00000002000000000000000C -rw------- 1 postgres postgres 16777216 Dec 1 12:52 00000002000000000000000D -rw------- 1 postgres postgres 16777216 Dec 1 12:52 00000002000000000000000E -rw------- 1 postgres postgres 41 Dec 1 13:57 00000002.history -rw------- 1 postgres postgres 83 Dec 1 13:57 00000003.history drwx------ 2 postgres postgres 4096 Dec 1 13:57 archive_status

@in restore_command位置内容:-

@in restore_command location content:-

-bash-4.1 $ cd / DATA_VEC /恢复/ -bash-4.1 $ ll 合计49156 -rw ------- 1 postgres postgres 16777216 Dec 1 18:45 00000002000000000000000A -rw- ------ 1个postgres postgres 16777216 Nov 30 21:22 00000002000000000000000B -rw ------- 1个postgres postgres 16777216 Dec 1 18:45 00000002000000000000000C -rw ----- -1个postgres postgres 83 Dec 1 18:45 00000003.history -bash-4.1 $

作为per_pg_xlog时间轴历史记录文件 00000003.history 到达备用数据库仍未从新的主数据库开始流式传输。

as per_pg_xlog timeline history file 00000003.historyarrived at standby still not starting streaming from new primary.

问题:- 1.是否是 recovery.conf 文件中的强制性参数 recover_target_timeline ='latest'

Question:- 1. Is it mandatory parameter recover_target_timeline='latest' in recovery.conf file" to get latest timeline id from new primary through streaming to start streaming replication?

2。如果是,是否适用于所有PostgreSQL版本?例如从9.3到11.5

2.If yes, is it for all PostgreSQL Version? like from 9.3 to 11.5

推荐答案

如果要使用回切功能,则必须设置 recovery_target_timeline ='latest',因为任何促销活动都会增加时间表。通常,针对特定情况使用固定的目标时间轴(即,您需要在脑裂,时间轴分散的场景之后恢复更改)。

If you want switch-back functionality, you will have to set recovery_target_timeline='latest', as any promotion will increment the timeline. Using a fixed target timeline is usually reserved for very specific cases (i.e., you need to recover changes after a split-brain, diverged-timeline scenario).

要回答您的问题具体问题:

To answer your specific questions:

  • 更多推荐

    在PostgreSQL 9.4.1中的切换和回切中是否为强制性参数recovery

    本文发布于:2023-10-29 02:58:51,感谢您对本站的认可!
    本文链接:https://www.elefans.com/category/jswz/34/1538533.html
    版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
    本文标签:强制性   参数   PostgreSQL   recovery

    发布评论

    评论列表 (有 0 条评论)
    草根站长

    >www.elefans.com

    编程频道|电子爱好者 - 技术资讯及电子产品介绍!