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

P4 Server Administration Documentation | 2025.2

# Use the read-only replica

## Prerequisite

The steps on this page assume you have logged into the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. named london as the P4 user with the access level of `super`. See Permission levels and access rights in the `p4 protect` topic of P4 CLI Reference. That user can have any name, but for convenience the examples use `super`:

`p4 -u super login`

## Replica for reporting

You can perform all normal operations against the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'., which in this example is named london:

`p4 -p london:1666 `command``

To reduce the load on the target server, direct reporting (read-only) commands to the replica:

`p4 -p replica:1667 command`

Because the replica is running in `-M readonly -D readonly` mode, commands that read both metadata and depot file contents are available, and reporting commands (such as `p4 annotate`, `p4 changes`, `p4 filelog`, `p4 diff2`, `p4 jobs`) work normally. However, commands that update the server’s metadata or depot files are blocked.

## Commands that update metadata

Some scenarios are relatively straightforward: consider a command such as `p4 sync`. A plain `p4 sync` fails, because whenever you sync your workspace, the P4 Server must update its metadata (the "have" list, which is stored in the `db.have` table). Instead, use `p4 sync -p` to populate a workspace without updating the have list:

    p4 -u super -p replica:1667 sync -p //depot/project/...@1234

This operation succeeds because it does not update the server’s metadata.

Some commands affect metadata in more subtle ways. For example, many P4 Server commands update the last-update time that is associated with a specification (for example, a user or client specification). Attempting to use such commands on replica servers produces errors unless you use the `-o` option. For example, `p4 client` (which updates the `Update:` and `Access` fields of the client specification) fails:

    p4 -u super -p replica:1667 client replica_client

    Replica does not support this command.

However, `p4 client -o` works:

    p4 -u super -p replica:1667 client -o replica_client

and the client spec is output to STDOUT.

If a command is blocked due to an implicit attempt to write to the server’s metadata, consider the options described above, as well as the broker.

Some commands, like `p4 submit`, always fail, because they attempt to write to the replica server’s depot files. These commands are blocked by the `-D readonly` option.)

Your search for returned results