Replication basics

A command that can replicate both metadata and versioned files, and report diagnostic information about pending content transfers.

A replica server can run multiple p4 pull commands against the same master server. To replicate both metadata and file contents, you must run two p4 pull threads simultaneously: one (and only one) p4 pull (without the -u option) thread to replicate the master server’s metadata, and one (or more) p4 pull -u threads to replicate updates to the server’s versioned files.

A configuration mechanism that supports multiple servers.

Because p4 configure stores its data on the master server, all replica servers automatically pick up any changes you make.

A configuration mechanism that defines a server in terms of its offered services. To be effective, the ServerID field in the p4 server form must correspond with the server’s server.id file as defined by the p4 serverid command.

A command to set or display the unique identifier for a Helix Core Server. On startup, a server takes its ID from the contents of a server.id file in its root directory and examines the corresponding spec defined by the p4 server command.

Causes the replica to schedule a transfer of the contents of any damaged or missing revisions.

The command reports BAD! or MISSING! files with (transfer scheduled) at the end of the line.

For the transfer to work on a replica with lbr.replication=cache, the replica should have one or more p4 pull -u threads configured (perhaps also using the --batch=N flag.)

Helix Core Servers can be identified and configured by using a serverID.

When you use p4 server or p4 configure on your master server, you can specify different sets of configurables for each named server. Each named server, upon startup, reads the server.id file in the P4ROOT directory to determine its serverID. This enables the server to refer to its own set of configurables and ignore the configurables set for other servers.

A type of user intended for authentication of server-to-server communications. Service users have extremely limited access to the depot and do not consume Helix Core Server licenses.

To make logs easier to read, create one service user on your master server for each replica or proxy in your network of Helix Core Servers .

Replica servers can be configured to automatically reject user commands that attempt to modify metadata (db.* files).

In readonly mode, the Helix Core Server denies any command that attempts to write to server metadata. In this mode, a command such as p4 sync (which updates the server’s have list) is rejected, but p4 sync -p (which populates a client workspace without updating the server’s have list) is accepted.

Replica servers can be configured to filter in (or out) data on client workspaces and file revisions.

• To provides fine-grained control over what data is replicated, using the ClientDataFilter:, RevisionDataFilter:, and ArchiveDataFilter fields of the p4 server form.
  • Alternatively, to explicitly filter out updates to entire database tables, use the -T tableexcludelist option with p4 pull.
• To create a filtered checkpoint based on a serverId, use the p4d command with the -P serverId -jd options.

Replica servers can be configured to automatically reject user commands that attempt to modify archived depot files.

As with the Helix Proxy, you can use P4TARGET to specify the master server or another replica server to which a replica server points when retrieving its data.

You can set P4TARGET explicitly, or you can use p4 configure to set a P4TARGET for each named replica server.

A replica server with P4TARGET set must have both the -M (metadata access) and -D (depot access) options.

Alternatively, use the equivalent configurables:

• db.replication (access to metadata)
• lbr.replication (access the depot’s library of versioned files)

Use the startup.n (where n is an integer) configurable to automatically spawn multiple p4 pull processes on startup.

Replica servers track the most recent journal position in a small text file that holds a byte offset. When you stop either the master server or a replica server, the most recent journal position is recorded on the replica in the state file.

Upon restart, the replica reads the state file and picks up where it left off. Do not alter this file or its contents. (When the state file is written, a temporary file is used and moved into place, which should preserve the existing state file if something goes wrong when updating it. If the state file is empty or missing, the replica server will re-fetch from the start of its last used journal position.)

By default, the state file is named state and it resides in the replica server’s root directory. You can specify a different file name by setting the statefile configurable.