Live backup

[Elver Loho]

Hey Bron,

I'm running Cyrus on Fedora 12, with the version number being
2.3.16-3.fc12 according to yum.

By the way, how can I verify that replication is working and is up-to-date?
When does sync_client fail and what does it leave behind that I should
be worried about? Can you share your scripts in that regard?

And are these log messages normal?

Jun 16 17:51:08 localhost syncserver[20969]: login: sahtel
[192.168.0.1] cyrus PLAIN User logged in
Jun 16 17:51:08 localhost syncserver[20969]: created decompress buffer
of 4102 bytes
Jun 16 17:51:08 localhost syncserver[20969]: created compress buffer
of 4102 bytes
Jun 16 17:56:15 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 17:57:54 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:00:17 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:08:51 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:11:26 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:12:04 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:13:40 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:14:11 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:14:57 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:17:10 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:17:22 localhost syncserver[20969]: Expunged 4 messages from
user.margus
Jun 16 18:18:26 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:20:36 localhost master[21189]: about to exec
/usr/lib/cyrus-imapd/ctl_cyrusdb
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: checkpointing cyrus databases
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving log file:
/var/lib/imap/db/log.0000000001
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving log file:
/var/lib/imap/db/log.0000000001
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving log file:
/var/lib/imap/db/log.0000000001
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving database file:
/var/lib/imap/annotations.db
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving database file:
/var/lib/imap/mailboxes.db
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: archiving log file:
/var/lib/imap/db/log.0000000001
Jun 16 18:20:36 localhost ctl_cyrusdb[21189]: done checkpointing cyrus databases
Jun 16 18:20:36 localhost master[20938]: process 21189 exited, status 0
Jun 16 18:20:45 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:21:02 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:23:58 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:24:06 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:25:09 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:25:11 localhost syncserver[20969]: skiplist: checkpointed
/var/lib/imap/mailboxes.db (90 records, 7936 bytes) in 0 seconds
Jun 16 18:25:25 localhost syncserver[20969]: UPLOAD: issuing RESTART
Jun 16 18:26:01 localhost syncserver[20969]: UPLOAD: issuing RESTART


Best,
Elver

elver.loho at gmail.com
+372 5661 6933
http://elver.wordpress.com/
skype: elver.loho

On 16 June 2010 17:27, Bron Gondwana <brong at fastmail.fm> wrote:
> On Wed, Jun 16, 2010 at 05:19:25PM +0300, Elver Loho wrote:
>> Replication looks to be the solution. Surprisingly I hadn't discovered
>> it on my own. Many thanks to everyone for pointing it out!
>>
>> However, while setting it up, I noticed a really weird thing. When
>> authentication fails on the master-initiated master->slave connection,
>> master will block connections from all clients! That's a seriously
>> weird design choice. Does the same thing happen when the slave goes
>> down? For example, if I reboot the slave, is the master mail server
>> down for everyone while the slave reboots? I have not dared to
>> experiment as when authentication failed and the Cyrus master server
>> stopped letting clients connect, everyone in the office started
>> shouting within seconds.
>
> What version of cyrus are you using?
>
> I recommend adding the -o flag to sync_client in cyrus.conf (try
> ONCE then drop out) - otherwise it keeps trying for roughly 1000
> seconds before giving up.  And yes, that's a crazy design decision,
> which is why I added the -o flag!
>
> You also need to monitor it a bit to make sure there's still a
> sync_client running - because bail outs can cause it to go away.
> We run a cron job that checks on the sync clients every 10 minutes
> and reports if any are missing - runs sync_client -r -f on the
> files left behind by any that have previous died, and generally
> keeps things tidy :)
>
> Bron.
>