Open topic with navigation
Replication is the duplication of server data from one Helix Core to another Helix Core, ideally in real time. You can use replication to:
Provide warm standby servers
A replica server can function as an up-to-date warm standby system, to be used if the master server fails. Such a replica server requires that both server metadata and versioned files are replicated.
Reduce load and downtime on a primary server
Long-running queries and reports, builds, and checkpoints can be run against a replica server, reducing lock contention. For checkpoints and some reporting tasks, only metadata needs to be replicated. For reporting and builds, replica servers need access to both metadata and versioned files.
Provide support for build farms
A replica with a local (non-replicated) storage for client workspaces (and their respective have lists) is capable of running as a build farm.
Forward write requests to a central server
A forwarding replica holds a readable cache of both versioned files and metadata, and forwards commands that write metadata or file content towards a central server.
Combined with a centralized authorization server (see Centralized authorization server (P4AUTH)), Perforce administrators can configure the Helix Broker (see The Helix Broker) to redirect commands to replica servers to balance load efficiently across an arbitrary number of replica servers.
Most replica configurations are intended for reading of data. If you require read/write access to a remote server, use either a forwarding replica, a distributed Perforce service, or the Helix Proxy. See Configuring a forwarding replica, Commit-edge Architecture and Helix Proxy for details.