Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now
Perforce

Perforce Replication – What is Perforce Replication ?

May 4, 2012 Leave a Comment
perforce-replication

perforce-replication

Perforce Replication

Replication is the duplication of server data from one Perforce Server to another Perforce Server, ideally in real time. You can use replication to:

  • A replica server can function as an up-to-date warm standby system, to be used if the master server fails. Such a replica server requires that both server metadata and versioned files are replicated.
  • Reduce load and downtime on a primary server by Long-running queries and reports, builds, and checkpoints can be run against a replica server, reducing lock contention.
  • Perforce administrators can configure the Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers.

NOTES:

  • For checkpoints and some reporting tasks, only metadata needs to be replicated.
  • For reporting and builds, replica servers will need access to both metadata and versioned files.
  • With the 2010.2 release, the Perforce Server now replication between Perforce servers of both metadata and versioned files.

Limitation:

  • Replication is unidrectional, and replica servers are intended for read-only purposes
  • Bidirectional replication is not supported, because any changes made to a replica server can be overwritten by changes made to the master Perforce server.

System Requirement:

  • All replica servers must be at the same release level as the master server. Prefebalily 2010.2 to use both command (p4 pull and p4 replicate).
  • All replica servers must have the same Unicode setting as the master server.
  • All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem.
  • All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem
  • p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals
  • The master and replica servers must have the same time zone setting.

Challenge
Issues 1: The master and replica servers must have the same time zone setting

Today I was just going through P4 replication features with the correspondence of Disaster recovery(Replication), as well as bbalance load efficiently using p4 broker and p4 replica.

We can have cross-geo Disaster recovery(Replication) setup as soon as, we have same time zone setting in both (master and replica) server.  Replica server is unidirectional (read-only) so making same time zone in two difference location would not make any difference since all development activities will be happening though master servers/proxies only.

But
I learned that if we go replication with cross geo then we will not be able to take advantage of balance load efficiently as follows.

  • We will not be able to take advantage of using replica server to reduce load and downtime on a primary server by Long-running queries, builds, and checkpoints in distributed geo environment.
  • Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers will not be having any advantage due to long distance and command will take more time to process in distributed geo environment.

Issues 2: p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals

The replication process is designed to have as little latency as possible between the replica and the master; the compression/decompression of the journal
and manipulation of compressed data introduces additional delay and complexity which in turn increases the potential difference between the state of the master and the replica.

To Setup Replication
p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -i 2”

p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -u -i 2”

To unset Replication
p4d -r $P4ROOT "-cunset  replica1#startup.1"
To list all server configuration variables,

use –cshow:

p4d -r $P4ROOT -cshow

This blog work still in progress…Still in Progress…

Reference

http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/pull.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/configure.html#1040665
http://www.perforce.com/perforce/doc.current/manuals/cmdref/replicate.html#1046521
http://kb.perforce.com/article/1099
http://kb.perforce.com/article/1352/accessing-server-configuration-variables
http://kb.perforce.com/article/1099
http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html

Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x