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: Wed, 16 Sep 2009 17:26:07 -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/16/2009 09:17 AM, Stephan von Krawczynski wrote:
Well, Michael, Mark, maybe we should talk more about real setups and less
about theory. In theory everything you say makes sense, and clearly your
"don't do that" approach is clean.
Unfortunately the real world ist not that clean and hardly ever can be bent to
be. But fortunately theory looks at setup that are rare in real world.

Right. It's not clean. Which means, that you can't expect to dump a bunch of files into a carefully replicated cluster backing store, and expect things to ever "just work". All sorts of complex rules can be made up to fit specific cases, but the concept is just bad from the start.

If you want to insert the data - figure out what the correct metadata should be, and apply it while your volume is down. Does that really sound unsolvable? (For simplicity we assume such local feeds

Another story: the backup
I am pretty astonished that you all talk about backuping the xattribs. But
according to your own clean philosophy there should be no problem for backups
without xattribs as long as they are read in from the glusterfs mountpoint.

No - I didn't say that. I said the close to the opposite. The backup should be done through the mount point too. Backup of the backing store doesn't guarantee a clean restore. You found this out already. Even making sure the attributes are backed up doesn't guarantee a clean restore. It's somewhat similar to taking a few files from a PostgreSQL or Oracle database and shoving them on backup, and then throwing them back into place later and expecting things to "just work". The content is the same, you say. But, is it?

Since other applications do not honor the xattribs either that can only mean
that a backup must be a complete snapshot without them.

This still assumes backup from backing file system, which is a bad idea if you actually intend to restore to the backing file system underneath GlusterFS. It's only a good idea if you are keeping a "just in case", in which case, you should really restore on top of the mount point - not to the backing file system.

Cheers,
mark

--
Mark Mielke<address@hidden>





reply via email to

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