--On Wednesday, June 23, 2004 11:48 -0700 Kevin Baker <[EMAIL PROTECTED]> wrote:
David,
This is exactly what I had in mind. Could you maybe give a quick overview of how you have the replication and failover setup; specifically "application level replication vs block"
application lvel means exactly that. The actual program/server software involved does it's own replication. Like Oracle RAC or MySQL replication. block level means soemthing at the disk I/O layer does it all, without the app's knowledge.
While the idea of a standby server that uses block level replication seems very great, if possible I'd like to have the reliability while still being able to use both machines.
Is it something like this: - Server A - active accounts 1-100 - replicate accounts 101-200 from Server B - Server B - active accounts 101-200 - replicate accounts 1-100 from Server A
If B goes down, A takes over the accounts it had replicated from B.
Thanks,
On Tue, 22 Jun 2004, Etienne Goyer wrote:
Does somebody on the list use this solution or a similar one and could comment and the practicality of it ? Perhap M. Carter (if you read the list) could give us a status update for his particuliar project ?
There's really not a whole lot to say.
We've been using the code on our main 32k user mail system since about this time last year for data migration, fast incremental backup to a tape spooling system, and rolling replication for live updates. We also used the replication system to migrate from a UW based system to Cyrus.
We have 16 small Linux servers running as 8 pairs. All the systems are live Cyrus servers, half the accounts on each system are replica versions.
One of the 16 had a hardware fault a couple of weeks back and noone has moaned at me after we switched to the replica which is always a good sign.
From my perspective the advantage of application level replication over block level replication like DRDB is flexibility. Read/write access to both master and replica systems can be useful: we maintain databases of MD5 checksums for all the messages and cache entries on each server. Its also rather cute to run PINE against both master and replica version of a given mailbox and watch the replica play follow my leader :).
-- David Carter Email: [EMAIL PROTECTED] University Computing Service, Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
-- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat
--- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
