Replication checks

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

For replication checks:

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.

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

  2. The replica requests that the master server check if it can locate this file in each of its depots.

  3. 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 graphClosed 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 extensionClosed 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.