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
