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.

Tracks the metadata pull thread position in the upstream journal stream, including the journal number and byte offset. The replica records this position in the state file and uses it to resume replication after a restart. The p4 pull -lj command reads this file to report replication status.

By default, the file is named state and is stored in P4ROOT. Configure a different file name by setting the statefile configurable.

The state file does not need to be included in checkpoint-based backups. The server manages this file automatically. Do not modify or edit the state file manually unless a recovery procedure explicitly instructs you to do so.

When updating the state file, the server writes to a temporary file and then moves it into place to preserve the existing file if an error occurs.

If the state file is missing, empty, or becomes corrupt:

1. Stop the server.

2. Remove the state file(s).

3. Start up the server.

The server creates a new state file during startup and resumes replication from a safe point in the most recent journal. As a result, some journal records might be processed more than once.