With 2009.2, Perforce makes it easier ot meet High Availability (HA) and Disaster Recovery (DR) objectives. What used to be an "advanced custom solution" is now becoming a commoditized solution.
Over the years, Perforce customers have deployed Perforce to meet certain HA/DR requirements. Having become familiar with the Perforce journaling mechanism, they found ways to duplicate Perforce metadata updates in real-time to a separate, replicated copy of the Perforce databases. This approach made possible deployment options such as "hot spare" standby/backup servers, warm spare DR servers, and read-only replica servers. Some custom solutions were presented by customers at Perforce user conferences over the years.
The p4jrep and later the P4jtail utilities evolved in the Public Depot. These utilities worked in some environments, but had limitations that kept them from being widely applicable. Windows environments aren't supported, they don't work with Unicode-enabled servers, and aren't "officially" supported by Perforce Technical Support.
That building in the background is (was?) my data center!
Enter Perforce 2009.2. Perforce 2009.2 offers new tools to simplify and commoditize HA/DR solutions: p4 replicate, and p4 export. The p4 export command handles raw metadata replication, and provides capabilities such as filtering—useful if you want to, for example, populate a read-only replica stripped of db.have entries. The p4 replicate command can be thought of as a wrapper to p4 export that handles the classic "full replication" scenario used for HA/DR solutions.
These new features are part of the core Perforce server and are fully supported. They provide a reliable, supported, cross-platform solution for replicating Perforce metadata. If you're doing DR you'll still need to replicate your versioned files, but ubiquitous tools like rsync (Linux) or ROBOCOPY (Windows) suffice in many environments. For some environments, more sophisticated technologies such as block-level replication solutions and WAN replication technologies are brought to bear to keep versioned files in sync on remote replicas.
Another approach to replicating versioned files is to drive the versioned file updates based on updates to metadata. Essentially, you only need to write files when submits or shelving operations occur, and those are easy to detect in the metadata. If you push files as they are updated, your replicas can be kept as up-to-date as possible. This should be considered if rsync or ROBOCOPY don't scale in your environment. Both rsync and ROBOCOPY can handle huge amounts of data, but sometimes it takes them a long time to determine that nothing changed—and that is a limiting factor in how up-to-date your replicated data can be.
Users running on Linux should take note of the fact that, as of 2.6.33 kernel of Linux, the Distributed Replicated Block Device (DRBD) was merged into the Linux kernel. This basically means that the infrastructure upon which HA/DR solutions can be built in Linux is that much more readily accessible than it had been previously (when it was available as an external patch for more bold and adventurous Linux users.) DRDB support can now play its part in future HA/DR solutions.
In Consulting, we've seen a lot of interest in HA/DR solutions in the past year or so. With new tooling available in 2009.2, you can bet you'll hear more about HA/DR in the future. You'll hear more from me, and maybe something at the Perforce User Conference in London in 2010. See you there, maybe?
Tom adpated this article from a blog post p4 blog, Perforce Software's blog.
Known to colleagues as "The ClearCase Guy" in the mid-late ’90s, Tom found Perforce while doing an SCM tools evaluation in 1999. He has been a Perforce enthusiast since then. Tom worked as an independent consultant, and later joined Perforce’s Consulting Services team. Tom loves to talk about branching strategies, ClearCase to Perforce migrations, and all things Perforce.