Retrieve metadata or versioned files from a Perforce master server to a replicate, or display status information about pending transfers.
In most situations, server replication with
p4 pull is
g-opts] pull [-J
g-opts] pull -u [-i
g-opts] pull -l [-s | -j [-J
g-opts] pull -d -f
g-opts] pull -L [-i
p4 pull command provides five syntax variants:
- The first variant retrieves journal records from a target server
- The second variant retrieves file contents from a target server
- The third variant displays information about scheduled file transfers.
- The fourth variant cancels a scheduled file transfer.
- The fifth variant specifies that journal records be retrieved from a
local journal file (produced by the
p4 journalcopycommand) rather than from the journal file of the target server. These records are then written to the replica’s database. You need to use this variant if you are using a standby replica for failover.
Except for testing purposes,
p4 pull is rarely run from the
command line. Instead, set the
configurable to start the
p4 pull processes every time the
replica server starts.
When you stop either the master server or a replica server, the replica
server tracks the most recent journal position in a small text file
called the state file. By default, the state file is named
resides in the replica server’s root directory. You can specify a
different file name by setting the
statefile configurable with
Retrieving journal and file content
p4 pull command instructs the current replica server to
retrieve either journal records or file contents from a target server
P4TARGET. Some replica servers do not need
both journal records and file contents: for example, if you are creating
a replica to help with offline checkpointing, you do not need to
transfer file contents.
To replicate both metadata and file contents, you must run at least two
p4 pull commands: one
p4 pull (without the
to replicate the master server’s metadata, and at least one
pull (with the
-u option) to replicate the server’s versioned
-ioption specifies a polling interval (in seconds) between updates. If
-iis not specified,
p4 pullruns for one polling interval and then exits.
-boption specifies a wait time after a failed pull attempt. If
-bis not specified,
p4 pullretries after 60 seconds.
-uoption specifies that file content should be retrieved. If this option is not specified only journal records are fetched.
--batchoption 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 15.2 or higher.)
-T option to exclude tables you do not want to replicate. For
example a build farm server does not need to replicate the
To delete a pending file transfer operation, use p4 pull -d
rev. This can be useful if a
pending file transfer is failing repeatedly due to unrecoverable errors
on the master.
rpl.compress configurable allows you to compress journal
record data that is transmitted using
Getting status information
-l option to display a list of files that are scheduled for
-s is specified along with
-l, a summary of scheduled
file transfers is displayed. An additional line specifies the oldest
changelist number that has at least one pending transfer. This provides
a clue about how far the replica is lagging in its transfer of archive
An operator may run the
p4 journalcopy -l,
p4 pull -l
p4 pull -l -s commands. This makes it possible for
an operator to confirm the state of a replica.
File transfers: n active/m total, bytes: nnn active/mmmmm total. Oldest change with at least one pending file transfer: n
For example, the following output:
File transfers: 1 active/63 total, bytes: 745 active/23684 total.
Tells us that there are 63 pending archive file transfers, one of which is currently active; and there are 23,684 bytes needed to be transferred of which 745 are currently actively being transferred.
-j is specified with
-l, report the current journal state at the
current replica and its master, the last time the state file was
modified, and the server’s local time and time zone. For example:
Current replica journal state is: Journal jjj, Sequence: sssss. Current master journal state is: Journal jjj, Sequence: sssss. The statefile was last modified at: 2012/01/10 14:23:23. The Server time is currently: 2012/01/10 14:23:23 -0800 PST
The value of
jjj specifies a journal number;
sssss specifies an
offset in that journal.
Specify a polling interval in seconds for retries after failed retrieval attempts. If you do not specify this option, the pull is retried after 60 seconds.
Use this option to specify the number of files a pull thread should process in a single request. For high-latency configurations, providing a larger value than the default might improve archive transfer speed for large numbers of small files.
Cancel a pending file content transfer, where
This is not the normal Perforce file and revision data, but rather the
archive file and revision. Use the
Specify a polling interval in seconds for content retrieval. The smallest interval is one second. If you omit this option, the command runs once and exits.
If you set the interval to be
Specify a prefix for the rotated journal file; overrides
If your master server uses a non-default rotated journal location, this allows you to specify the rotated journal file location on the master server.
List files that are scheduled for transfer.
If you use this option on an edge server or build server that has
Display the current journal state on the replica and the master.
During the process of journal rotation on the master, the output of
Display a summary of scheduled file content transfers. If this list is
unexpectedly long or is growing, you might consider running
Retrieve journal records from a local journal file, normally produced
Filter data from
In older releases, this option confirmed filters defined in the filter
spec. This confirmation is no longer required. The option is retained
for continued support of earlier releases. It can also be useful if you
want to share filter configuration among multiple servers. In this case,
For compatibility with earlier releases of Perforce, you can also supply
filter patterns directly within this field by using the same syntax used
Supply a list of database tables (for example,
To specify multiple tables, double-quote the list and separate the table
names with spaces. Table names can also be separated by commas. For
Transfer archive files instead of journal records. If you omit this option, the command retrieves journal records.
See “Global Options”.
|Can File Arguments Use Revision Specifier?||Can File Arguments Use Revision Range?||Minimal Access Level Required|
For more about configuring Perforce to run in a replicated environment, see Helix Versioning Engine Administrator Guide: Multi-site Deployment.