Re: [Dovecot] Live Mirror dovecot / OS X 10.6.4 (Timo Sirainen)
Timo Sirainen tss@iki.fi wrote:
Two potential problems I see with this:
If users can do any changes on the secondary server (flag changes, saving new mails, etc), you're going to have problems syncing the changes back (without losing any changes or causing other problems).
If users can access the secondary server via IMAP clients, the clients could become confused if the secondary server isn't completely up-to-date.
With v2.0 dsync would help with the first problem.
Change in strategy. Primary rsyncs regularly to the secondary which keeps all mail services off. When primary fails email services are started manually until primary back online. Then I (or another ITer) manually stop the backup, rsycn and restart services on the primary. A bit labor intensive, but it should work.
So getting back to this backup server concept... Would rsyncing all the directories listed in a dovecotd -n dump be enough to sync all my virtual users/uids, etc.? Or does OS X have other locations I need to sync for this backup server to be functional when the primary is down?
On Wed, 2010-08-25 at 09:35 -0400, Eric Boltz (MMI/UPC) wrote:
So getting back to this backup server concept... Would rsyncing all the directories listed in a dovecotd -n dump be enough to sync all my virtual users/uids, etc.?
You need to rsync the mail directory. You don't need to rsync base_dir. What else is there?.. You need to sync the users somehow.
Or does OS X have other locations I need to sync for this backup server to be functional when the primary is down?
No idea.
On Wed, 2010-08-25 at 05:43 -0400, Eric Boltz (MMI / UPC) wrote:
- If users can do any changes on the secondary server (flag changes, saving new mails, etc), you're going to have problems syncing the changes back (without losing any changes or causing other problems).
Change in strategy. Primary rsyncs regularly to the secondary which keeps all mail services off. When primary fails email services are started manually until primary back online.
Okay..
Then I (or another ITer) manually stop the backup, rsycn and restart services on the primary.
But if secondary server allowed changes, this is the difficult step to do correctly. For example lets say in first server:
- It rsyncs user foo
- User foo changes message A flag to \Seen
- User foo deletes message B
- User foo saves a new message C
- The server crashes
- Secondary server goes up, but 2-4 changes weren't resynced yet
- User foo logs in and changes message D's flag to \Seen
- Primary server goes back up
- You rsync .. how? If you make primary server look exactly like secondary server, you message C gets lost. If you copy new files, now message A and message D gets duplicated, because their filename changed due to the flag change. Also message B becomes undeleted.
Of course assuming this happens rarely enough, those aren't a huge problem, but the server move isn't always transparent to users and you'll get errors in Dovecot's logs.
On Aug 25, 2010, at 10:15 AM, Timo Sirainen wrote:
But if secondary server allowed changes, this is the difficult step to do correctly. For example lets say in first server:
- It rsyncs user foo
- User foo changes message A flag to \Seen
- User foo deletes message B
- User foo saves a new message C
- The server crashes
- Secondary server goes up, but 2-4 changes weren't resynced yet
- User foo logs in and changes message D's flag to \Seen
- Primary server goes back up
- You rsync .. how? If you make primary server look exactly like secondary server, you message C gets lost. If you copy new files, now message A and message D gets duplicated, because their filename changed due to the flag change. Also message B becomes undeleted.
Of course assuming this happens rarely enough, those aren't a huge problem, but the server move isn't always transparent to users and you'll get errors in Dovecot's logs.
First off, thanks. It will happen rarely (2-3x/year most likely base on prior power outages) and if a couple users get a duplicate message or unread when read issue they can file a complaint :) The transfer wouldn't be transparent - I would force them to webmail on the backup (maybe even force POP3?).
Now to figure out where the virtual user data is...sigh
On Wed, Aug 25, 2010 at 4:27 PM, Eric Boltz (MMI/UPC) eboltz@marathonmonitors.com wrote:
On Aug 25, 2010, at 10:15 AM, Timo Sirainen wrote:
But if secondary server allowed changes, this is the difficult step to do correctly. For example lets say in first server:
- It rsyncs user foo
- User foo changes message A flag to \Seen
- User foo deletes message B
- User foo saves a new message C
- The server crashes
- Secondary server goes up, but 2-4 changes weren't resynced yet
- User foo logs in and changes message D's flag to \Seen
- Primary server goes back up
- You rsync .. how? If you make primary server look exactly like secondary server, you message C gets lost. If you copy new files, now message A and message D gets duplicated, because their filename changed due to the flag change. Also message B becomes undeleted.
Of course assuming this happens rarely enough, those aren't a huge problem, but the server move isn't always transparent to users and you'll get errors in Dovecot's logs.
First off, thanks. It will happen rarely (2-3x/year most likely base on prior power outages) and if a couple users get a duplicate message or unread when read issue they can file a complaint :) The transfer wouldn't be transparent - I would force them to webmail on the backup (maybe even force POP3?).
Now to figure out where the virtual user data is...sigh
Would the "users" be the users in the Open Directory?
If that's the case then you could probably "just" make the "backup" server an Open Directory Replica thus it would allways contain a (read only) copy of the user database…
PS.: I am also thinking about how to make a "hot standby" OS X 10.6.x Server mail server ;-)
- TvE
participants (4)
-
Eric Boltz (MMI / UPC)
-
Eric Boltz (MMI/UPC)
-
Thomas von Eyben
-
Timo Sirainen