Hi & thanks,
Well, obviously my intention is not to create a mess, but the reason for
redundancy is probably that servers may disappear from the cluster for a
while. In case I run any glusterfs commands related to the volume
definition at that time, those changes will not reach the unavailable
server. That's why I wonder how GlusterFS will sync such information
when the server is available again? In case I know how that is handled,
I'll know what I can do and what I cannot do.
Regards
Andreas
On 09/22/2015 01:05 PM, Alastair Neil wrote:
glusterd should handle syncing any changes you make with the "gluster"
command to the peers, obviously if you make local changes to the
volume file on one server you are likely to break things unless you
copy rsync the changes to the other server.
On 22 September 2015 at 04:02, Andreas Hollaus
<[email protected] <mailto:[email protected]>>
wrote:
Hi,
Are there any restrictions as to when I'm allowed to make changes
to the GlusterFS
volume (for instance: start/stop volume, add/remove brick or
peer)? How will it
handle such changes when one of my two replicated servers is down?
How will GlusterFS
know which set of configuration files it can trust when the other
server is connected
again and the files will contain different information about the
volume? If these
were data files on the GlusterFS volume that would have been
handled by the extended
file attributes, but how about the GlusterFS configuration itself?
Regards
Andreas
_______________________________________________
Gluster-users mailing list
[email protected] <mailto:[email protected]>
http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users
