ok sorry for the confusion, i understand now kinda of what you are doing
at this point i am assuming the laptop is portable and offsite.
to answer the pgsql setup first :
basically when a new email comes in on a server it gets flagged in the
user entry in the db explaining that a replication event needs to occur.
this is what the notify option does, when a notify event in imap happens
that user gets flagged in the db entry for that user. it also tracks
weather or not it is an active mailbox in the db versus an alias etc
adding to the logic of what is a real mb that needs to be replicated.
this is how dopvecot knows what to push and when on the fly.
in your case without the database dsync is forced to go sequentaly one
mailbox at a time because there is no quick way to know if the mailbox
changed or not.
please be aware that there IS a replicator db that runs locally to both
sides under the dovecot config dir but cross references with the db (at
least it is for me)
however as i mentioned i have only ever used it with a pgsql database ?
and with user mailbox config's
{{{
mail_location = maildir:~/
service doveadm {
process_limit = 0
process_min_avail = 0
idle_kill = 0
client_limit = 1
user = vmail
inet_listener {
port = 12345
}
}
service config {
unix_listener config {
user = vmail
}
}
}}}
basically the above tells dovecot to make a dir for the doman under a
user dir and then the users full email address
aka mine is
/data/dovecot/users/scom.ca/[email protected]
again this is all handled by the database (aka user name, passowrd
loctions etc etc etc)
in general i have setup scripts to support various status reporting for
replication
{{{
# cat /programs/common3/sync.status
doveadm replicator status
echo ' '
doveadm replicator dsync-status | grep -v 'Not connected'
}}}
{{{
# cat /programs/common3/sync.fullstatus
doveadm replicator status '*'
echo ' '
doveadm replicator dsync-status | grep -v 'Not connected'
}}}
the one above give yeplication status pending
{{{
# /programs/common3/sync.fullstatus | grep info
[email protected] none 01:47:05 71:24:40 02:46:22 -
[email protected] none 00:04:09 11:22:21 00:15:22 -
[email protected] none 03:28:59 03:28:59 03:28:59 -
[email protected] none 00:18:59 01:54:06 00:18:59 -
[email protected] none 01:19:48 01:28:30 01:28:30 -
[email protected] none 03:28:31 03:28:31 03:28:31 -
[email protected] none 10:57:20 10:57:20 10:57:19 -
[email protected] none 00:59:58 00:59:58 00:59:57 -
[email protected] none 01:14:58 01:38:15 01:38:15 -
[email protected] none 03:41:30 03:41:30 03:41:30 -
# /programs/common3/sync.status
Queued 'sync' requests 0
Queued 'high' requests 0
Queued 'low' requests 0
Queued 'failed' requests 0
Queued 'full resync' requests 0
Waiting 'failed' requests 0
Total number of known users 322
username type status
}}}
in the above example the '-' means the user is in sync between both
servers on THIS server. aka no replication push is needed.
This is how dovecot speeds up dsync requests as it knows what to skip.
In general if the db user entry is flagged to push emails (aka a change
happend on the local servers email account)
when a replicated server (in your case your laptop i guess) when the
laptop comes on line then the main server will push only mailbox changes.
and skip anything else
with all due respect the dsync / replication was not really designed to
auto update a server (laptop in your case) that can go offline all the time.
it was more designed for live replication and more so recovery when the
slave server went back on line.
aka server maintence,upgrades etc.
in general you could setup something that would work but if one end is
portable then a vpn/static ip's etc etc would be a good recomendation.
as i mentioned (and other people have) ssh does work but will bog down
on large email server replica's (like scom's) thus causing timeouts when
replicating.
this was all mostly by experience on what worked for SCOM. (With much
help from AKI)
without access to the main server and laptop i can not really elaborate
any further as testing this kind of setup would be key to get it working.
hope this helps a bit.
Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.)
Have A Happy Wednesday AND Happy Sucessful 2026 !
Scom.ca Internet Services <http://www.scom.ca>
104-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3
Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email [email protected]
On 2026-06-10 9:59 AM, Jesus Cea via dovecot wrote:
On 10/6/26 13:25, Paul Kudla via dovecot wrote:
also ssh does not work well, are you replicating on a private network
connection (aka direct connection between servers on a different sub
net) - i use 10.xx.xx.server1 & 10.xx.xx.server2 with a crossover cable.
I use SSH because my laptop is at home/hotel/on the go, and the server
is in a datacenter thousands of kilometers away :-). Yes, I am running a
local dovecot server in my laptop.
I just learned that replication is removed in 2.4. Ouch!
Thanks for your configuration, but you are not addressing the main point
of my email: performance.
I am using manual replication using "doveadm sync". It works fine, but
even when nothing changed, it takes 30 seconds because it compares each
of my >400 mailboxes in my IMAP4 account.
I was wondering if I am missing something and that if using internal
dovecot replication (dead in 2.4, but apparently solvable via the
external wormhole extension) the overload would be lower.
also this is based on using mysql or postgresql databasing for auth,
other auth mechs will be a crap shoot as dovecot uses a database entry
to track the replication requests
Could you elaborate this?
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
