On Wed, Mar 13, 2013 at 11:55 AM, John Kinsella <j...@stratosec.co> wrote: > Looks good, alas this particular use case needs MSSQL not MY :) > > On Mar 12, 2013, at 7:21 PM, Jason Davis <scr...@gmail.com> wrote: > >> Galera MySQL might be an option, depending on how fast the round trip is >> between the two sites. >> >> I will confess that I am NOT a fan of Linux HA clustering. I would >> recommend doing replication at the MySQL layer. Linux HA clustering is >> complex and fragile... Our big LMS at the university runs on such a cluster >> (RHEL cluster + DRBD) and its more trouble than its worth. I am working to >> hopefully move this to Galera. In our testing it has been way easier and >> more resistant to fault. >> On Mar 12, 2013 9:00 PM, "Mathias Mullins" <mathias.mull...@citrix.com> >> wrote: >> >>> Hi John, >>> >>> So in a lot of the installations that we have worked with, we are seeing a >>> lot of work with DRBD (Active/Standby, Active/Active w/Pacemaker). So far >>> it's been one of the better solutions that we have seen installations >>> stable with. I think a lot of people would like to see this functionality >>> written into ACS to support something in addition to MySQL Master/Slave >>> replication. >>> >>> Personally I like the DRBD solution because it deals with the replication >>> at a block level and gives us the flexibility of active/passive and >>> active/active ability versus having to do a lot of manual work to revert >>> the master/slave relationship. >>> >>> Thanks, >>> Matt >>> >>> >>> On 3/12/13 9:32 PM, "John Kinsella" <j...@stratosec.co> wrote: >>> >>>> Thought I'd throw this question out on the list - we're working on >>>> geographically (1500 miles) replicated databases for customers who really >>>> don't want their stuff to go down. >>>> >>>> In this particular case, how they've architected their DB schemas means >>>> they're really not friendly to the standard transactional replication >>>> (this is MSSQL server) so we're looking at replicating the whole block >>>> device the db is stored on. >>>> >>>> We've tried usingŠ >>>> * Ceph - know it's not meant for geo-repŠloving it locally, though! >>>> * Gluster - When clustering across the WAN, performance was weak. Don't >>>> have enough disks/nodes to create a gluster cluster to replicate with >>>> gluster-geo-replicate >>>> * drbd in active/standby - Fairly decent performance. I hear it'd be >>>> better with the drbd-proxy, but don't feel like spending the $$ yet. I've >>>> been previously shot in the foot enough times with drbd active/active >>>> that I won't try that again. >>>> >>>> Currently using drbd (I'm pondering writing management of the >>>> primary/secondary stuff into ACS) but curious if others have found ways >>>> of doing this with ACS that they like? >>>> >>>> John >>>> >>>> Stratosec - Secure Infrastructure as a Service >>>> o: 415.315.9385 >>>> @johnlkinsella >>>> >>> >>> > > Stratosec - Secure Infrastructure as a Service > o: 415.315.9385 > @johnlkinsella >
So not to come off all BOFH-ish, but it seems like there needs to be give and take here. >From your post: $entity wants no downtime. $DB provides several replication strategies that work to varying degrees to get one closer to no downtime. $entity doesn't want to design a schema that works well the proven $DB replication strategies. $entity seeks magic silver bullet to provide the above. While things like DRBD might be reasonable, if it's something they care enough about to really want no downtime, why are they not willing to modify their schema to use $DB-approved solutions for maintaining availability? --David
