<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Я думаю, что такую ситуацию следует обходить именно шатдауном
      обслуживающего софта в случае выпадания ноды из кластера.</p>
    <p>Если речь идет о том proprietary софте, то я его просто
      пейсмейкером уложу на failed active node и сделаю новую active -
      перенесу Virtual IP и запущу сервисный инстанс.</p>
    <p>Полагаясь всё же на внутренние механизмы синхронизации файловой
      системы, когда всё наладится.</p>
    <p>И да - очевидно, что именно три ноды.<br>
    </p>
    <div class="moz-cite-prefix">On 15.11.2021 17:48, Vladimir Sharun
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1636990591.721006000.1fve6ozo@frv53.fwdcdn.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <span style="display:block;" class="xfm_34544121">
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">Привет,</span><br>
        </div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1"><br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">Во время отсутствия кворума нода
            по-правильному не работает вообще (так например поступает
            Эластик), чтобы не допустить split brain - вот такой
            conflict resolution. Read only в ситуации split brain
            приведет к неверным принятиям решений. Ну например ты
            смотришь остаток на счету в одной ноде и это Х, а в другой
            ноде там уже больше/меньше. Т.е. при read only ситуация всё
            равно плохая.<br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1"><br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">Я рассматривал подобное решение для банкинга 
            (бабки, платежи) в ситуации нескольких датацентров "в
            кластере", оказалось что файловые системы мягко говоря не
            подходят. </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">Именно потому что аппликейшн не в курсе, что
            не может писать например или, что еще хуже: прочитал,
            попытался записать, получил "рид онли", взял паузу, ФС
            разблокировалась+просинхронизировалась, а ты сделал запись в
            уже ДРУГОЙ файл (классический race).<br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1"><br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">Вот такая вот защита от split brain она очень
            виртуальная. Софт должен понимать что что-то может не
            работать и иметь механизмы conflict resolution'а<br
              data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1"><br data-mce-bogus="1">
          </span></div>
        <div><span
            style="font-size:12pt;line-height:14pt;font-family:Arial;"
            class="xfmc1">PS: совсем эдж кейс шарить таким образом файлы
            embedded database'ов типа bdb/sqlite<br data-mce-bogus="1">
          </span></div>
        <div><br>
        </div>
        <div><i><span style="font-size:10pt;line-height:12pt;"><span
                style="font-family:Arial;">15 листопада 2021, 17:04:00,
                від "Mykola Ulianytskyi" <</span><a
                href="mailto:lystor@gmail.com" target="_blank"
                moz-do-not-send="true"><span style="font-family:Arial;">lystor@gmail.com</span></a><span
                style="font-family:Arial;">>:
              </span></span></i></div>
        <div><br>
        </div>
        <blockquote style="border-left:1px solid #cccccc;margin:0px 0px
          0px 0.8ex;padding-left:1ex;">
          <pre style="margin:5px 0;">> У тебя очевидная проблема будет при split brain, очевидная необходимость в conflict resolution. Файловая система не даёт таких возможностей.

Даёт. С тремя нодами всё будет ок.

Client quorum:
This is a feature implemented in Automatic File Replication (AFR here
on) module, to prevent split-brains in the I/O path for
replicate/distributed-replicate volumes.
By default, if the client-quorum is not met for a particular replica
subvol, it becomes read-only.

<a href="https://docs.gluster.org/en/v3/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/" target="_blank" rel="noreferrer noopener" moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.gluster.org/en/v3/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/</a>

</pre>
        </blockquote>
      </span>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison</pre>
  </body>
</html>