On 2020/08/25 11:22, Michael Paquier wrote: > On Mon, Aug 24, 2020 at 03:56:43PM -0400, rams nalabolu wrote: >> I did the following steps to perform switchover >> 1) ran a checkpoint on primary. >> 2) verified secondary status and it is up to date with primary. >> 3) stopped primary using pg_ctl -mf i.e force. > > This is not a force mode, but the fast mode, where all existing > connections are forcibly stopped, and that the shutdown is clean, with > a shutdown checkpoint generated before finishing the shutdown > sequence. During this shutdown, the primary makes sure that all > standbys have flushed WAL up to the point of the shutdown checkpoint. > Note that this makes rather unnecessary the checkpoint you ran on the > primary in step 1. > >> 4) promoted primary using trigger file and verified the status of the new >> primary; it is not in recovery mode and running on new timeline ID 2. > > I think that you mean promotion of the standby here. > >> 5) I did create the recovery.conf file on old primary i.e new standby with >> primaray_coninfo: new primary(B) >> recovery_target_timeline='latest' >> primary_slot_name: "slot I created in new_standby"
Did you enable standby_mode?
> > Typo here. You mean primary_conninfo. > >> 6) I started the new standby. It is up and running but it is not in >> recovery mode. > > This switchover flow is a good base, so it should be possible to reuse > your previous primary as a standby. > >> But the wal sender process on primary and receiver process on secondary are >> not running. i.e it looks like my replication is broken. >> what steps am I missing here without rebuilding a new standby i.e old >> primary I want the replication happen b/w my new primary and >> secondary. > > It may be many things without more information. Could you check > pg_stat_replication on the primary and pg_stat_wal_receiver on the > standby? Most likely something is wrong with primary_conninfo, but > the logs of the standby should have enough information to let you know > what happened. Another thing you are not telling is the version of > PostgreSQL you are using here. In 12 and newer versions, > support for recovery.conf has been removed, requiring roughly the > creation of standby.signal with all recovery parameters set in > postgresql.conf if you want to set up a standby. > -- > Michael >
-- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
