[Dovecot] dsync replication questions
I am running two servers with Dovecot v2.2.12 on CentOS x86_64 (5.10 and 6.5 respectively) and users are virtual over ldap.
I have setup our main internal server (vmail.example.com) with dsync replication according to the first part of http://wiki2.dovecot.org/Replication. The second one (vmail1.example.com) will be the failover server which we want to be a real-time mirror (but can be manipulated directly and it should propagate changes back to vmail.example.com).
When I started the server (vmail.example.com), mirroring started and completed fine (after a few hours).
However, since then, I am not seeing a continued mirroring between the two. I would expect changes to one of the masters to be propagated in real time to the other - which does not happen.
If I manually run (on vmail.example.com):
dsync -u imaptester mirror ssh -l root vmail1.example.com dsync -u
imaptester
then these two accounts are synced.
Question 1: Shouldn't mirroring continue automatically in real time (having configured it as in the first part of http://wiki2.dovecot.org/Replication)? If not, what should I do to enable such a real-time (or near-real-time) sync?
Note that I have not configured "replication_dsync_parameters" as noted at the above page.
Question 2: Where can I find documentation about "replication_dsync_parameters" and about "the doveadm sync command" (referred to at the same page)? I have not been able to locate such a documentation/wiki page.
Question 2a: What do options "-d -N -l 30 -U" signify in "replication_dsync_parameters = -d -N -l 30 -U"?
Thanks, Nick
On 28/3/2014 11:58 πμ, Nikolaos Milas wrote:
When I started the server (vmail.example.com), mirroring started and completed fine (after a few hours).
However, since then, I am not seeing a continued mirroring between the two. I would expect changes to one of the masters to be propagated in real time to the other - which does not happen.
If I manually run (on vmail.example.com):
dsync -u imaptester mirror ssh -l root vmail1.example.com dsync -u imaptester
then these two accounts are synced.
I am trying to figure out whether replication plugin is configured correctly (- I guess something is wrong).
I have (in vmail.example.com dovecot.conf):
dsync_remote_cmd = ssh -l root vmail1.example.com doveadm dsync-server -u%u
plugin { mail_replica = remote:vmail@vmail1.example.com }
The question here is, in:
mail_replica = remote:vmail@vmail1.example.com
the reference: "vmail@" refers to the virtual user under whom accounts live in the remote system (which I have assumed), or something else?
Also, in the aggregator service, is there something wrong?
service aggregator { fifo_listener replication-notify-fifo { user = vmail } unix_listener replication-notify { user = vmail } }
Note that I am not using Director.
Follows the whole configuration on the main master, for your reference (I've only changed the true domain name). Dovecot conf on the mirror server is exactly the same without the replication bits.
Please advise.
Thanks, Nick
====================================================================== # 2.2.12: dovecot.conf
protocols = imap pop3
login_greeting = Org POP/IMAP Srv XAPITI XPICTOY
mail_location = maildir:~/Maildir/ mail_gid = 500 mail_uid = 500
auth_mechanisms = plain login auth_username_format = %Lu
auth_verbose = yes auth_debug = no
disable_plaintext_auth = no
mail_plugins = quota notify replication
protocol imap { imap_client_workarounds = "delay-newmail" mail_plugins = quota imap_quota }
protocol pop3 { mail_max_userip_connections = 3 mail_plugins = quota pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_uidl_format = %08Xu%08Xv }
protocol lda { auth_socket_path = /var/run/dovecot/auth-master info_log_path = log_path = mail_plugins = quota postmaster_address = sysadmin@example.com sendmail_path = /usr/lib/sendmail }
userdb { args = /etc/dovecot/dovecot-usrdb-ldap.conf driver = ldap }
passdb { args = /etc/dovecot/dovecot-passdb-ldap.conf driver = ldap }
dsync_remote_cmd = ssh -l root vmail1.example.com doveadm dsync-server -u%u
plugin { mail_replica = remote:vmail@vmail1.example.com }
plugin { quota = maildir:User quota quota_rule = *:storage=4G quota_rule2 = Trash:storage=+3%% quota_warning = storage=75%% quota-warning 75 %u quota_warning2 = storage=90%% quota-warning 90 %u }
service quota-warning { executable = script /opt/mail1.sh user = vmail unix_listener quota-warning { user = vmail } }
service aggregator { fifo_listener replication-notify-fifo { user = vmail } unix_listener replication-notify { user = vmail } }
service replicator { unix_listener replicator-doveadm { mode = 0600 } }
service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-master { group = vmail mode = 0660 user = vmail } user = root }
service imap-login { service_count = 1 vsz_limit = 64 M }
service pop3-login { service_count = 1 vsz_limit = 64 M }
service replicator { process_min_avail = 1 }
ssl_ca =
syslog_facility = local1
On 28/3/2014 10:40 μμ, Nikolaos Milas wrote:
When I started the server (vmail.example.com), mirroring started and completed fine (after a few hours).
However, since then, I am not seeing a continued mirroring between the two. I would expect changes to one of the masters to be propagated in real time to the other - which does not happen.
Hi,
I found this older thread:
http://comments.gmane.org/gmane.mail.imap.dovecot/69148
which provided the solution to my issues (I had to enable the replication plugin on pop3/imap/lda services).
Things seem to be working fine now. I only wish dsync logging were a bit more verbose; I don't know how this can be done. If anyone knows, I would appreciate this info.
Case closed for now.
Best regards, Nick
On Fri, 2014-03-28 at 11:58 +0200, Nikolaos Milas wrote:
Question 2a: What do options "-d -N -l 30 -U" signify in "replication_dsync_parameters = -d -N -l 30 -U"?
I'd also be interested to know the answer to this part. I found mention of the '-f' option, and adding '-f' to that list appears to have fixed a replication race condition I was having, but I can't find out a note of what it does.
Simon.
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
On 31/3/2014 12:03 μμ, Simon Fraser wrote:
On Fri, 2014-03-28 at 11:58 +0200, Nikolaos Milas wrote:
Question 2a: What do options "-d -N -l 30 -U" signify in "replication_dsync_parameters = -d -N -l 30 -U"? I'd also be interested to know the answer to this part. I found mention of the '-f' option, and adding '-f' to that list appears to have fixed a replication race condition I was having, but I can't find out a note of what it does.
There is no one who knows that? Or no documentation whatsoever?
Anyone please?
How can we determine whether we need to configure "replication_dsync_parameters = -d -N -l 30 -U" as indicated on the wiki2 (or some variation thereof) or not?
Thanks, Nick
On 2014-04-04 11:42, Nikolaos Milas wrote:
On 31/3/2014 12:03 μμ, Simon Fraser wrote:
On Fri, 2014-03-28 at 11:58 +0200, Nikolaos Milas wrote:
Question 2a: What do options "-d -N -l 30 -U" signify in "replication_dsync_parameters = -d -N -l 30 -U"? I'd also be interested to know the answer to this part. I found mention of the '-f' option, and adding '-f' to that list appears to have fixed a replication race condition I was having, but I can't find out a note of what it does.
There is no one who knows that? Or no documentation whatsoever?
Anyone please?
How can we determine whether we need to configure "replication_dsync_parameters = -d -N -l 30 -U" as indicated on the wiki2 (or some variation thereof) or not?
It does appear to be completely undocumented, I tried looking in the source code but just ended up going in circles (i'm not familiar with it at all).
"doveadm sync" has no documentation that I can find at all. I would happily write it if I could find the options in the code lol
/A
On 4/4/2014 1:17 μμ, Alan McGinlay wrote:
It does appear to be completely undocumented,
We would appreciate if Timo can kindly provide us with -at least- some details!
I tried looking in the source code but just ended up going in circles (i'm not familiar with it at all).
I faced the same difficulties... :-(
Nick
On 04/04/2014 12:42 PM, Nikolaos Milas wrote:
Anyone please?
How can we determine whether we need to configure "replication_dsync_parameters = -d -N -l 30 -U" as indicated on the wiki2 (or some variation thereof) or not?
I am definitely not Timo, but I will try a short answer based on my limited familiarity with the dsync replication functionality and code.
-d Use a default location for the replica. As far as I can tell this is obtained from userdb variable mail_replica. -N Sync all (visible?) namespaces (only makes sense when syncing with a remote host, with potentially different namespaces) (instead of either -n <namespace to sync> or -x <namespaces not to sync>) -l <seconds> Use a dsync lock file when syncing and the timeout for locking. -U Update replicator server on the status of the replication
For replicating in a multiple server configuration, they sound like a good idea to me.
Hope this helps a little, Teemu Huovila
On Fri, 2014-04-04 at 15:34 +0300, Teemu Huovila wrote:
-d Use a default location for the replica. As far as I can tell this is obtained from userdb variable mail_replica. -N Sync all (visible?) namespaces (only makes sense when syncing with a remote host, with potentially different namespaces) (instead of either -n <namespace to sync> or -x <namespaces not to sync>) -l <seconds> Use a dsync lock file when syncing and the timeout for locking. -U Update replicator server on the status of the replication
For replicating in a multiple server configuration, they sound like a good idea to me.
Hope this helps a little,
It does help, thank you. Do you also know what the '-f' option does?
Simon.
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Hi
On 04/04/2014 03:38 PM, Simon Fraser wrote:
It does help, thank you. Do you also know what the '-f' option does? According to the dsync-man page it:
Makes dsync run in "full sync" mode rather than "fast sync" mode. In fast sync mode dsync might skip syncing a mailbox, if both locations had modified it equally many times (i.e. highest-modseqs were equal), but with different changes.
br, Teemu Huovila
On Fri, 2014-04-04 at 15:41 +0300, Teemu Huovila wrote:
Hi
On 04/04/2014 03:38 PM, Simon Fraser wrote:
It does help, thank you. Do you also know what the '-f' option does? According to the dsync-man page it:
Makes dsync run in "full sync" mode rather than "fast sync" mode. In fast sync mode dsync might skip syncing a mailbox, if both locations had modified it equally many times (i.e. highest-modseqs were equal), but with different changes.
Thank you. Is it still only the changes that are synced each way, or the entire mailbox? I'm trying to gauge the performance hit for enabling this on larger mailboxes. (I could, of course, run some tests, but someone may already have done that)
Simon.
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Thank you. Is it still only the changes that are synced each way, or the entire mailbox? I'm trying to gauge the performance hit for enabling this on larger mailboxes. (I could, of course, run some tests, but someone may already have done that) Cant say anything certain on this one. I do know that not all the messages are sent to the other side. There are optimizations in place, using the Dovecot transaction logs and some pretty complicated application login, but a lot of data still needs to be
On 04/07/2014 12:22 PM, Simon Fraser wrote: processed by the dsync "brains".
I think testing with your particular setup and data would give the most accurate results.
br, Teemu Huovila
participants (4)
-
Alan McGinlay
-
Nikolaos Milas
-
Simon Fraser
-
Teemu Huovila