<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Dear all,</p>
    <p>first of all thanks to Stefan (Kania) for the feedback. So
      detaching the peer, removing brick and downgrading to replica 2
      until you add a new brick as you would do with any otherwise
      faulty node.<br>
    </p>
    <p>So here is how we proceeded:</p>
    <ul>
      <li>check mounts where the faulty (ex-filled-up) node is present
        and remove it from there</li>
      <li>detach "bad" peer with:  gluster peer detach
        <your_faulty_gluster_node></li>
      <li>remove brick: gluster volume remove-brick <vol> replica
        2 <your_faulty_gluster_node>:<the_brick_path> force</li>
    </ul>
    <p>So in our case we are ready to add a new brick to restore our
      replica 3.<br>
    </p>
    <p>This should be safer (and in the end as simple) than just copying
      the missing files probably bringing along meta-data
      inconsistencies. Which was also the doubt expressed on this post.<br>
    </p>
    <div class="moz-cite-prefix">Am 08.01.24 um 11:13 schrieb Ilias
      Chasapakis forumZFD:<br>
    </div>
    <blockquote type="cite"
      cite="mid:60b97b2c-04e9-43d1-8c2b-d7c94a126304@forumZFD.de">Dear
      all,
      <br>
      <br>
      we have a replica 3 configuration an issue after that the file
      system filled up. The gluster daemon is not starting anymore on
      the affected node and the inconsistency that we noticed is that
      the /var/lib/glusterd/peers does contain only one "good" node and
      the other one is missing.
      <br>
      <br>
      Now what we would like to try is to probe from the affected peer
      the missing one. We also thought about just copying the missing
      node config file /var/lib/glusterd/peers here but we think this
      might be more inconsistent because perhaps of the time passed
      between finding out the issue and when the fill up had occurred
      (if this has relevance). We assume probing will fill that missing
      entry in the affected gluster and will sync to it. What we want to
      avoid is that this happens the other way around.
      <br>
      <br>
      So in brief the question is if in our situation probing is too
      risky and we should try other methods (removing-adding brick) or
      anything that you might want to suggest from your experience.
      <br>
      <br>
      Many thanks in advance
      <br>
      <br>
      Ilias
      <br>
      <br>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">________



Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: <a class="moz-txt-link-freetext" href="https://meet.google.com/cpu-eiue-hvk">https://meet.google.com/cpu-eiue-hvk</a>
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gluster.org/mailman/listinfo/gluster-users">https://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
forumZFD
Entschieden für Frieden | Committed to Peace

Ilias Chasapakis
Referent IT | IT Consultant

Forum Ziviler Friedensdienst e.V. | Forum Civil Peace Service
Am Kölner Brett 8 | 50825 Köln | Germany

Tel 0221 91273243 | Fax 0221 91273299 | <a class="moz-txt-link-freetext" href="http://www.forumZFD.de">http://www.forumZFD.de</a>

Vorstand nach § 26 BGB, einzelvertretungsberechtigt|Executive Board:
Alexander Mauz, Sonja Wiekenberg-Mlalandle, Jens von Bargen
VR 17651 Amtsgericht Köln

Spenden|Donations: IBAN DE90 4306 0967 4103 7264 00   BIC GENODEM1GLS</pre>
  </body>
</html>