Standby and forwarding-standby server

Helix Core server 2019.1 introduced replication improvements with a standby server (or a forwarding standby server), which provide advantages over using a Read-only replica:

  • no transactions are lost if the master fails
  • the p4 pull command no longer needs to acquire database locks
  • all journal records are pulled before the p4 pull command goes to sleep

A standby server splits the pull command process into the p4 journalcopy and p4 pull -L commands.

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 position read in the source server journal
  • updates the statejcopy file in standby server

In replicas other than standby servers, the pull thread updates the state file.

The standby journal:

  • is a complete copy of the master journal
  • always appears as a numbered journal, such as journal.41, even for the current journal

Creating a Standby Server

Prerequisite: A server from which a checkpoint can be taken. A standby server must be created by using a checkpoint of its master. Conversion of a replica 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 master for a newly-created standby server.

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 legal Perforce user name. (See Service users)

    p4 user -f serviceuser
    [...]
    Type: Service

  2. Save the user specification and close the editor.
  3. Create a service group, add the serviceuser to the group, and set the Timeout field to unlimited:
    p4 group service
    [...]
    Timeout: unlimited
    [...]
    Users:
        serviceuser
  4. Save the group specification and close the editor to save the user.
  5. 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
Note

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 commit server, which you can use to create the commit-standby server.

Preparing the standby server

  1. Create a server.id file in the P4ROOT directory of the commit-standby server that contains the server id for this server, which is commit-standby. Change directory to the standby root directory and enter the command:

    echo commit-standby > server.id

  2. Log the service user into the commit server from the machine the standby server is running on:

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

  3. Start the commit standby replica.

  4. Confirm the server status with the command:

    p4 -p {standbyserver:port} -Ztag info

  5. 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

Monitoring a Standby Server

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

    p4 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 -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 to determine the current copy position as detected by the replica:

    p4 journalcopy -l

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

  3. To check the status of the replica meta-data replication, use the p4 pull -lj command:

    p4 pull -lj
    Current replica journal state is: Journal 1, Sequence 8779.
    Current master journal state is: Journal 1, 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

    This command both applies the journal from a local file and maintains the replica server's state file, which is located in the replica server's root directory.

Obtaining A Duplicate License

Although the standby server can operate without a license as a replica, a license error at startup will occur if you attempt to start a standby server as a standard services (commit) server. To prevent this problem when a failover occurs, submit a Duplicate Server Request as part of your failover planning.