<div dir="ltr"><div><div><div>If you're not sure just pick one and save the other.<br><br></div>Steps I did:<br></div>save one of the qcow2 file split-brains (copy from brick to another name)<br>removed the qcow2 file that you just "backed up". Gluster will heal with the other one.<br>
restart VM<br>if VM recorvers after a fsck then just delete the saved qcow2 file<br> otherwise try the other.<br>If they are both messed up use other backup plans or rebuilt the VM.<br></div> stuff happens<br><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 1:50 AM, Joćo Pagaime <span dir="ltr"><<a href="mailto:joao.pagaime@gmail.com" target="_blank">joao.pagaime@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>thanks<br>
<br>
but which qcow2/FVM file choose for deletion? maybe there is
some known current best-practice for the VM maximum stability<br>
<br>
if the VM is frozen the decision maybe to delete the oldest
qcow2/FVM file, or random choose if there is no difference<br>
<br>
best regards,<br>
--joćo<br>
<br>
<br>
<br>
<br>
Em 05-03-2014 20:26, Bryan Whitehead escreveu:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>I followed this blog: <a href="http://geekshell.org/%7Epivo/glusterfs-split-brain.html" target="_blank">http://geekshell.org/~pivo/glusterfs-split-brain.html</a><br>
</div>
<div>(this can take too long because of using "find" if you have
many files)<br>
</div>
<div><br>
</div>
Right after Joe Julian released a pretty handy system for
exploring the split brains and fixing. You can check it out
here:<br>
<a href="http://joejulian.name/blog/glusterfs-split-brain-recovery-made-easy/" target="_blank">http://joejulian.name/blog/glusterfs-split-brain-recovery-made-easy/</a><br>
<a href="https://github.com/joejulian/glusterfs-splitbrain" target="_blank">https://github.com/joejulian/glusterfs-splitbrain</a><br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 5, 2014 at 1:40 AM, Joćo
Pagaime <span dir="ltr"><<a href="mailto:joao.pagaime@gmail.com" target="_blank">joao.pagaime@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>hello Bryan and thanks for sharing!<br>
<br>
how did you fix those 2 files on a split-brain
situation? deleted one "bad" file?
<div>
<div>
<div style="display:inline-block">
<div><span></span></div>
</div>
</div>
</div>
<div>
<div dir="ltr" style="zoom:1">
<div><span lang="en"><span> which</span></span> one
to select for deletion?<br>
<br>
on an software update situation I would expect not
to have peer probe problems, simply because there
are no "gluster peer probe" commands. The problem
that could happen is the updated 3.4.2 node having
problems reentering a 3.3.0 cluster (without
"peer probes" commands). It's good news it went
well<br>
<br>
best regards<br>
joao<br>
</div>
</div>
</div>
<br>
Em 04-03-2014 18:30, Bryan Whitehead escreveu:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>I just did this last week from
3.3.0->3.4.2.<br>
<br>
I never got the peer probe problems - but I did
end up with 2 files being in a split-brain
situation.<br>
<br>
</div>
Note: I only had ~hundred files that are qcow2 for
KVM, so 2 files getting split-brain is about 2%
filesystem problem.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Mar 4, 2014 at
1:43 AM, Joćo Pagaime <span dir="ltr"><<a href="mailto:joao.pagaime@gmail.com" target="_blank">joao.pagaime@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all<br>
<br>
anyone tried a rolling upgrades with no
downtime [1] from 3.3.0 to 3.4.2 or similar
upgrade? any comments?<br>
<br>
for testing purposes we've installed a 3.4.2
server and it won't peer, giving the error
"peer probe: failed: Peer X does not support
required op-version".<br>
<br>
I guess this is expected behavior for a new
entry on the cluster<br>
<br>
What about changing the software on an
existing peer of the cluster? Will it also
refuse to re-enter the cluster after the
upgrade for the same reason (peers not
supporting the required op-version)?<br>
<br>
After all servers and clients are upgraded,
how to increase the op-version of the global
cluster?<br>
<br>
best regards,<br>
joćo<br>
<br>
[1]<br>
<a href="http://vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4/" target="_blank">http://vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4/</a><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>