Failback after failover

After a Failover with target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. participation, the failback procedure restores the previous role of that server. Optionally, the pre-failover standby server is restored to its original role.

In what follows, "server" refers to an instance of P4D, the P4 Server software, and "machine" refers to the physical hardware on which an instance of P4 Server runs.

Prerequisites for using the failback command

  1. Both the target server and the standby servers must be version 2022.1 or later.

  2. The original p4 failover command must have been performed with the participation of the target server.

  3. The p4 failback command must be performed with the participation of the target server.

  4. When the target server is an edge server with a standby (or forwarding standby) server, the failback command requires the participation of the commit server that is the target for that edge server.

  5. The server ID for the failed-over server must not be manually altered prior to performing the Procedure for using the failback command.

  6. Journals created after failover or failback must still exist in their expected location before the standby-to-be is started as a standby. In other words, keep the journal locations and journals from failover through completion of all intended failback operations.

In addition, we recommend using two DNS aliases:

  • One DNS alias points to the IP address of the target server. This allows the same DNS alias to point the new target server (former standby server).

  • A second DNS alias points to the IP address of the standby server.

Scenario for this example

The commit server and its standby go down as part of the failover and failback to take them out of use and prevent data divergence.

  1. Before failover, a commit server, with the serverID of commit-uk, was running on MachineA, and a standby server, with the serverID of standby1, was running on MachineB. To learn about serverID, see p4 serverid in the P4 CLI Reference.

     

  2. After failover, MachineB hosts the commit server commit-uk and MachineA hosts the restricted standby standby1.

    Also, commit-uk on MachineB uses the same IP address that commit-uk on MachineA used prior to failover.

    Similarly, standby1 on MachineA uses the same IP address that standby1 on MachineB used prior to failover.

     

  3. After failback, commit-uk will be restored to its pre-failover role as a commit server running on MachineA.

    standby1 on MachineA will go down so that commit-uk on MachineA can use the same IP address that commit-uk on MachineA used prior to failover.

    Optionally, standby1 can be restored to its pre-failover role as a standby server that replicates its target server, commit-uk, in readiness for any future failover.

Procedure for using the failback command

Step Description

1.

 

On the MachineA, where commit-uk was running prior to failover, convert commit-uk to a restricted standby, which causes commit-uk to ignore configuration settings that would otherwise interfere with failback.

  1. Preview the p4d -Fm command described at Failback options:
    p4d -r p4root -Fm commit-uk standby1
    where the p4root location is the P4ROOT location of the pre-failover target server, commit-uk.

  2. If the preview looks acceptable, include the -y option:

    p4d -r p4root -y -Fm commit-uk standby1

2.

Start standby1 on MachineA and wait for its replication to catch up with commit-uk on MachineB.

3.

On MachineA:

  1. As the standby service user, log in to commit-uk on MachineB.

  2. Verify that the login ticket is stored in the file indicated by the standby server’s P4TICKETS configurable.

  3. Check whether failback is possible by running the p4 failback command.

  4. If so, run the p4 failback -y command. Otherwise, see If p4 failback cannot be used.

4.

 

After the completion of a successful failback,

  1. Verify that standby1 on MachineA has been restarted as commit server commit-uk on MachineA.

    To do this, run the p4 info command against the P4PORT of commit-uk to ensure the following lines are part of the output:

    ServerID: commit-uk
    Server services: commit-server

  2. Site-specific changes might be needed to use the new target server. It might be necessary to make DNS changes so that users and replicas can connect to the new target server. For example,

If you have a DNS alias set up for MachineA If you do not have a DNS alias set up for MachineA

Update the IP address of that DNS alias to point to the IP address of its new location.

After this is done, users will be able to connect to the commit-uk on MachineA by using the same P4PORT they used prior to failover.

The DNS alias for the standby server must be changed to point to the IP address of that standby1 used on MachineB prior to failover.

 

Update the P4TARGET environment variable and server specifications to use the correct host. The port number should remain the same, but the host name must be changed to use its new location.

  • Change your P4PORT to point to the MachineA and the same port number so that you can connect to commit-uk on MachineA.

  • On commit-uk on MachineA, change the P4TARGET for each replica or edge server by issuing the p4 configure show allservers command and then issuing the p4 configure set "replica-name#P4TARGET=commit-uk:port-number" command.

  • Update each replica's own P4TARGET by issuing the p4d -r $P4ROOT "-cset replica-name#P4TARGET=commit-uk:port-number"command.

  • Update your server specifications with the proper hostname and port number by issuing the p4 server servername command.

  • Inform your users if they need to update their P4PORT to connect to commit-uk on MachineA. The port number should remain the same as before, and your users can now issue new commands.

5.

(Optional) On MachineB, restore the P4 Server to its former status of being a standby server for commit-uk.

  1. Preview the p4d -Fs command described at Failback options:
    p4d -r p4root -Fs commit-uk standby1

  2. If the preview looks acceptable, include the -y option to perform the operation:
    p4d -r p4root -y -Fs commit-uk standby1

This command changes standby1 to a restricted standby. When standby1 discovers from replication that p4 failback has been successfully run, it will function as an unrestricted standby for commit-uk.

6.

 

(Optional) Change the standby server spec of standby1 to a mandatory standby by setting mandatory for the Options field.

A mandatory standby persists journalcopy'ed metadata before that metadata is replicated to other replicas, which can adversely affect replication performance. To learn more, see "mandatory standby" at Standby and forwarding-standby

If p4 failback cannot be used

Failback might still be possible even if the Prerequisites for using the failback command are not fully met.

Prerequisites if p4 failback cannot be used

Ensure that commit-uk on MachineB is reconfigured as a standby server before starting standby1 on MachineA, which must be configured as the target server for commit-uk.

Reseeding the original commit or central server

If p4 failback cannot be used, it is a best practice to reseed standby1 now running on MachineA before performing the failback steps.

Why you might want to reseed

Reason 1:

If commit-uk running on MachineA did not participate in the failover, the metadata for that server might contain transactions that had not been replicated to standby1 on MachineB at the time of failover. Those transactions could reappear at failback, so the safest option is to reseed.

Reason 2:

If commit-uk on Machine A did participate in the failover, reseeding might not be necessary. However, if you have any doubts about metadata integrity, the safest option is to reseed.

How to reseed

  1. From a checkpoint of the commit server commit running on MachineB, reseed the server running on Machine A as standby1. For a detailed walkthrough, see Replica server metadata recovery.

  2. Proceed with failback steps.

Failback steps if p4 failback cannot be used

Current status is after failover of commit-uk, such that commit-uk is running on Machine B and standby1 is running on MachineA.

At standby1 on MachineA

  1. Verify that commit-uk on MachineB is pulling from standby1 on MachineA by issuing p4 servers -J
  2. Check the result, which might be something like:

    commit-uk '2025/07/09 16:41:36' commit-server 40/13642 40/13642 wadL/1 1

    standby1 '2025/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 target server.

  3. Wait a moment, then reissue p4 servers -J to verify that standby is fully caught up with the target server. For example:

    commit-uk '2025/07/09 16:41:36' commit-server 40/13642 40/13642 wadL/1 1

    standby1 '2025/07/09 16:41:36' standby 40/13642 40/13642 wAdl/4 1

At the commit-uk on MachineB

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