Может ли вес узла galera (pc.weight) быть нецелым числом?
В кластере 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 (или более) центрах обработки данных.
(Нет, я не знаю, работают ли дробные значения; я хочу сказать, что они вам никогда не понадобятся.)