failover scenario's for replication

[Wesley Craig]

On 29 Aug 2006, at 04:11, Paul Dekkers wrote:
> I haven't tried this; but does it hurt defining sync_server, imapd and
> friends processes in the replicas cyrus.conf and by that have it
> identical as the master?

If you tell the replica where mupdate is, sync_server behaves  
incorrectly.  I'd also avoid running imapd on a replica, unless I  
could guarantee that users couldn't get to it.

> (I'm still thinking of nice ways to control (/automatically  
> restart) the
> sync_client; It doesn't write out a pid, daemon (on FreeBSD) doesn't
> create the right pidfile for the thing, so things like monit or the
> restartwrapper fail to control the thing... It doesn't stay in
> foreground while in rolling mode... Maybe just have check_procs from
> Nagios look at the process-string (or any other thing that looks in
> /proc or ps). What do others do? Wesley's suggestion for having a
> seperate init-script in the same runlevel still looks 'manual' to me,
> and/or that's not the part that generates an alert.

We run the attached script periodically.

> Maybe I'd write a patch for staying in foreground and/or writing out a
> pidfile ;-))

We've toyed with the idea of making it stay in the foreground, so we  
could run it from init.  In the current implementation, tho, when it  
exits it needs operator intervention, so automatic restart is no use  
-- it will just exit again.  The real solution is to make the code  
more resilient.

And on a separate track, we need an overarching strategy for high  
availability.

:wes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: replnag
Type: application/octet-stream
Size: 984 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20060829/4be9b90d/replnag.obj