Replication is the duplication of server metadata from one Perforce Server (the master server) to another Perforce Server (the replica server). The basics of replication are covered in Chapter 10 of the Perforce System Administrator's Guide. This article provides answers to common questions that come up when setting up and implementing Perforce metadata replication.
With the release of Perforce Server 2009.2, the p4 replicate utility is the supported method of Perforce metadata replication. Information on system requirements and limits and restrictions when using p4 replicate can be found in the Perforce System Administrator's Guide.
The functionality provided by p4 replicate was first introduced in beta (prior to the release of Perforce Server 2009.2) as a standalone utility called p4jtail. p4jtail is now available as open source in the Public Depot as an example of a client program that uses the Perforce C++ API to do replication. It also serves as a starting point for those interested in extending or customizing replication behavior in some way not supported by p4 replicate.
Prior to p4 replicate and p4jtail, the common utility used for replication was p4jrep, a user-contributed Perforce journal replication utility available from the Public Depot. Both p4jrep and p4jtail remain unsupported but customers can obtain assistance and advice on usage by contacting Perforce Technical Support.
What is p4 replicate?
Where do I run the p4 replicate command?
Does p4 replicate work against archive file content?
Can I replicate from one master server to multiple replica servers?
Can I replicate bidirectionally?
Can I checkpoint the master server?
Can I checkpoint the replica server?
How does p4 replicate extract journal records from the master server?
How does p4 replicate locate journal files on the master server?
How does p4 replicate track what journal records have been processed?
Can I filter what gets replicated from the master server?
What is the upgrade process when doing replication?
A. p4 replicate is a client command that polls a primary Perforce Server (the master) for new journal records, then provides these records to a subprocess that restores the records into the database of a Secondary Perforce Server (the replica).
Q Where do I run the p4 replicate command?
A. You run p4 replicate on the machine that will host the replica Perforce Server. Because p4 replicate is a client command, you can run it from any client machine that can connect to the master server.
Q. Does p4 replicate work against archive file content?
A. No. p4 replicate only replicates Perforce Server metadata, that is the information contained in the db.* files. Depending on the requirements for your replica server, you can optionally configure the replica server to read the master server's versioned files, or use third-party or native OS functionality to mirror the versioned file content to the replica server.
Q. Can I replicate from one master server to multiple replica servers?
A. Yes, multiple instances of p4 replicate can be run against the same master server.
Q. Can I replicate bidirectionally?
A. No, replication is unidirectional.
Q. Can I checkpoint the master server?
A. Yes, p4 replicate continues to run during journal rotation on the master server, except when p4 replicate is started using the -x option. If p4 replicate is started with the -x option, replication will terminate when journal rotation is detected on the master server.
Can I checkpoint the replica server?
A. Yes. If using the replica server for offline checkpoints, checkpoint using the p4d -jd option. See the Offline Checkpoints Knowledge Base article for further details.
Q. How does p4 replicate extract journal records from the master server?
A. Behind the scenes, p4 replicate makes use of the p4 export command to extract journal records from the master server. In addition to providing journal records, p4 export adds fields to its output to indicate points of transactional consistency and the end of the journal file.
Q. How does p4 replicate locate journal files on the master server?
A. p4 replicate locates the live journal file on the master server based on the setting of P4JOURNAL or the -J option passed to p4d on startup. For rotated journals, p4 replicate looks by default in the P4ROOT directory on the master server and uses the default naming convention for rotated journals (journal.nnn). If using the prefix option when checkpointing or rotating the journal on the master server (prefix in this example is /data/backup/p4):
p4d -jc /data/backup/p4 ORp4 admin checkpoint /data/backup/p4p4d -jj /data/backup/p4 ORp4 admin journal /data/backup/p4the name and possibly the location of rotated journals will not follow the default convention. In this case, the -J flag to p4 replicate must be used, specifying the same prefix used in the checkpoint and journal rotation commands on the master server:
p4 replicate -J /data/backup/p4 ...Q. How does p4 replicate track what journal records have been processed?
A. p4 replicate uses a statefile to store a journal position token consisting of a journal number and position (byte) offset indicating what journal records from the master have been processed.
Q. Can I filter what gets replicated from the master server?
A. Yes. Filters can be used with p4 replicate to customize the journal records that are replicated. The command that p4 replicate runs on the replica to replay journal records could be, for example, a script that first applies some filter to the journal data stream and then passes the data to the command used to replay the journal records into the replica.
Warning: If you are using replicate to perform offline checkpoints, then do not filter the journal stream. By definition, filters remove content; therefore, a filtered journal replication will not provide sufficient data integrity for your checkpoint and backup process. The primary use of journal stream filtering is to support replication to a read-only Perforce Server used for build or reporting purposes. Depending on the specific use case, it might be desirable to filter out db.have or other db table entries.
Q. What is the upgrade process when doing replication?
A. For detailed upgrade procedures, see the Upgrading replica servers section of the System Administrator's Guide.
No comments:
Post a Comment