Shared archives

Sharing archive files Versioned files that users submitted to a depot. is supported between a target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. and the server replicates it, but replica servers cannot share archives with other replica servers.

Typical replication

Shared archives

Typically, a 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. server retrieves both its metadata and file archives from the target server on the user-defined pull interval. For example p4 pull -i 1 This configuration requires the P4TARGET server to send the archives files to the replica.

If a replica server is configured to share the same physical archive files as the target server: The replica accesses the archives directly, so archive files are not transferred. The replica and target server can: run on the same machine, or share storage over a network shared storage, where network latency affects performance.

To share archives, on the replica, set the lbr.replication configurable to shared either in the server spec or manually. Be aware that:

• Only metadata is retrieved on the pull interval.
• The shared archive files are not retrieved until requested by a client.
• New files are not automatically transferred.
• Purged files are not removed.

Shared archives can form part of a High Availability configuration.

To configure a replica to share archive files with a target server

1. Ensure that the clocks for the target server and replica servers are synchronized.

   Nothing needs to be done if the target server and replica servers are hosted on the same operating system.

   Synchronizing clocks is a system administration task that typically involves using a Network Time Protocol client to synchronize an operating system’s clock with a time server on the Internet, or a time server you maintain for your own network.

   See http://support.ntp.org/bin/view/Support/InstallingNTP.

2. If you have not already done so, configure the replica or edge server. See Deployment architecture.

3. Ensure the replica server has access to write files to the absolute shared archive location IF there are any absolute depot map paths. The replica server enforces correct lbr.replication settings when archives are being shared. Therefore, the replica server needs to write files to the shared archive locations noted by any depot map paths. See Providing map information in the P4 CLI Reference.

4. Set server.depot.root on the target server and replica, or the commit and edge, to point to the shared archive location for relative depot map paths to use. For example, if london is the target server:
   
   p4 configure set london#server.depot.root=/data/depots
p4 configure set replica#server.depot.root=/data/depots

5. Set lbr.replication=shared either in the replica's server spec or manually using a command similar to this:

   p4 configure set replica#lbr.replication=shared

6. Restart the replica.

Result

The result of this configuration:

• Commands that would schedule the transfer of file content, such as p4 pull -u and p4 verify -t are rejected

• If startup configurables, such as startup.N=pull -u, are defined, the replica server attempts to run such commands. Because the attempt to retrieve archive content is rejected, the replica’s server log will contain an error similar to this:

  Perforce server error:
      2023/11/03 09:08:22 pid 87949 service-od@21131 background [p4d/2023.1/LINUX26X86_64/2442900] 'pull -u -i 1'
      This command is not used with a replica server which uses lbr.replication=shared.

See also

Replication checks