p4 pull command

The p4 pull command provides the most general solution for replication. Use p4 pull to configure a replica server that:

  • replicates versioned files (the ,v files that contain the deltas that are produced when new versions are submitted) unidirectionally from a master server.
  • replicates server metadata (the information contained in the db.* files) unidirectionally from a master server.

  • uses the startup.N configurable to automatically spawn as many p4 pull processes as required.

    A common configuration for a warm standby server is one in which one (and only one) p4 pull process is spawned to replicate the master server’s metadata, and multiple p4 pull -u processes are spawned to run in parallel, and continually update the replica’s copy of the master server’s versioned files.

  • The startup.n configurables are processed sequentially. Processing stops at the first gap in the numerical sequence. Any commands after a gap are ignored.

Although you can run p4 pull from the command line for testing and debugging purposes, it’s most useful when controlled by the startup.n configurables, and in conjunction with named servers, service users, and centrally-managed configurations.

The --batch option to the p4 pull specifies the number of files a pull thread should process in a single request. The default value of 1 is usually adequate. For high-latency configurations, a larger value might improve archive transfer speed for large numbers of small files. (Use of this option requires that both master and replica be at version 2015.2 or higher.)

Setting the rpl.compress configurable allows you to compress journal record data that is transmitted using p4 pull.

Note

If you are running a replica with monitoring enabled and you have not configured the monitor table to be disk-resident, you can run the following command to get more precise information about what pull threads are doing. (Remember to set monitor.lsof).

$ p4 monitor show -sB -la -L

Command output would look like this:

31701 B uservice-edge3 00:07:24 pull sleeping 1000 ms
    [server.locks/replica/49,d/pull(W)]

The possible status messages are:

For journal records For pulling archives
scanned NNNN records sleeping
applied NNNN records running
rotating journal  

p4 pull vs. p4 replicate

Helix Core Server also supports a more limited form of replication based on the p4 replicate command. This command does not replicate file content, but supports filtering of metadata on a per-table basis.