> parameters. You don't have to use rsync, that's just the default. I am > currently experimenting with using csync2, as that provides the very feature > you mentioned above - it is specifically designed for 1->many cluster > synchronisation. Great points, and I had just gotten csync2 installed and working between two nodes a few days ago and really like it. My only concern is requiring the csync2 daemon running on the remote clusters, since they won't all be 'our' clusters, having SSH access may be the most we can do. P On Thu, May 20, 2010 at 3:38 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > phil cryer wrote: >> >> I'm testing with lscynd now to sync remote clusters (ours running >> gluster, others may be, may not be) and it's working well. > > Just make sure you are running the latest trunk version. The exclude file > handling bugs were fixed about 5 hours ago. :-) > >> Also look >> at http://code.google.com/p/pylsyncd/ which boasts: >> >> "The main advantage of pylsyncd against lsyncd is that it uses message >> queues in order to synchronize in a parallel way several destination >> servers, saving up time when it is required to have more than one >> destination. It has been tested in heavy loaded environments." > > I saw it, but lsyncd looked better to me for the following reasons: > > 1) Speed - it's written in C. > > 2) lsyncd's rsync hooks are fully configurable - both the binary and the > parameters. You don't have to use rsync, that's just the default. I am > currently experimenting with using csync2, as that provides the very feature > you mentioned above - it is specifically designed for 1->many cluster > synchronisation. > > 3) I haven't managed to find any documentation on pylsyncd's handling for > excluding parts of the watched subtree, so I have to assume it cannot do > this. lsyncd understands a subset of rsync's exclude pattern syntax so it > both omits the excluded files from the watch and passes the same exclude > file to rsync. This is essential in my use case as I want to mirror root > directories across servers in a cluster. > > Gordan > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > -- http://philcryer.com
