Standby and forwarding-standby server

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:

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 master journal, and therefore cannot be filtered (unlike a readonly or forwarding-replica)
  • always appears as a numbered journal, such as journal.41, even for the current journal

Creating a Standby Server

Prerequisites

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 legal Perforce user name. (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 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. See the Failover topic.

  8. Take a checkpoint of the commit server. You will it use to create the standby server that can become the commit 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. Log the service user into the commit server from the machine the standby server is running on:

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

  4. Start the commit standby replica.

  5. Confirm the server status with the command:

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

  6. 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 master 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 to determine the current copy position as detected by the replica:
    p4 -u super journalcopy -l
Current replica persisted journal state is: Journal 1234, Sequence 8779.

  3. To check the status of the replica 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: 2019/09/20 12:49:16.
    The replica server time is currently: 2019/09/20 13:20:11 -0700 PDT