[Gluster-users] Replication logic
hunter86_bg at yahoo.com
Sun Dec 27 22:31:05 UTC 2020
I checked geo-rep on 8.3 and it takes less than 10 sec for the master to detect the change and start pushing the files to the slave volume.
Geo-rep should be much more optimal and I would give it a try. I guess there is a way to delay the confirmation till a preset of time (to ensure georep has managed to sync the files).
В неделя, 27 декември 2020 г., 23:49:37 Гринуич+2, Gionatan Danti <g.danti at assyoma.it> написа:
Il 2020-12-27 21:58 Zenon Panoussis ha scritto:
>> For such a project, I would simply configure the SMTP server do to
>> protocol-specific replication and use a low-TTL DNS name to publish
>> the IMAP/Web frontends.
> Either you know something about mail servers that I would love
> to know myself, or else this idea won't work. That's because
> even if you could configure three SMTP servers as relays to
> each-other (which you cannot), IMAP actions (move, delete etc)
> do not propagate. So, one day you organise your mail nicely
> in folders, next day you find all of it back in your inbox.
> Or you go looking in your Sent folder for that mail you sent
> last week, and it's just not there. That kind of thing would
> probably frustrate everyone much more than a bit of latency.
Uhm yes, what I wrote was quite confusing. I was really referring to
something as that: https://wiki.dovecot.org/Replication
Re-reading your original question, I think geo-replication should work:
after all, if I understand it right, you would only use the
remote/backup copy in case the primary/local server goes down. Right?
However, you should carefully test if Gluster is, by itself, capable of
the load you are going to put over it: considering that a mailserver can
easily store millions of small files and Gluster relatively low file
lookup performance, I would thoroughly test it before putting this setup
About the closing consideration about a "bit of latency", I think you
are *way* over-optimistic for replica volumes: Gluster sync replication
is very latency boud and, if things did not changed recently, it was
strongly advised against running sync replication between WAN links.
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
Community Meeting Calendar:
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Gluster-users mailing list
Gluster-users at gluster.org
More information about the Gluster-users