[Gluster-devel] solutions for split brain situation

Mark Mielke mark at mark.mielke.cc
Wed Sep 16 21:26:07 UTC 2009

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 

> 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.


Mark Mielke<mark at mielke.cc>

More information about the Gluster-devel mailing list