Question
Dovecot Clustered Configuration vs. External Storage Replication for Zero-Downtime Migration
Rahul River
0 reputation · 03 Aug 2026, 10:47 UTC
70.6K views1
Loading…
0 reputation · 03 Aug 2026, 10:47 UTC
The objective is to migrate a small Dovecot deployment to a new node configuration while preserving continuous service availability for existing mail clients.
Key constraints involve determining whether Dovecot's hot reload mechanism can synchronize module settings across all cluster members without service interruption, and whether the underlying external storage replication guarantees that active sessions and mailbox state remain consistent during the transition.
How does hot reload behavior affect configuration synchronization across clustered nodes during migration? Can external storage replication ensure uninterrupted session state when reconfiguring Dovecot clusters?
35775 reputation · 03 Aug 2026, 15:58 UTC
Dovecot hot reload updates the in-memory configuration of each Dovecot process independently. It does not synchronize active IMAP sessions, mailbox locks, or authentication state across clustered nodes. External storage replication such as NFS, GlusterFS, or Ceph can keep dovecot.conf identical on every member, but it cannot preserve a client session if the connection is moved to a node that never held that state. Zero-downtime migration therefore requires a shared configuration source plus a traffic switch that leaves existing connections on their current nodes.
dovecotdoveadm reload or SIGHUP reloads configuration on the local process only./etc/dovecot/dovecot.conf and its includes on a shared filesystem mounted with strong consistency on every node.doveadm reload on each existing node and compare the config timestamp with the source file.| Item | Command |
|---|---|
| Config timestamp | stat /etc/dovecot/dovecot.conf |
| Mount consistency | mount | grep /etc/dovecot |
| Active sessions | doveadm socket list |
Is the Dovecot configuration stored on a shared filesystem that all nodes can read simultaneously?
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 03 Aug 2026, 19:24 UTC
The doveadm director move command updates the user-to-backend map, but the change propagates to all director instances with a default 2-second delay (director_consistency_timeout). During this window, new connections for the moved user may still route to the old backend. Plan cutover steps to account for this latency, especially when draining multiple users in sequence.
If dovecot.index* files reside on a shared filesystem (NFS, GlusterFS, Ceph), concurrent writes from multiple backends can corrupt indexes unless the director ensures only one backend serves a given user at a time. Set mail_fsync = optimized and mmap_disable = yes on NFS mounts, and verify lock_method = fcntl (default) works correctly on your storage. Stress-test concurrent access before production cutover.