On 12/07/2024 17:38, James Cook via dovecot wrote:
Replication is in the current dovecot version but will go away in 2.4.
The doveadm sync feature is staying. So with some work you can set it
up what you are requesting.
I used to use replication and now I'm thinking about using sync but
have not implemented it. The following are thoughs on it.
There are some points to be addressed that are outside dovecot. I
think you'd have to make sure that your sync happened frequently
enough that you could live with losing the emails that arrives
bewteen syncs for example.
I have been thinking of writing a hacky delivery script that passes
the email on to dovecot-lda, then runs doveadm sync, and only returns
success after the sync is done (or after a timeout). No idea what
problems I will run into, but the idea is to never accept an email
until it's guaranteed replicated.
That would tend to lead to a requirement to sync more frequently and
reduce risk of email loss. But then you'd need to avoid more than one
sync being active simultaneously (that is my assumption that this
would not work, but I don't know if it is a real problem).
Doesn't the -l option protect against simultaneous syncs? Just based
on reading the doveadm-sync man page. (I guess it could cause a
problem if you start sync processes more quickly than they can finish.)
NB I'm just running a one-person email server so don't take my ideas
too seriously :)
Hi James
I want to avoid the -1 parameter because it doesn't do deletes in the
target. It might not be an issue, but I'd like to keep the target the
same as the source. I don't know if it would protect against
simultaneous jobs, but I dont' know even if that is an issue. I was
making the assumption it could be so I plan to avoid it somehow.
As for the lda to doveadm sync script, I have been wondering too about
how to close the gap for emails arriving between syncs, even though the
risk might not be so significant.
With delivering to two dovecot servers before accepting the email,
either one going down will stop email delivery. That's an inconvenience
but without necessarily introducing risks for losing the emails.
Ultimately it depends on where those undelivered emails are being kept
in the meantime (presumably MTA queue) and whether they are safer there
than being delivered to a single instance. Though that is related only
to the downtime. When both are up the risk would be mitigated by the
solution.
Other idea I was thinking of is a replicated file system. That could
make emails available in real time to both dovecot instances assuming a
functionality to sync to disk on both/multiple nodes before replying
back to dovecot to accept the email. I believe there would still need to
be only one dovecot instance active at a time. However, I have heard of
but don't know personally of horror stories about email outages on
clustered file systems, which leads me to believe that there would still
be sufficient residual risk to require a backup copy of the mailboxes
with doveadm sync or other tools.
John
John
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
