Helix Core Server Administrator Guide: Multi-Site Deployment (2019.2)

Configuring a replica with shared archives

Typical replication Shared archives

Typical replication	Shared archives
Typically, a replica server retrieves both its metadata and file archives from the master 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 master server: the replica accesses the archives directly, so archive files are not transferred the replica and master can: run on the same machine, or share storage over a network shared storage, where network latency affects performance.

Typically, a replica server retrieves both its metadata and file archives from the master 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 master server:

the replica accesses the archives directly, so archive files are not transferred
the replica and master 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:

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.

Note

Sharing archives is supported between a master server and a replica server, or between a commit server and an edge server. Replica servers can't share archives with other replica servers.

Warning

When archive files are directly shared between a replica and master server, the replica must have lbr.replication set to shared. Otherwise, the files in the archive might be corrupted.

To configure a replica to share archive files with a master

Ensure that the clocks for the master and replica servers are synchronized.

Nothing needs to be done if the master 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.
If you have not already done so, configure the replica server as a forwarding replica.

See Configuring the master server for the forwarding replica.
Set lbr.replication=shared either in the replica's server spec or manually using a command similar to this:

p4 configure set fwd-1667#lbr.replication=shared
Restart the replica, specifying the share archive location for the replica’s root.

Result

The result of this configuration:

archive file content is only retrieved when requested, and those requests are made against the shared archives.
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:
```
Perforce server error:
        2014/01/23 13:02:31 pid 6952 service-od@21131 background 'pull -u -i 10'
```
Note
For upgrading, see Upgrading replica servers.

Your search for returned result(s).