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

P4 Server Administration Documentation | 2026.1

# Replication commands and configurables

Replication of P4 Servers depends upon these commands, environment variables, and configurables:

Command or Feature | Typical use case
--- | ---
`p4 pull` | A command that can replicate both metadata and versioned files, and report diagnostic information about pending content transfers. A replica server can run multiple `p4 pull` commands against the same target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'.. To replicate both metadata and file contents, run two `p4 pull` threads simultaneously: One (and only one) `p4 pull` (without the `-u` option) thread to replicate the target server’s metadata, and One (or more) `p4 pull -u` threads to replicate updates to the server’s versioned files.
`p4 configure` | A configuration mechanism that supports multiple servers. Because `p4 configure` stores its data on the target server, all replica servers automatically pick up any changes you make.
`p4 server` | A configuration mechanism that defines a server in terms of its offered services. To be effective, the `ServerID` field in the `p4 server` form must correspond with the server’s `server.id` file as defined by the p4 serverid command.
`p4 serverid` | A command to set or display the unique identifier for a P4 Server. On startup, a server takes its ID from the contents of a `server.id` file in its root directory and examines the corresponding spec defined by the `p4 server` command.
`p4 verify -t` | Causes the replica to schedule a transfer of the contents of any damaged or missing revisions. The command reports `BAD!` or `MISSING!` files with `(transfer scheduled)` at the end of the line. For the transfer to work on a replica with `lbr.replication=cache`, the replica must have one or more `p4 pull -u` threads configured (optionally using the `--batch=N` flag.) You can also run the p4 verify -S -t command on a replica to request re-transfer of a shelved archive that is missing or bad. Re-transferring a shelved archive from the target server only works if the shelved archive is on the target server because: The shelf was originally created on the target server, or The shelf was promoted from an edge server,
Server names `server.id` | P4 Servers can be identified and configured by using a serverID. When you use p4 server or p4 configure on the target server, you can specify different sets of configurables for each named server. Each named server, upon startup, reads the `server.id` file in the P4ROOT directory to determine its serverID. This enables the server to refer to its own set of configurables and ignore the configurables set for other servers.
Service users serviceUser | A type of user intended for authentication of server-to-server communications. Service users have extremely limited access to the depot and do not consume P4 Server licenses. To make logs easier to read, create one service user on the target server for each replica or proxy in your network of P4 Servers .
Metadata access `db.replication` | Replica servers can be configured to automatically reject user commands that attempt to modify metadata (`db.*` files). In `readonly` mode, the P4 Server denies any command that attempts to write to server metadata. In this mode, a command such as `p4 sync` (which updates the server’s have list) is rejected, but`p4 sync -p` (which populates a client workspace without updating the server’s have list) is accepted.
Metadata filtering `p4 server` | Replica servers can be configured to filter in (or out) data on client workspaces and file revisions. To provides fine-grained control over what data is replicated, using the `ClientDataFilter:`, `RevisionDataFilter:`, and `ArchiveDataFilter` fields of the `p4 server` form. Alternatively, to explicitly filter out updates to entire database tables, use the `-T tableexcludelist` option with `p4 pull`. To create a filtered checkpoint based on a serverId, use the `p4d` command with the `-P serverId` -jd options. To learn more, see P4 Server (p4d) reference.
Depot file access `lbr.replication` | Replica servers can be configured to automatically reject user commands that attempt to modify archived depot files.
Mode | Server behavior
--- | ---
`readonly` | Accepts commands that read depot files, but denies commands that write to them. In this mode, `p4 describe` can display the diffs associated with a changelist, but `p4 submit` is rejected. However, edge servers do have the capability to write some files, such as shelved files, to the depot. A forwarding replica cannot write to archive files, but instead forwards the command to the target server.
`shared` | Accepts commands that read metadata, but does not transfer new files nor remove purged files from the target server. `p4 pull -u` and `p4 verify -t`, which would otherwise transfer archive files, are disabled. If a file is not present in the archives, commands that reference that file will fail. This mode must be used when a replica directly shares the same physical archives as the target, whether by running on the same machine or via network sharing. This mode can also be used when an external archive synchronization technique, such as `rsync`, is used for archives.
`cache` | Permits commands that reference file content, but does not automatically transfer new files. Files that are purged from the target are removed from the replica when the purge operation is replicated. If a file is not present in the archives, the replica will retrieve it from the target server, which might affect performance.
`none` | Denies any command that accesses the versioned files that make up the depot. In this mode, a command such as p4 describe ``changenum`` is rejected because the diffs displayed with a changelist require access to the versioned files, but `p4 describe -s `changenum`` (which describes a changelist without referring to the depot files in order to generate a set of diffs) is accepted.
Target server `P4TARGET` | As with the P4 Proxy, you can use P4TARGET to specify the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. or another replica server to which a replica server points when retrieving its data. You can set `P4TARGET` explicitly, or you can use `p4 configure` to set a `P4TARGET` for each named replica server. A replica server with `P4TARGET` set must have both the `-M` (metadata access) and `-D` (depot access) options. Alternatively, use the equivalent configurables: `db.replication` (access to metadata) `lbr.replication` (access the depot’s library of versioned files)
Startup commands `startup.1` | Use the `startup.n` (where `n` is an integer) configurable to automatically spawn multiple `p4 pull` processes on startup.
State file `statefile` | Replica servers track the most recent journal position in a small text file that holds a byte offset. When you stop either the target server or a replica server, the most recent journal position is recorded on the replica in the state file. Upon restart, the replica reads the state file and picks up where it left off. Do not alter this file or its contents. (When the state file is written, a temporary file is used and moved into place, which should preserve the existing state file if something goes wrong when updating it. If the state file is empty or missing, the replica server will re-fetch from the start of its last used journal position.) By default, the state file is named `state` and it resides in the replica server’s root directory. You can specify a different file name by setting the `statefile` configurable.
P4 Broker | The P4 Broker can be used for load balancing, command redirection, and more. See P4 Broker for details.

Replication requires uncompressed journals. Starting the target server using the `p4d -jc -z` command breaks replication. Instead, use the `-Z` flag instead to prevent journals from being compressed.

Your search for returned results