Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Identifying your server

Giving your server a unique ID permits most of the server configuration data to be stored in the P4 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 central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'. to the replicas along with other metadata.

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

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

The p4 serverid serverid command can be used to create a small text file named `server.id` in the P4ROOT directory of the server. For example,

    p4 serverid UK-commit-1

The server executable, `p4d`, can also create this `server.id` file with the syntax:

    p4d -r $P4ROOT -xD serverid

For example, from the `P4ROOT` directory:

    p4d -r . -xD UK-commit-1

To see the server id, see the output of the `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 -r $P4ROOT -xD serverid

To change an existing server ID, delete the `server.id` file from the `P4ROOT` directory, then set the server ID.

## Define the server

After you create the ServerID, bring up the Server spec by using the p4 server command.
In this example, london is the name of the central server. Run these two commands:

    p4 -p svrA.company.com:11111 serverid london
    p4 server london

In the Server spec, specify a type of service, such as `commit-server`, in the `Services` field.

Two ways to set configurables:

Add configurable settings to the `DistributedConfig` field of the server spec. For example:

    DistributedConfig:
        monitor=2
        security=6

or run commands similar to these:

    p4 -p svrA.company.com:11111 configure set london#monitor=2
    p4 -p svrA.company.com:11111 configure set london#security=6

## After the configuration data has been replicated

A upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'. 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.

Run this command:

    p4 -p svrA.company.com:11111 configure set london#journalPrefix=/p4/ckps/london

The output is:

    For server 'london', configuration variable 'journalPrefix' set to '/p4/ckps/london'

Then run this command:

    p4 -p svrA.company.com:11111 configure set myReplica#journalPrefix=/p4/ckps/myReplica

The output is:

    For server 'myReplica', configuration variable 'journalPrefix' set to '/p4/ckps/myReplica'

Your search for returned results