Helix server replication

This topic assumes you have read the Introduction to multi-site deployment architectures.

Replication is the duplication of server data from one Helix Core server to another Helix Core server, 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, reports, and checkpoints can be run against a replica server that only contains metadata. Situations where files are being synced or reports need access to physical archive files will mean that the replica should also have a copy of the archive 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. A forwarding replica offers a blend of the functionality of the Helix Proxy with the improved performance of a replica. (See Configuring a forwarding replica.)

Combined with a centralized authorization server, Helix server administrators can configure the Helix Broker to redirect commands to replica servers to balance load efficiently across an arbitrary number of replica servers. See Centralized authorization server (P4AUTH) and Helix Broker.