gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] solutions for split brain situation


From: Mark Mielke
Subject: Re: [Gluster-devel] solutions for split brain situation
Date: Mon, 14 Sep 2009 23:46:16 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

On 09/14/2009 07:28 PM, Stephan von Krawczynski wrote:
I have problems in understanding exactly the heart of your question. Since the
main reason for rsyncing the data was to take a backup of the primary server,
so that self heal would have less to do it is obvious (to me) that it has been
a subvolume of the replicate. In fact is was a backup of the _only_ subvolume
(remember we configured a replicate with two servers, where one of them was
actually not there until we offline fed it with the active servers' data and
then tried to switch it online in glusterfs.

A potentially valid question here - if the backend storage was a database as other solutions use, would you expect this to work?

To some degree, rsync from backup is opening up the black box and shoving stuff in that you think, in theory, should work.

I don't think this is really the definition of self-heal. I think of self-heal is repairing damage. Really, you are sending it all new data (extracting from a lossy backup copy) that happens to indirectly inherit from previous data, happens to use the same path names, and asking it to reconcile the differences. What is being saved here? Even in a self-heal situation - it's still going to have to re-write the files, unless it is able to detect that some of the leading blocks are in common and only send the diffs? The files really are different.

Cheers,
mark

--
Mark Mielke<address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]