[p4] Using p4jrep for a hot standby

Jeff Grills jgrills at drivensnow.org
Wed Oct 12 12:33:12 PDT 2005


It's the perforce server software itself that guarantees that transactions
appear to be atomic to its users.    At some point the perforce server has
to start writing the DB changes to the RAID, and I don't see any reason that
those writes to the disk are guaranteed to be atomic, especially considering
it has to write to multiple files for a single atomic transaction.  If
something goes wrong with the machine in the middle of writing the changes
to the disk, I don't think you can trust the DB files as they are on the
disk.  You'd want to recover from a checkpoint+journal.
 
j
 

-----Original Message-----
From: Jamison, Shawn [mailto:sjamison at ciena.com] 
Sent: Wednesday, October 12, 2005 2:07 PM
To: Jeff Grills; Neil Carson; perforce-user at perforce.com
Subject: RE: [p4] Using p4jrep for a hot standby


That's the point of having atomic transactions.  They are all or nothing.  
If Server A dies during a 50,000 file submit the metadata doesn't get
written to the db.* files
Bring up Server B and submit again. 
 
At least that's how I understand it.  Someone at Perforce might be able to
shed more light on this situation.
 
-Shawn j>

 

-----Original Message-----
From: Jeff Grills [mailto:jgrills at drivensnow.org]
Sent: Wednesday, October 12, 2005 3:01 PM
To: Jamison, Shawn; 'Neil Carson'; perforce-user at perforce.com
Subject: RE: [p4] Using p4jrep for a hot standby


 
What would you do if the primary machine crashed in the middle of an
operation and left the db.* files in an inconsistent state?  It seems better
to replicate atomic transactions from one machine to the next.
 
j
 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Jamison, Shawn
Sent: Wednesday, October 12, 2005 11:07 AM
To: Neil Carson; perforce-user at perforce.com
Subject: RE: [p4] Using p4jrep for a hot standby


Why not just have them share an external raid array and eliminate the risk
of mirroring metadata and depot files?
That way all you would have to do is start the p4d service on the "Hot"
spare and your off.
 
-Shawn J>

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com]On Behalf Of Neil Carson
Sent: Tuesday, October 11, 2005 8:01 PM
To: perforce-user at perforce.com
Subject: [p4] Using p4jrep for a hot standby



Greetings and good evening,

 

My first post to the list. We're just working on a new perforce installation
here at Everdream.

 

I've purchased two different machines, one as a primary perforce server, one
as a hot or "warm" standby - preferably a hot one. Both are fairly high end
Linux/Opteron machines.

 

In the case of a hot standby, I was looking at p4jrep. It seems to do a good
job of making sure the second machine's metadata is accurately mirrored.
What I wasn't sure of in this picture is how to then also mirror the
versioned files to the second machine - rsync periodically, or another
method?

 

What approaches have you typically used successfully in this configuration?
Any advice much appreciated.

 

            Thanks,

 

            Neil

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.perforce.com/pipermail/perforce-user/attachments/20051012/b5aa9422/attachment-0006.html>


More information about the perforce-user mailing list