Failback after failover

Failback reestablishes the relationship between the commit or master server and the standby server to what it was prior to failover. Failback is common when the failover was done for testing purposes. Failback is also a valid choice after failover for disaster recovery or maintenance.

After a successful failover, the original standby server has taken over as the new commit or master server.

To make a failback possible, ensure that the original commit or master server is:

reconfigured as a standby before starting it
assigned the serverid of a standby server, and that this serverid is different from the serverid of the current commit or master server

Reseeding the original commit or master server

Generally, it is a best practice to reseed the original commit or master from the new commit or master before performing the failback steps. Consider the following:

If the original commit or master did not participate in the failover ...	If the original commit or master participated in the failover ...
... the old commit or master's metadata might contain transactions that did not make it to the original standby at the time of failover. Those transactions could reappear at failback. To avoid this possibility, reseed the original commit or master from the new commit or master before performing the failback steps.	... reseeding might not be necessary. However, if you have any doubts about metadata integrity, the safest option is to reseed the original commit or master from the new commit or master before performing the failback steps.

Failback steps

At the new commit or master server

Verify that the standby is pulling from new commit or master server by issuing p4 servers -J
Check the result, which might be something like:
commit '2019/07/09 16:41:36' commit-server 40/13642 40/13642 wadL/1 1
standby '2019/07/09 16:41:31' standby 40/10000 40/10000 wAdl/4 1
where 10000 is lower than 13642, which indicates that the standby is not yet fully caught up with the commit or master server.
Wait a moment, then reissue p4 servers -J to verify that standby is fully caught up with the commit or master server. For example:

commit '2019/07/09 16:41:36' commit-server 40/13642 40/13642 wadL/1 1
standby '2019/07/09 16:41:36' standby 40/13642 40/13642 wAdl/4 1

At the new standby that was the original commit or master server

Issue the failover command: p4 failover
Follow the steps at Failover.