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 <serverid> command can be used to create a small
text file named server.id in the P4ROOT directory of the server. The server executable, p4d, can also create this server.id file:
p4d -r $P4ROOT -xD <serverid>
- To see the server id, use
p4d -xDor the p4 serverid command - If the response is
"Server does not yet have a server ID", set the server ID withp4d -xD myServer - To change an existing server ID, delete the
server.idfile, 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.idfile
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 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/myMasterFor server 'myMaster', configuration variable 'journalPrefix' set to '/p4/ckps/myMaster'
$ p4 -p svrA.company.com:11111 configure set myReplica#journalPrefix=/p4/ckps/myReplicaFor server 'myReplica', configuration variable 'journalPrefix' set to '/p4/ckps/myReplica'
