I don't see any errors. But...
As a work-around, I tried the (equivalent of the) following:
mkdir /mnt/.tmp
chown nobody:nobody /mnt/tmp #rsync uses "nobody"
ln -s ../.tmp /mnt/master-volume
I then changed /etc/rsyncd.conf's [master-volume] entry to:
path = /mnt/
Do you see any errors in Master logs?
(/var/log/glusterfs/geo-replication//*.log)
regards
Aravinda
On 10/15/2015 07:51 PM, Brian Ericson wrote:
Thanks!
As near as I can tell, the GlusterFS thinks it's done -- I finally
ended up renaming the files myself after waiting a couple of days.
If I
Thanks!
As near as I can tell, the GlusterFS thinks it's done -- I finally ended
up renaming the files myself after waiting a couple of days.
If I take an idle master/slave (no pending writes) and do an rsync to
copy a file to the master volume, I can see that the file is otherwise
correct (
Slave will be eventually consistent. If rsync created temp files in
Master Volume and renamed, that gets recorded in Changelogs(Journal).
Exact same steps will be replayed in Slave Volume. If no errors, Geo-rep
should unlink temp files in Slave and retain actual files.
Let us know if Issue pers
Admittedly an odd case, but...
o I have simple a simple geo-replication setup: master -> slave.
o I've mounted the master's volume on the master host.
o I've also setup rsyncd server on the master:
[master-volume]
path = /mnt/master-volume
read only = false
o I now rsync from
