1

In a MariaDB Galera cluster, you can assign a weight to each node, from 0-255. However, the documentation does not specify if this is allowed to be a decimal number (like 1.5). In other areas, it does specify when something must be an integer, leading me to believe it might allow decimals for this value.

Does the config allow non-integer numbers to be assigned to this weight? When I assign non-integer weights, no error or warning is generated. However, I haven't tested to see if the weights actually take into account any non-integer value.

For example, if I had 4 nodes, with 2.1, 2.2, 2.4, and 2.8 weights assigned, and then two nodes split off from the other two, would the weighted quorum calculation correctly find a quorum with the two nodes that had slightly higher weight totals? Or would it only calculate each node as if they had a weight of 2, resulting in a split brain?

I asked a question on math.se to find a general way to calculate unique weights that will never create a split-brain. However, the specific galera documentation says the highest weight is limited to 255, meaning the formula provided in the answer will only reasonably allow for 8 nodes (weights) that meet my criteria. But if decimal values are allowed, the formula could be generalized for a much larger number of nodes.

Example: With 9 servers, each node could be given a weight of 256, 257, 259, 263, 271, 287, 319, 383, 511 (which is (255+2^(n-1))). It is impossible to get any set of those numbers to add up to 50% of the whole group or any subset of the group, meaning no split brain possibility exists. Since the documentation only allows values up to 255, just multiply all of those by 0.1. But if the documentation only allows integers, the calculation is limited to 8 servers and a formula of (127+(2^(n-1)).

Stephen S
  • 180
  • 8
  • Why not just make them 21, 22, 23, and 24? – ceejayoz Apr 26 '19 at 15:18
  • @ceejayoz I updated the numbers in question, as I realized I already had a possibility of a split brain even with the non-integers (21+24 = 22+23). Which goes back to why I asked the question on math.se to generate a formula that would provably never allow any two subsets to have an equal sum with each other. – Stephen S Apr 26 '19 at 15:27
  • Note that the formula creates weights that increase in size quickly. In my case of 9 servers, the last 2 servers would outweigh the first 3 servers. But it avoid a split brain, which was more important in my mind than having a group with more servers. And I can easily start out with 3 servers, then add on up to a max of 9 without having to test all combinations to avoid a possible split brain scenario. And of course, if I ever needed to, I could just recompute weights for more than 9 and edit the configs. – Stephen S Apr 26 '19 at 15:53
  • I think you're doing so much overthinking to avoid the pretty rare condition of split brain that you're going to wind up making a *more* failure-prone setup here. – ceejayoz Apr 26 '19 at 16:21
  • Haha, you're probably right. That happens sometimes when I think too much about a specific problem. But I still would like to know if the field is integer or not. – Stephen S Apr 26 '19 at 19:34

1 Answers1

0

A quorum is declared if the nodes have more than 50% of the total weight. Equal to 50% is the same as less than 50%.

For 4 nodes, simply 1,1,1,2.

For an even number of nodes it is not mathematically possible to weight them such that half can go down and the other half add up to more than half the weight. Simple proof: Flip to the other half going down.

Weighting was not in the original release.

One reason for adding weighting is so that you won't be split-brained in all cases of half of an even number of nodes.

Another reason might be to avoid giving preference to a subset with a garbd: 1,2,2,2, where the garbd is weighted 1.

For 9, what is wrong with 1,1,1,1,1,1,1,1,1? Any 4 or fewer die, then the other 5 or more will have quorum.

Since each node talks to every other node, going beyond about 5 nodes is frowned on because of heavy network traffic.

The general wisdom is to plan for a "single failure", but not worry about the very small possibility of multiple failures.

Since datacenters can go down, you should ponder the weights based on how many servers are in each datacenter. That is, the combined weight for any one datacenter should be less than half the total.

And, of course, you should be in 3 (or more) datacenters.

(No, I don't know if fractional values work; my point is that you should never need them.)

Rick James
  • 2,463
  • 1
  • 6
  • 13