Thank you, that is all really useful information. The more I work through my configuration the more I think my best option at this time is going to be to put a cloud-based HAProxy in front of my two servers so if one goes down I can easily just switch to the other. It is good to hear that you have had a positive experience with the multi-master syncing. It sounds like a solid solution, and in my case a simple one because for now I won't even need IMAP from either server.
The other thing that worries me is that dbmail is going to fall into a state of disrepair without any developers backing it (as was recently mentioned on this list). What do other dbmail users say about that? Are you thinking of switching? Ryan On Sat, Sep 22, 2018 at 03:14:50PM +0200, Andrea Brancatelli wrote: > We've been having a MySQL multi master replication with three geographically > distant server for years without any particular issue. > > You don't need the galera-specific "distributed acknowledge" stuff that, as > you > guessed, slows down every insert. > > Basically everything in dbmail's database has a native unique primary key > (auto > incrementing), PLUS an hash column that is used for deduplication. That means > that the only really clumsy problem, even in case of a split brain situation > is > that if the very same email arrives in two different location while the > database is not in sync, is that the mail doesn't get deduped. Definitely not > a > big issue. > > One tricky parts, on other hand, is the IMAP side as you have to make sure > that > any IMAP session goes to the same Backend or, always in case of a split brain > situation, the user may see mail appearing and disappearing if two different > IMAP session go to two different, unaligned, sites. > > But there are very easy workaround for that too - here we usually NGINX as a > frontend IMAP and we have a script that does some hashing of the login name to > map it to a specific geographic location - unless that location is down. > > If you need some more details in all of this just ask. > > --- > > Andrea Brancatelli > > > > On 2018-09-21 05:26, Ryan Beethe wrote: > > I am currently operating a small mail server (postfix + dovecot) but I > have experienced a couple of ISP issues recently and would like to > improve the availability of my server by operating a second server at a > separate physical site (the sites I have available are separated by a > 60ms ping). > > I am new to the world of high availability, but given my resources and > constraints, an "active/passive" configuration seems to be my best > option, where I have a primary server that is up most of the time and I > can use pacemaker to switch from one to the other for failovers. > > I think I could get away with not using a distributed file system if I > were to switch from dovecot to dbmail. I definitely need the > distributed database, so avoid also using a distributed file system > seems like a way to keep my architecture as simple as possible (but > please correct me if I am wrong). > > For doing geo-replication, I have read that galera supports > georeplication. But my gut sense is that galera's synchronous protocol > in combination with my ping time would make anything that needed to > write to the database a lot (like dbmail) prohibitively slow. Does > anybody know if that is the case or not? > > Also, I read that auto_increment columns with the galera plugin are > guaranteed to be unique, but not guaranteed to be sequential. Would > that break dbmail? > > My other option would be a master-master synchronization between the two > databases. I know people on this mailing list have been doing that for > a while, because I read about that setup on this mailing list as far > back as 2006. But (noob question alert), since the master-master > database sync is asynchronous, doesn't that run the risk of data loss or > corruption from the very latest data if a server crashes? Has that ever > happened to any of you with dbmail, and what is the recover process > like? > > Ryan > _______________________________________________ > DBmail mailing list > DBmail@dbmail.org > http://lists.nfg.nl/mailman/listinfo/dbmail > _______________________________________________ DBmail mailing list DBmail@dbmail.org http://lists.nfg.nl/mailman/listinfo/dbmail
