Don't really have a "how to", but I do have a sort of, grand scheme paper on how I did it.
Latency on failover is about 30-45s. Machines are connected via a x-over gigE connection that is just used for replication of DRBD (though DRBD can only currently sync at 700Mb I believe). I also connect them via a serial connection for heartbeat, and lastly they both ping the gateway on their primary interface. (They call me anal around here a lot). DRBD is amazingly fast for replication when it's up. I tried everything I could to get it to hang up but it wouldn't. Right now I have a fairly empty 60GB partition that I'm replicating and upon failover it takes no time to take over services. When the broken machine is returned to service it's taken about 20 min to replicate everything. DRBD has a 128M (I think) buffer and if that was not wraped before you get the machine back online resync is really fast. If that has wraped then DRBD sync's every single block on the drive. So even at full capacity it should only take about 20min for the sync to happen. I'll Email you a copy of the page that I wrote. -- David A. Niblett | email: [EMAIL PROTECTED] Network Administrator | Phone: (352) 334-3400 Gainesville Regional Utilities | Web: http://www.gru.net/ -----Original Message----- From: Kevin Baker [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 2:58 PM To: DBMail mailinglist Subject: RE: [Dbmail] DbMail in a ISP Cluster So David, Do you have any kind of howto on the DRBD? How is the latency? How do you have the machines connected? - dedicated (crossover) or normal ethernet I considered this before as a way to replicate Cyrus for a standby failover solution... but it look kind of complex, which is why I started looking into DBMail. Thanks, Kevin > Well I need psql because I have a large need of triggers, stored > proceedures and views. At the time I implemented most all > of that > stuff was "coming soon" in mysql. > > I can work around replication with other devices, but I > can't > work around triggers. > > Thanks for the help, I'll stick with DRBD replicating > psql. > > -- > David A. Niblett | email: [EMAIL PROTECTED] > Network Administrator | Phone: (352) 334-3400 > Gainesville Regional Utilities | Web: http://www.gru.net/ > > > > -----Original Message----- > From: Simon Lange [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 18, 2005 1:02 PM > To: 'DBMail mailinglist' > Subject: RE: [Dbmail] DbMail in a ISP Cluster > > > > Well when we did evaluate pgsql it didnt cover > replication. maybe u are > right that they dont implement replication because there > are thridparty > solutions available. but ur reffered solution is still unstable (just > read their mailinglists and checked up their versions) and if > ppl use it for > productive purposes... -- well their business ;) however, > i could not find > any stable solution for circle replication for pgsql so > far. maybe there are > sum available but why searching if there is a > databaseserver which is fast > efficient and has replication built in (and in the next > major update also > native clustering)? it was no meant as an offense but its > a good question: > why usin pgsql-without-replication + thirdparty > replication and not using > mysql-WITH-replication?! > > be sure i DO understand pgsql and i know why im not using > it. :) i never > meant to piss on pgsql. ok i would never use it for our servers but > thats my opinion. ;) so u dont piss on me just because mysql has > the better > replication system built-in! ;) and as far as i can > remember the inital > question to this thread was if there are ppl out with > dbmail/clustering > experience... yes there are... > > regards > > Simon > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Matthew T. O'Connor > Sent: Wednesday, May 18, 2005 6:42 PM > To: DBMail mailinglist > Subject: Re: [Dbmail] DbMail in a ISP Cluster > > The Postgresql development team made an intentional design decided not > to include any one replication system into the main CVS tree > simply because > there are many types of fundamentally different > replication that serve > different purposes. > > Slony is well tested, and is used in many production environments. It > is a master-slave replication system, it works quite well and > is supported by the > slony team. I would not call it non-native. In addition > there are several > other replication implementation that serve different > purposes, some are > commercially supported by a vendor. > > Please don't spread FUD about a system you don't > understand. I have not and > would not say a single negative thing about mysql or its replication > because I don't have experience with it. > > Matt > > Simon Lange wrote: > >>varieties means ports?! branches of the original pgsql source?! or >>are these thridparty solutions which add external >> functionalities which >>pgsql does not provide? however, i would prefer a native >> replication > instead a workaround. >>;) especially on productive environments. ;) >> >>however dbmail/mysql provides a tested and working >> clustering (circle >>replication) with on fail solution for all those who may >> need it. so >>why using a pgsql with non-native replication if there is >> a stable >>native mysql replication solution available? >> >>regards >> >>Simon >> >> >>Simon Lange //Director >>======================== >>www.polynaturedesign.com >>+49[0]4131 220121 PHONE >>+49[0]4131 224730 FAX >>+49[0]16090300077 CELL >>======================== >> >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>Behalf Of Matthew T. O'Connor >>Sent: Wednesday, May 18, 2005 5:58 PM >>To: DBMail mailinglist >>Subject: Re: [Dbmail] DbMail in a ISP Cluster >> >>Postgresql does support replication, in fact there are several >>different varieties of it available, check out slony1 >> among others. >>What it doesn't support is automatic failover. >> >>Simon Lange wrote: >> >> >> >>>pgsql does not support replication. thats why we do use mysql - >>>clustering is announced for mysql5 :D >>> >>>if a database goes down, exim recognizes this and >>> temporaly refuses >>>any mails which causing foreign mta to address the other mta... >>> >>>regards >>> >>>Simon >>> >>> >>>Simon Lange //Director >>>======================== >>>www.polynaturedesign.com >>>+49[0]4131 220121 PHONE >>>+49[0]4131 224730 FAX >>>+49[0]16090300077 CELL >>>======================== >>> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>On Behalf Of Niblett, David A >>>Sent: Wednesday, May 18, 2005 5:04 PM >>>To: '[email protected]' >>>Subject: [Dbmail] DbMail in a ISP Cluster >>> >>>What are you all using to cluster PostgreSQL? I looked >>> at the >>>master/slave replication that comes with Postgres. It >>> seems fine if >>>you want to replicate the data, but how do you get >>> dbmail to switch >>>databases when there is a failure? >>> >>>I'm currently using drbd to replicate the disk block >>> device that my >>>postgres database is stored on, then only run postgres >>> on the "primary" >>> >>> >>machine. >> >> >>>Linux heartbeat fails and starts the services on the "secondary" >>>machine shold the first one croak. >>> >>>-- >>>David A. Niblett | email: >>> [EMAIL PROTECTED] >>>Network Administrator | Phone: (352) 334-3400 >>>Gainesville Regional Utilities | Web: >>> http://www.gru.net/ >>> >>>_______________________________________________ >>>Dbmail mailing list >>>[email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail >>> >>>_______________________________________________ >>>Dbmail mailing list >>>[email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail >>> >>> >>> >>> >>> >>_______________________________________________ >>Dbmail mailing list >>[email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail >> >>_______________________________________________ >>Dbmail mailing list >>[email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail >> >> >> > _______________________________________________ > Dbmail mailing list > [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ > Dbmail mailing list > [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > _______________________________________________ Dbmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
