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 Helix Core Server that automatically maintains a full or partial copy of the master server's metadata and that might contain related file content. The replica copies from its master 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.
Master server The innermost Helix Core server in a multi-server topology. A commit server can also be referred to as a master server. refers to the server that is the target server, which 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 master, 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 master 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 master server. (The exceptions to this rule are that Archive depots and Remote depots are not checked because they are not routinely replicated.)

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 master 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.

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 Helix Core Server. See also Git Connector and classic depot. or extension Custom logic that runs in a Lua engine embedded into the Helix Core Server and that does not require a runtime that is external to the server. Extensions are an alternative to triggers. See the Helix Core Extensions Developer Guide.. 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 master and replica by using: `p4 configure set master#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 master server.
Use of a file transfer utility	When replicas are using a file transfer utility such as `rsync` to transfer depot files from the master server, make sure that `cache` is the setting of the `lbr.replication` configurable.