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

P4 Server Administration Documentation | 2025.2

# Standby and forwarding-standby

Standby and forwarding-standby servers support the same set of functionality as the Read-only replica and Forwarding replica servers, except that standby and forwarding-standby servers:

- Use `p4 journalcopy` and `p4 pull -L` for metadata replication. (The `pull -L` thread reads the numbered journal obtained by journalcopy and updates the state file to track journal entries applied to the database.)

- Allow the use of the `p4 failover` command for Failover against mandatory servers, and the use of `p4 failback` for Failback after failover.

  If you are considering whether to deploy standby or forwarding-standby servers for general replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. use, be aware that:

  - Performance of other servers could be degraded because replaying journalcopy’d metadata might be delayed on a mandatory standby or forwarding-standby server due to concurrent activity on that server.

  - Failover to either a standby or forwarding-standby server could be adversely affected because the failover process might take longer while the standby or forwarding-standby server catches up with the journal of the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. if the target server participates in the failover.

The `p4 journalcopy` thread:

- Writes journal records to a local numbered journal file. As a result, no database tables are locked.
- Uses a file in the server root directory, `statejcopy`, to track the last consistency point journalcopy’d from the source server journal.
- Updates the `statejcopy` file in the standby server.

The standby journal:

- Is a complete copy of the target server journal, and therefore cannot be filtered.
- Always appears as a numbered journal, such as `journal.41`, even for the current journal.

## Creating a Standby Server

### Prerequisites

- A server from which a checkpoint can be taken. A standby server must be created by using a checkpoint of its target server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'.. Conversion of a replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. of any other type to a standby is not supported. In what follows, we use the example of a commit server to act as the target server for a newly-created standby server.

- The steps on this page assume you have logged into the target server as the P4 user with the access level of `super`. See Permission levels and access rights in the `p4 protect` topic of P4 CLI Reference. That user can have any name, but for convenience the examples use `super`:

> `p4 -u super login`

### Preparing the commit server

1. On the commit server, add a service user (if needed) and assign its `Type` to be `service`. The service user name can be any valid P4 user name. To learn more, see Service users.

   `p4 -u super user -f serviceuser
   [...]
   Type: Service`

2. Save the user specification and close the editor.

3. Provide the serviceuser with a strong password:

   p4 -u super passwd serviceuser

4. Consider creating a group for your service users. See Group for service users (recommended).

5. The ticket for a service user defaults to unlimited in 2025.2 and later. For 2025.1 and earlier: To prevent the service user logins from timing out, you can use the p4 group command to add the service user to a group with the Timeout field set to `unlimited`. See Tickets and timeouts for service users.

6. Set the access level for the service user or service user’s group to `super` in your protections table. See Access level for service users.

7. Set the level of security to 4 or higher on the target server. See Server security levels.
   For example,
   $ p4 -u super configure set security=4
8. Set up the configuration for the standby server using a server spec form. For example:

       ServerID:     commit-standby
       Type:         server
       Address:      {standbyserver host}:{port number}
       Services:     standby
       Options:      nomandatory
       ReplicatingFrom:     {commit-server-ID}
       Description:    Standby server for {commit-server-ID}.
       DistributedConfig:
       	any#auth.default.method=ldap
       	any#auth.ldap.order.1=popeye
       	any#auth.ldap.userautocreate=1
       	any#db.monitor.shared=8192
       	...
       	any#server.allowpush=2
       	P4TARGET={server:port}
       	P4TICKETS={/path/to/p4tickets-file}
       	P4LOG={/path/to/logfile}
       	db.replication=readonly
       	lbr.replication=readonly
       	journalPrefix={/path/to/rotated/journal/commit-standby}
       	monitor=1
       	rpl.journalcopy.location=1
       	serviceUser={serviceuser-name}
       	startup.1=journalcopy -i 1
       	startup.2=pull -L -i 1
       	startup.3=pull -u -i 1

   where, under `DistributedConfig:`

   - The values in bold and {italics} represent values specific to your server.

   - Entries starting `any#` are configurables that have already been set on the commit server to apply to all servers. These entries cannot be changed in this form.

   - The `Options` field must be set to `nomandatory` until the standby is running and up to date. This field can then be changed to `mandatory`. To learn more, see the Failover topic.

9. Take a checkpoint of the commit server. You will use the checkpoint to create the standby server that can become the commit server during a Failover process.

### Preparing the standby server

1. Run the following command to restore metadata from the specified checkpoint:

   p4d -r /standby/p4root -jr commit.ckp.12345

2. Set the server ID for the newly-seeded standby server:

   p4d -r /standby/p4root -xD commit-standby

3. If the edge uses SSL/TLS, establish a trust for SSL/TLS connections between client and server:

       export P4TRUST=/path/to/.p4trust
       p4 -p ssl:{commit-server:port} trust

4. Create a login ticket for the service user by logging into the commit from the machine that the standby is running on:

       export P4TICKETS={/path/to/p4tickets-file}
       p4 -u {serviceuser-name} -p {commit-server:port} login

5. Start the standby as a daemon (-d), specifying the domain name or IP address of the server along with a port and the path to the journal, such as /opt/p4d/journalfile:

       p4d -d -p {standbyserver:port} -J /opt/p4d/journalfile

6. Confirm the server status with the command:

       p4 -u super -p {standbyserver:port} -Ztag info

7. Confirm that `serverServices` is set to standby and that `replica` is showing the server and port number of the commit server.

>     p4 -ztag info
>     [...]
>     ... ServerID commit-standby
>     [...]
>     ... replica commit-server:1666

### Failover readiness

If you want the standby server to be capable of becoming the new target server during Failover, fill out a Duplicate Server Request form at https://www.perforce.com/support/duplicate-server-request. Having the license ready reduces the risk of delay during a failover process.

## Monitoring a Standby Server

1. Use p4 servers -J to check the replication status of all standby replicas. For example:

   `p4 -u super servers -J`
   `commit-standby '2019/09/20 12:49:16' standby 1234/8779 1234/8779 wadL/1 1`

   If you want verbose output, use the `-Ztag` option:

       p4 -u super -Ztag servers -J
       ... ServerID commit-standby
       ... Updated 2019/09/20 12:49:16
       ... ServerType standby
       ... ServerOptions nomandatory
       ... PersistedJournal 1234
       ... PersistedSequence 8779
       ... AppliedJournal 1234
       ... AppliedSequence 8779
       ... JAFlags wadL/1
       ... IsAlive 1

2. Use p4 journalcopy -l command to determine the current copy position as detected by the replica:

       p4 -u super journalcopy -l

   which outputs;

       Current replica persisted journal state is: Journal 1234, Sequence 8779.

3. To check the status of the replica metadata replication from the target server (master), use the p4 pull -lj command:

       p4 -u super pull -lj

       which outputs:

       Current replica journal state is: Journal 1234, Sequence 8779.
       Current master journal state is: Journal 1234, Sequence 8779.
       The statefile was last modified at: 2019/09/20 12:49:16.
       The replica server time is currently: 2019/09/20 13:20:11 -0700 PDT

Your search for returned results