Re: Replication logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

Best Regards,
Strahil Nikolov






В неделя, 27 декември 2020 г., 23:49:37 Гринуич+2, Gionatan Danti <g.danti@xxxxxxxxxx> написа: 





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 
into production.

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.

Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8

________



Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users
________



Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users




[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux