Replication checks

When you set up and test replication, be aware of:

What the replica server checks at startup
Guidelines for special situations

For replication checks:

Replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. refers to edge servers as well as replica servers.
Target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. refers to the server that is established by the replica's P4TARGET environment variable.

What the replica server checks at startup

When a replica server is started, it checks to ensure the setting of its lbr.replication configurable is correct for the environment in which it is running. If the setting of lbr.replication is incompatible with the storage in the environment, the replica's log file indicates the error:

Storage incompatibility	Replica log file error
Storage is shared between the replica and the target server, but `lbr.replication` is not set to shared.	`Replica cannot run! This replica server appears to share archive storage with its master server. However, the replica was not configured with lbr.replication=shared. Sharing archive storage without setting lbr.replication=shared can result in lost or damaged data. Please reconfigure this replica or contact Perforce Technical Support for assistance.`
Storage is not shared between the replica and the target server, but `lbr.replication` is set to shared.	`Replica cannot run! This replica server does not appear to share archive storage with its master server. However, the replica was configured with lbr.replication=shared. Setting lbr.replication=shared without sharing archive storage can result in transfer errors between servers. Please reconfigure this replica or contact Perforce Technical Support for assistance.`

The replica's pull or journalcopy thread checks whether its depots are shared with its target server.

The exceptions to this rule are that Archive depots and Remote depots are not checked because they are not routinely replicated. To learn about remote depots, see Remote depots and multi-server development.

How the replica checks for shared storage at startup

To check for shared storage at startup, the replica uses temporary binary files in the format described at Versioned file formats.

The replica creates a temporary binary file in each of its depots with the format:

depot-name/PerforceServerIdentities/server-id,d/1.1
For example,

Project1/PerforceServerIdentities/EdgeServer3,d/1.1

where Project1 is a depot, PerforceServerIdentities is the specific directory used for this check, and EdgeServer3,d/1.1 is the binary file storage for the EdgeServer3 file that identifies this replica.
The replica requests that the target server check if it can locate this file in each of its depots.
When the checks are done, the replica deletes the PerforceServerIdentities directory and its contents.

Service user super access to all depots

To create the PerforceServerIdentities files required for the checks, the service user configured for the replica must have super access to all depots. To learn more, see Permissions for service users under Types of users in P4 CLI Reference.

Ensure the service user protections are at the bottom of the protections table so later lines don't potentially remove required access. To learn more, see How protections are implemented.

If the service user doesn't have proper access, the replica log on startup might contain errors. For example:

//jam/PerforceServerIdentities/commit-standby - no permission for operation on file(s).
//jam/PerforceServerIdentities/commit-standby - must refer to client 'pluto'.

Guidelines for special situations

When setting up and testing replication, consider these guidelines:

Situation	Guideline
Absolute map path	Depots that use absolute depot map paths must have those paths checked to be compatible with the `lbr.replication` setting.
Graph and extension depots	The `p4 depots` command does not show depots of type graph A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot. or extension Custom logic that runs in a Lua engine embedded into the P4 Server. Extensions are an alternative to triggers. See the P4 Extensions Documentation.. To show the depot names and mappings: `p4 -F "%name% %map%" -ztag depots` `p4 -F "%name% %map%" -ztag depots -t graph` `p4 -F "%name% %map%" -ztag depots -t extension`
Shared	Where there are no absolute depot mappings and the storage is shared, the relative location of the depots can be set on both the target server and replica by using: `p4 configure set london#server.depot.root=/data/depots` `p4 configure set replica#server.depot.root=/data/depots` Alternatively, set the replica’s `server.depot.root` configurable to match the `Server root` value in the output of the `p4 info` command on the target server.
Use of a file transfer utility	When replicas are using a file transfer utility such as `rsync` to transfer depot files from the target server, make sure that `cache` is the setting of the `lbr.replication` configurable.