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 master The innermost Helix Core server in a multi-server topology. A commit server can also be referred to as a master server.. To learn more, see Checkpoint files.
The steps on this page assume you have logged into the edge as the Helix Core user with the access level of super. See Permission levels and access rights in the p4 protect topic of Helix Core Command-Line (P4) Reference. That user can have any name, but for convenience the examples use super:
p4 -u super login

Preparing the edge

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 Helix Core user name. To learn more, see Service users.

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

Save the user specification and close the editor.
Provide the serviceuser with a password:
```
p4 -u super passwd serviceuser
```
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
```
Save the group specification and close the editor to save the user.
Add the service group to the protections table with super capabilities:
```
p4 -u super protect
[...]
super group service * //...
```

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.

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

Restore metadata from the specified checkpoint of the edge:
```
p4d -r /standby/p4root -jr edge.ckp.12345
```
Set the server ID for the newly-seeded standby:
```
p4d -r /standby/p4root -xD standby-for-edge
```

If the edge uses SSL, establish a trust:

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

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
```
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
```
Confirm the status of the standby:
p4 -u super -p standby-for-edge:1999 -Ztag info
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

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

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.

To check the status of the standby metadata replication, 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