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

P4 Server Administration Documentation | 2025.1

# Standby for an edge

You can create a standby server for an edge server. This standby can function as an up-to-date warm standby in case the edge becomes unavailable. The standby replicates the metadata and versioned files from the edge.

### Prerequisites for the standby

- An edge server from which a checkpoint can be taken because the standby must be created by using a checkpoint of the edge that functions as its target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'.. To learn more, see Checkpoint files.

- The steps on this page assume you have logged into the edge 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 edge

1. On the edge, add a service user to be used by the standby, 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 password:

       p4 -u super passwd serviceuser

4. Create a `service` group, add the `serviceuser` to the group, and set the `Timeout` field to `unlimited`:

       p4 -u super group service
       [...]
       Timeout: unlimited
       [...]
       Users:
           serviceuser

5. Save the group specification and close the editor to save the user.
6. Add the `service` group to the protections table with super capabilities:

       p4 -u super protect
       [...]
       super group service * //...

7. Set up the configuration for the standby by using a server spec form. For example, if the `serverID` is `standby-for-edge`, run the `p4 server standby-for-edge` command:

       ServerID:     standby-for-edge
       Type:         server
       Address:      {standbyedgeserver host}:{port number}
       Services:     standby
       Options:      nomandatory
       ReplicatingFrom:     {edge-ID}
       Description:    Standby server for {edge-ID}.
       DistributedConfig:
       	any#db.monitor.shared=8192
       	...
       	P4TARGET={edge-server:port}
       	P4TICKETS={/path/to/p4tickets-file}
       	P4LOG={/path/to/logfile}
       	db.replication=readonly
       	lbr.replication=readonly
       	journalPrefix={/path/to/rotated/journal/standby-for-edge}
       	monitor=1
       	rpl.journalcopy.location=1
       	serviceUser={serviceuser}
       	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`. See the Failover topic.

8. Take a checkpoint of the edge according to the guidelines at Checkpointing and types of servers. You will use the checkpoint of the edge to create the standby that can become the edge during a Failover process.

### Preparing the standby

1. Restore metadata from the specified checkpoint of the edge:

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

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

       p4d -r /standby/p4root -xD standby-for-edge

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:{edge-server:port} trust

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

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

5. Start the standby, running the daemon (`-d`) in the background and specifying a port (such as `1999`) and the path to the journal (such as `/opt/p4d/journalfile`):

       p4d -d -p 1999 -J /opt/p4d/journalfile

6. Confirm the status of the standby:

   p4 -u super -p standby-for-edge:1999 -Ztag info

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

>     p4 -ztag info
>     [...]
>     ... ServerID standby-for-edge
>     [...]
>     ... replica edge:1666

## Monitoring a standby-edge

1. Use p4 servers -J to check the replication status of the standby for the edge, which belongs to the set of all standby replicas. For example:

       p4 -u super servers -J
       standby-for-edge '2023/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 standby-for-edge
       ... Updated 2023/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 to determine the current copy position as detected by the standby:

       p4 -u super journalcopy -l
       Current replica persisted journal state is: Journal 1234, Sequence 8779.

3. To check the status of the standby metadata replication from the upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'. (master), use the p4 pull -lj command:

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

Your search for returned results