我已经按照以下步骤进行了切换和切回。
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
发布评论