sven.schwedas at tao.at
Thu Apr 18 05:59:31 EDT 2013
On 18.04.2013 11:24, Janne Peltonen wrote:
> On Thu, Apr 18, 2013 at 10:45:03AM +0200, Sven Schwedas wrote:
>> If I understand correctly, failover is simply done by pointing clients
>> to the replica (e.g. moving public IP)?
> More or less. You'll also have to make sure sync_server is no longer running on
> the replica but all the other relevant services are, so that users can connect.
>> We can assume that only one server is ever accessed by clients (both
>> IMAP and SMTP/LMTP), they only have access to the public IP, which is
>> switched over manually.
> Ok. But as an added security measure, you should still make sure that the
> sync_server isn't running on the replica-as-master. (And sync_client shouldn't
> be running on the original master.)
>> How do I then migrate the data over to the master once it's running again?
>> • Is master-master replication possible in this case?
> I gather it is only supported in the forthcoming 2.5 release.
Too bad. :(
>> • If not, how do I move the data back to the master? Shut down the
>> replica and rsync the spool back to the master?
> You could do that, I guess, but that would result in quite a downtime. We
> simply run the master as the replica for a while (sync_server
> running on the original master and sync_client on the original replica), force
> a sync to all users and shared folders and then switch the IPs back.
> (To be more exact, each 'role change' (switching of master/replica roles and
> reverting to original) consists of
> 1) force syncronisation
> 3) manually run any remaining synclogs
How do I do that / what's the difference between forced sync and a
manual sync log run?
> 4) shut down current replica 5)
> change ip 6) start master services in what used to be replica 7) make sure
> everything appears to be ok 8) start sync_server in what used to be master)
Mit freundlichen Grüßen, / Best Regards,
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas at tao.at | +43 (0)680 301 7167
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 665 bytes
Desc: OpenPGP digital signature
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20130418/587b69db/attachment-0001.bin
More information about the Info-cyrus