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:

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.
  • 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 valid Helix Core 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:
    5. 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:
    export P4TICKETS={/path/to/p4tickets-file}
p4 -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