Helix Core Server Administrator Guide: Multi-Site Deployment (2019.2)

Identifying your server

Giving your server a unique ID permits most of the server configuration data to be stored in the Helix Core server. This is an alternative to using startup options or environment variables. A unique server ID is essential for configuring replication because p4 configure settings are replicated from the master server to the replicas along with other metadata.

Configuring the following servers require the use of a server spec:

Type

Description

Commit server central server in a distributed installation
Edge server node in a distributed installation
Build server replica that supports integration with a build server (or build farm)
Standby server read-only replica that uses p4 journalcopy
Forwarding standby forwarding replica that uses p4 journalcopy

The p4 serverid command creates a small text file named server.id in the root directory of the server. The server executable, p4d, can also create this server.id file:

p4d -r $P4ROOT -xD

Tip
  • To see the server id, use p4d -xD or the p4 serverid command
  • If the response is "Server does not yet have a server ID", set the server ID with p4d -xD myServer
  • To change an existing server ID, delete the server.id file, then set the server ID

You can use the p4 server command to:

  • define a specification for each of the servers known to your installation
  • create a unique server ID that can be passed to the p4 serverid command, and to define the services offered by any server that, upon startup, reads that server ID from a server.id file

For example, you can set your master server id to myMaster and the replica id to myReplica:

p4 -p svrA.company.com:11111 serverid myMaster
Server myMaster saved.
p4 -p svrB.company.com:22222 serverid myReplica
Server myReplica saved.

You can use p4 configure on the master instance to control settings on both the master and the replica because configuration settings are part of the replicated metadata of a Helix server server.

For example, if you issue the following commands on the master server:

$ p4 -p svrA.company.com:11111 configure set myMaster#monitor=2
$ p4 -p svrA.company.com:11111 configure set myReplica#monitor=1

the two servers have different monitoring levels after the configuration data has been replicated. Therefore, if you run p4 monitor show against the master server, you see both active and idle processes because the monitor configurable is set to 2 for the master server. In contrast, if you run p4 monitor show against the replica, you see only active processes because 1 is the monitor setting.

A master and each replica is likely to have its own journal and checkpoint files. To ensure their prefixes are unique, use the journalPrefix configurable for each named server:

$ p4 -p svrA.company.com:11111 configure set myMaster#journalPrefix=/p4/ckps/myMaster
For server 'myMaster', configuration variable 'journalPrefix' set to '/p4/ckps/myMaster'
$ p4 -p svrA.company.com:11111 configure set myReplica#journalPrefix=/p4/ckps/myReplica
For server 'myReplica', configuration variable 'journalPrefix' set to '/p4/ckps/myReplica'