p4 pull
Synopsis
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 preferable to p4 replicate.
Syntax
p4 [g-opts
] pull [-J prefix
] [-i interval
] [-b interval
] [-T excluded_tables
] [-P serverid
]
p4 [g-opts
] pull -u [-i interval
-b interval
--batch number
]
p4 [g-opts
] pull -l [-s | -j [-J prefix]]
p4 [g-opts
] pull -d -f file
-r revision
p4 [g-opts
] pull -L [-i interval
]
Description
The p4 pull command provides five syntax variants:
-
The first variant retrieves journal records from a target server specified by
P4TARGET
. -
The second variant retrieves file contents from a target server specified by
P4TARGET
. -
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 journalcopy command) 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
startup.
configurable to
start the p4 pull processes every time the replica
server starts.
n
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 state
and resides in the replica server's root directory.
You can specify a different file name by setting the statefile
configurable
with p4 configure.
Retrieving journal and file content
The p4 pull command instructs the current replica
server to retrieve either journal records or file contents from a target
server specified by
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 -u
option) to replicate the master
server's metadata, and at least one p4 pull (with the
-u
option) to replicate the server's versioned
files.
-
The
-i
option specifies a polling interval (in seconds) between updates. If-i
is not specified, p4 pull runs for one polling interval and then exits. -
The
-b
option specifies a wait time after a failed pull attempt. If-b
is not specified, p4 pull retries after 60 seconds. -
The
-u
option specifies that file content should be retrieved. If this option is not specified only journal records are fetched. -
The
--batch
option 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.)
Use the -T
option to exclude tables you do not want to
replicate. For example a build farm server does not need to replicate
the db.have
, db.working
, or
db.resolve
tables.
To delete a pending file transfer operation, use p4 pull -d -f
file
-r
rev
. This can be useful if a
pending file transfer is failing repeatedly due to unrecoverable errors
on the master.
Note
Setting the rpl.compress
configurable allows you to compress journal
record data that is transmitted using p4 pull.
Getting status information
Use the -l
option to display a list of files that are
scheduled for transfer. If -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 content.
An operator may run the p4 journalcopy -l, p4 pull -l -j, and 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
If -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: Journaljjj
, Sequence:sssss
. Current master journal state is: Journaljjj
, 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.
Options
|
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. Default; 1 |
|
Cancel a pending file content transfer, where
NoteThis is not the normal Perforce file and revision data, but rather the archive file and revision. Use the p4 pull -l command to get the correct file name and revision. |
|
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 p4 pull -l -j can have three lines of output: one for the replica journal's current state, one for the state of the corresponding journal on the master, and a third line for the new journal on the master, data from which has not yet arrived at the replica. |
|
Display a summary of scheduled file content transfers. If this list is unexpectedly long or is growing, you might consider running additional p4 pull -u commands. |
|
Retrieve journal records from a local journal file, normally produced by the p4 journalcopy command. |
|
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, the
Note
For compatibility with earlier releases of Perforce,
you can also supply filter patterns directly within this
field by using the same syntax used by the
p4 export,
but specifying a server and using fields in the
p4 server
form is strongly encouraged, because the behavior of a replica
that makes use of multiple p4 pull commands
with inconsistent or conflicting |
|
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 example, |
|
Transfer archive files instead of journal records. If you omit this option, the command retrieves journal records. |
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? |
Can File Arguments Use Revision Range? |
Minimal Access Level Required |
---|---|---|
N/A |
N/A |
|
For more about configuring Perforce to run in a replicated environment, see Perforce Server Administrator Guide: Multi-site Deployment.