Re: PostgreSQL switchover process

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