Read-only replica as warm standby

Although it is possible for a read-only replica to be used as warm standby server, since the 2019.1 Helix Server release we recommend the use of standby servers for ease of management and failover. See Standby and forwarding-standby server.

However, if you want to use the pre-2019.1 technology, continue with this topic.

Pre-2019.1 information

To support warm standby servers, a replica server requires an up-to-date copy of both the master server’s metadata and its versioned files.

Tip

To help the standby server stay as current as possible with the master server, consider setting the rpl.journalcopy.location configurable. The value of 1 could keep the standby server's journalcopy more current with the master server's journal by writing the journalcopy to a faster device than the device in the journalPrefix configurable defined for the standby server.

Note

Replication is asynchronous, and a replicated server is not recommended as the sole means of backup or disaster recovery. We recommend that you maintain a separate set of database checkpoints and depot backups.

In addition, see the Failover topic.

Disaster recovery and failover strategies can be complex and site-specific, in which case Perforce Consultants are available to assist organizations in planning and deployment.

The following extended example configures a replica as a warm standby server for an existing Helix Core Server with some data in it. For this example, assume that:

  • Your master server is named Master and is running on a host called master, using port 1666, and its server root directory is /p4/master.
  • Your replica server will be named Replica1 and will be configured to run on a host machine named replica, using port 1667, and its root directory will be /p4/replica.
  • The service user name is service.
Note

You cannot define P4NAME using the p4 configure command because a server must know its own name to use values set by p4 configure.

You cannot define P4ROOT using the p4 configure command because it is important to avoid the risk of specifying an incorrect server root.

Important

To avoid configuration problems, the value of serverID should always match the value of P4NAME if both are set. We recommend setting serverID, but support P4NAME for backward compatibility.