I've done and am doing this. For questions 1 and 2 I don't really have an answer because bandwidth wasn't an issue for me / the people I set this up for.
In the past I found that if Cyrus is restarted on the replica, the sync_client on the master server fails. I also saw instances of sync_client failing on the master if the replica isn't available. The lower levels pertaining to why I don't know (or remember), but I can recreate this and post the exact error that is logged if any one on this list is interested.
Here's a bash script executed by the cron daemon on a pair of Cyrus servers every minute for watch-dogging sync_client.
#!/bin/bash
if [ "$(pgrep cyrus-master)" ] ; then
if [ "$(cat /etc/cyrus-role)" == "master" ] ; then
if [ ! "$(pgrep sync_client)" ] ; then
su cyrus -c "/usr/lib/cyrus-imapd/sync_client -r" ;
fi
fi
fi
if [ "$(cat /etc/cyrus-role)" == "replica" ] ; then
if [ "$(pgrep sync_client)" ] ; then
kill $(pgrep sync_client)
fi
fi
The script checks for the conditions that the server is set as the master (which it is set to if Cyrus is started) and that the sync_client is not running. If so it runs the sync_client again.
The script does not check if the Cyrus daemon is running because it was written taking into consideration a scenario where replication hasn't occurred for some arbitrary amount of time while the Cyrus daemon was running but replication once again becomes possible while the Cyrus daemon local to the master is not running.
You can also use this script to enable bi-directional IMAP replication. Why you would want to do such a thing (with a two-server master/replica configuration) is if you have SMTP daemons running on both of your Cyrus servers and want the "replica"/"passive" (IMAP-side at least) server to be able to push mail accepted by it from the outside world onto the master Cyrus server. This is probably better (and faster for the user) than simply dropping packets from outside SMTP servers (which is what I've seen on two-server master/replica Cyrus servers out there, fencing was done through setting ports as "filtered'). Because a user's IMAP activity on the master server shouldn't conflict with incoming mail, in theory bi-directional Cyrus replication for incoming messages from the SMTP daemon is not only optimal but also possible without creating a split-brain scenario. I plan to test this myself when I have time.
This was all done with Cyrus 2.3.7 on CentOS 5.3 and 5.4 in each case. Your mileage may vary and if any of the behavior described above is expected to be different with new versions of Cyrus please share.
- Jon
In the past I found that if Cyrus is restarted on the replica, the sync_client on the master server fails. I also saw instances of sync_client failing on the master if the replica isn't available. The lower levels pertaining to why I don't know (or remember), but I can recreate this and post the exact error that is logged if any one on this list is interested.
Here's a bash script executed by the cron daemon on a pair of Cyrus servers every minute for watch-dogging sync_client.
#!/bin/bash
if [ "$(pgrep cyrus-master)" ] ; then
if [ "$(cat /etc/cyrus-role)" == "master" ] ; then
if [ ! "$(pgrep sync_client)" ] ; then
su cyrus -c "/usr/lib/cyrus-imapd/sync_client -r" ;
fi
fi
fi
if [ "$(cat /etc/cyrus-role)" == "replica" ] ; then
if [ "$(pgrep sync_client)" ] ; then
kill $(pgrep sync_client)
fi
fi
The script checks for the conditions that the server is set as the master (which it is set to if Cyrus is started) and that the sync_client is not running. If so it runs the sync_client again.
The script does not check if the Cyrus daemon is running because it was written taking into consideration a scenario where replication hasn't occurred for some arbitrary amount of time while the Cyrus daemon was running but replication once again becomes possible while the Cyrus daemon local to the master is not running.
You can also use this script to enable bi-directional IMAP replication. Why you would want to do such a thing (with a two-server master/replica configuration) is if you have SMTP daemons running on both of your Cyrus servers and want the "replica"/"passive" (IMAP-side at least) server to be able to push mail accepted by it from the outside world onto the master Cyrus server. This is probably better (and faster for the user) than simply dropping packets from outside SMTP servers (which is what I've seen on two-server master/replica Cyrus servers out there, fencing was done through setting ports as "filtered'). Because a user's IMAP activity on the master server shouldn't conflict with incoming mail, in theory bi-directional Cyrus replication for incoming messages from the SMTP daemon is not only optimal but also possible without creating a split-brain scenario. I plan to test this myself when I have time.
This was all done with Cyrus 2.3.7 on CentOS 5.3 and 5.4 in each case. Your mileage may vary and if any of the behavior described above is expected to be different with new versions of Cyrus please share.
- Jon
On Wed, Dec 9, 2009 at 8:08 AM, Robert Mueller (web) <robm@xxxxxxxxxxx> wrote:
I just wanted to check if any people have any experience or reports
about doing cyrus replication over a WAN?
A few potential issues spring to mind:
1. I know the replication protocol is pretty "chatty", so does the
higher latency over a WAN (ms vs us) cause it to get behind more
regularly?
2. The protocol uses more bandwidth than really needed, has that caused
unexpected bandwidth usage problems?
3. A WAN isn't nearly as reliable as a local connection. If you're over
a VPN, and the connection goes down for a minute and then comes back,
does that confuse the sync_client, or does it tend to just continue and
work?
Any insights would be appreciated.
Rob
Rob Mueller
robm@xxxxxxxxxxx
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
