I've figured out the problem.
If you mount the glusterfs with native client on a peer, if another peer
crashes then doesn't self-heal after reboot.
Should I put this issue in the bug tracker?
Bye
Raf
----- Original Message -----
From: "R.C." <[email protected]>
To: <[email protected]>
Sent: Monday, March 14, 2011 11:41 PM
Subject: Best practices after a peer failure?
Hello to the list.
I'm practicing GlusterFS in various topologies by means of multiple
Virtualbox VMs.
As the standard system administrator, I'm mainly interested in disaster
recovery scenarios. The first being a replica 2 configuration, with one
peer crashing (actually stopping VM abruptly) during data writing to the
volume.
After rebooting the stopped VM and relaunching the gluster deamon (service
glusterd start), the cluster doesn't start healing by itself.
I've also tried the suggested commands:
find <gluster-mount> -print0 | xargs --null stat >/dev/null
and
find <gluster-mount> -type f -exec dd if='{}' of=/dev/null bs=1M \; >
/dev/null 2>&1
without success.
A rebalance command recreates replicas but, when accessing cluster, the
always-alive client is the only one committing data to disk.
Where am I misoperating?
Thank you for your support.
Raf
_______________________________________________
Gluster-users mailing list
[email protected]
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
