В кластере MariaDB Galera вы можете назначить вес каждому узлу от 0 до 255. Однако в документации не указывается, может ли это быть десятичное число (например, 1.5). В других областях он действительно указывает, когда что-то должно быть целым числом, что наводит меня на мысль, что это может допускать десятичные дроби для этого значения.
Позволяет ли конфигурация назначать этому весу нецелые числа? Когда я назначаю нецелочисленные веса, никаких ошибок или предупреждений не возникает. Однако я не проверял, учитывают ли веса какие-либо нецелочисленные значения.
Например, если бы у меня было 4 узла с назначенными весами 2,1, 2,2, 2,4 и 2,8, а затем два узла отделились от двух других, правильно ли вычисление взвешенного кворума обнаружило бы кворум с двумя узлами, которые имели немного больший вес итоги? Или он будет вычислять каждый узел только так, как если бы он имел вес 2, что привело бы к разделению мозга?
Я спросил вопрос на math.se найти общий способ вычисления уникальных весов, который никогда не приведет к разделению мозга. Однако в специальной документации Galera указано, что максимальный вес ограничен 255, что означает формулу, приведенную в ответ будет разумно разрешать только 8 узлов (весов), которые соответствуют моим критериям. Но если разрешены десятичные значения, формула может быть обобщена для гораздо большего числа узлов.
Пример: с 9 серверами каждому узлу можно присвоить вес 256, 257, 259, 263, 271, 287, 319, 383, 511 (что составляет (255 + 2 ^ (n-1))). Невозможно получить какой-либо набор этих чисел, чтобы добавить до 50% всей группы или любого подмножества группы, что означает, что не существует возможности разделения мозга. Поскольку в документации разрешены значения только до 255, просто умножьте их на 0,1. Но если в документации разрешены только целые числа, расчет ограничен 8 серверами и формулой (127+ (2 ^ (n-1)).
Кворум объявляется, если узлы имеют больше, чем 50% от общего веса. Равно 50% означает меньше 50%.
Для 4 узлов просто 1,1,1,2.
Для четного числа узлов математически невозможно взвесить их так, чтобы половина могла упасть, а другая половина в сумме составила больше, чем половина веса. Простое доказательство: переверните другую половину вниз.
В исходной версии утяжеления не было.
Одна из причин для добавления весов состоит в том, чтобы у вас не было раздвоения мозга во всех случаях, когда половина четного числа узлов.
Другая причина может заключаться в том, чтобы не отдавать предпочтение подмножеству с garbd: 1,2,2,2, где garbd имеет вес 1.
Для 9, что не так с 1,1,1,1,1,1,1,1,1? Если умирает 4 или меньше кубиков, то кворум будет у остальных 5 или более.
Поскольку каждый узел общается со всеми остальными узлами, выход за пределы 5 узлов не одобряется из-за большого сетевого трафика.
Общая мудрость состоит в том, чтобы спланировать «единичный отказ», но не беспокоиться о очень небольшой возможности множественных отказов.
Поскольку центры обработки данных жестяная банка вниз, вам следует подумать о весах, основанных на том, сколько серверов находится в каждом центре обработки данных. То есть общий вес для любого центра обработки данных должен быть меньше, чем половина от общей суммы.
И, конечно же, вы должны быть в 3 (или более) центрах обработки данных.
(Нет, я не знаю, работают ли дробные значения; я хочу сказать, что они вам никогда не понадобятся.)