Cluster Issues
Failed actions:
apache2_monitor_10000 (node=bacon, call=102, rc=7, status=complete): not running
apache2_start_0 (node=bacon, call=104, rc=1, status=complete): unknown error
5 Replies
@Guspaz:
Unison shouldn't be better in terms of bandwidth usage than rsync, since it basically is rsync; it use the rsync algorithm.
rsync was using copious amounts of bandwidth compared to Unison. Unison uses as much as idle bandwidth, rsync used about ~2mbits each time it ran. Plus, Unison synchronizes in both directions.
@clayfreeman:
@Guspaz:Unison shouldn't be better in terms of bandwidth usage than rsync, since it basically is rsync; it use the rsync algorithm.
rsync was using copious amounts of bandwidth compared to Unison. Unison uses as much as idle bandwidth, rsync used about ~2mbits each time it ran. Plus, Unison synchronizes in both directions.
It sounds like you may have misconfigured rsync. As I said, they both use the same algorithm for synchronizing data (you can read about this on the Unison website if you don't believe me), and they're both going to have to exchange a certain amount of information to determine what needs to be synced.
rsync relies on the file size and modification date to determine if a file has changed, although this behaviour can be changed to only rely on the filesize (useful for files that only ever grow) or to replace the modification date with a 128-bit checksum. rsync's default method requires a minimum of disk IO to detedmine updated files
Unison's default method is to do a full checksum of every file on both sides and compare those. It's a little bit more efficient for network IO, but enormously more intensive for IO.
You're definitely correct that they're not intended to accomplish exactly the same thing, though. Unison is intended for bi-directional synchronization, although I'm not sure why you'd ever want bi-directional sync in an HA cluster. That sounds dangerous.