Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Reference | 2025.1

# p4 failover

Fail over to a standby server.

## Syntax

    p4 failover [-y] [ -m | [-i] -s serverID ] [-w waitForQuiesce] [-v verificationTime] [failoverMessage]

Syntax conventions

## Description

Allows the administrator of a standby server to initiate the process of failing over from the current target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. to its standby server. In this context, the target server is the server from which the standby server makes its journalcopy (see p4 journalcopy). The target server can also be an edge server. The standby server can be either a standby server or forwarding-standby server.

Failing over to a "mandatory" (see p4 server Options:) standby when the target server is not part of the failover process ensures that none of the downstream replicas will be ahead of the new target server.

- For the local High Availability standby server, we recommend mandatory, but only after journalcopying is complete.
- For the remote Disaster Recovery standby server, we recommend nomandatory

To learn more, see the Failover topic in the Backup and recovery chapter of P4 Server Administration Documentation.

2020.2 and later | Prior to 2020.2
--- | ---
Failover from a mandatory standby server when the target server is not participating includes checking the ReplicatingFrom field of the standby server spec for the target server's serverID when -s is not specified on the command line. | Failover from a mandatory standby server when the target server is not participating used to require specifying -s <serverID>.
Part of the failover process involves stopping the journalcopy and pull threads. If the failover process fails, any pull -L, pull -u, or journalcopy threads that were configured using startup.N configurables will automatically be restarted. | If the failover process fails, the journalcopy and pull threads needed to be restarted manually.

## Options

`-y` | Perform the failover operation. Without this option, `p4 failover` merely reports what it would do. Carefully consider the report of what failover would do BEFORE you include the -y option and launch the operation. During the failover process, end-user clients cannot issue commands against the server.
-v | Specifies the verificationTime as a number of seconds prior to the launch of the failover command. The default value of 300 seconds means that any file content that was updated from 1 - 300 seconds prior to launch of failover will be verified. This is to ensure that this file content will be correct when the failover process completes on the new target server. The failover command proceeds as soon as it has determined that the new target server has received correct file content. The legal range is between 0 (no verification) and 43200 seconds (12 hours).
`-w` | The waiting period in seconds for commands in the target server to complete. At the end of this quiesceWait period, all user commands, regardless of their activity, will be stalled. If -w is not specified, the default quiesceWait value is 60 You can set the waiting period to any integer value between 0 (immediate) and 3600 seconds (1 hour). To cancel the failover during the quiesceWait period, press Ctrl-C
`-i` | Ignore the original target server, even if it is accessible. This option and the -m option are mutually exclusive. Using the -i flag when the target server is accessible can result in an undesirable "split-brain" scenario in which two target servers process divergent datasets.
`-m` | The target server is required to participate in failover, which excludes the -i option. If the target server cannot be accessed by the standby server, the failover will not occur.
-s | If the existing target server participates in failover, the new target server automatically gets the serverID of the old target server and this option is not required. Prior to 2020.2, if the standby server could not access the target server, this option was necessary to specify the serverID of the target server. For 2020.2 and later, if the standby server cannot access the target server, there is automatic checking the ReplicatingFrom field of the standby server spec for the target server's serverID when -s is not specified on the command line.
failoverMessage | If the target server participates in the failover operation, failoverMessage is the text to display to end-users during the failover operation when end-users attempt to start new commands on the target server. The default message is: Server currently in failover mode, try again after failover has completed The failoverMessage must be the final argument specified in the p4 failover command. For example, p4 failover -w 90 -v 500 -y The Perforce server is undergoing scheduled maintenance and quotation marks are not required.
`g-opts` | See Global options

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
N/A | N/A | `super`

## Related commands

To copy journal data from a target server to the local file system of a standby replica | `p4 journalcopy`
To copy the file content of the files that have been added or updated (according to the replicated journal data) | `p4 pull -u`
To retrieve the journal records from the journalcopy files created by the `p4 journalcopy`, and to apply these to the standby’s database | `p4 pull -L`
To reestablish the relationship between the commit server and the standby server to what it was prior to failover | p4 failback

Your search for returned results