Replication commands and configurables

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 target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'..

To replicate both metadata and file contents, run two p4 pull threads simultaneously:

• One (and only one) p4 pull (without the -u option) thread to replicate the target 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 target 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 P4 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 must have one or more p4 pull -u threads configured (optionally using the --batch=N flag.)

You can also run the p4 verify -S -t command on a replica to request re-transfer of a shelved archive that is missing or bad. Re-transferring a shelved archive from the target server only works if the shelved archive is on the target server because:

• The shelf was originally created on the target server, or

• The shelf was promoted from an edge server,

P4 Servers can be identified and configured by using a serverID.

When you use p4 server or p4 configure on the target 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 P4 Server licenses.

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

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

In readonly mode, the P4 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, butp4 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. To learn more, see P4 Server (p4d) reference.

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

As with the P4 Proxy, you can use P4TARGET to specify the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central 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 target 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.