Keepalived Master and backup role election strategy

Original works, allow reprint, please be sure to use hyperlinks in the form of the original source of the article, author information and this statement. Otherwise, the legal liability will be investigated. http://ixdba.blog.51cto.com/2895551/1544858

In the keepalived cluster, there is no strict primary and standby node, although you can set the "state" option to "Master" in the keepalived configuration file, but this does not mean that this node is always the master role. The Control node role is the "priority" value in the keepalived configuration file, but it does not control the roles of all nodes, and the other that can change the node role is the "weight" value set in the Vrrp_script module, which corresponds to an integer value, where " The weight "value can be a negative integer, and the role of a node in the cluster is determined by the size of the two values.

In a master multi-keepalived cluster, the "priority" value will become the master node in the cluster, and the other is the backup node. After the master node fails, a "democratic election" will be conducted between the backup nodes, and a new master node is chosen to take over the cluster service by calculating the priority value of the node and the "weight".

In the Vrrp_script module, if you do not set the "weight" option value, the selection of the cluster priority is determined by the "priority" value in the Keepalived profile, and when you need to flexibly control the priorities in the cluster, you can pass the VRRP_ The "Weight" value is set in the script module. Here is an example to specify.

Assuming there is a keepalived cluster consisting of a and B nodes, in the A-node keepalived.conf file, set the "priority" value to 100, and in the B-node keepalived.conf file, set the "priority" value to 80, and a and b Two nodes use the "Vrrp_script" module to monitor the MySQL service while setting the "weight" value to 10, the following will occur.

After both nodes have started the keepalived service, it is normal that a node will become the master node in the cluster, and B will automatically become the backup node, when the MySQL service of the A node is closed, and the B node takes over the log of the a node by looking at the log discovery. The b node is still in the backup state, and the A node is still the master state, in which case the entire HA cluster loses its meaning.

The following analysis of the cause of this situation, which is the keepalived cluster in the main, the role of the election strategy of the problem. The following summarizes the election algorithm for the entire cluster role when using the Vrrp_script module in Keepalived, as the "weight" value can be positive or negative, so there are two situations to describe.

1. when the "weight" value is a positive number

If the script specified in Vrrp_script is successful, then the master node's weight will be the sum of the weight value and the priority value, and if the script fails, the master node's weight remains the "priority" value, so the switch policy is:

Master node "Vrrp_script" script fails to detect if the master node "priority" value is less than the sum of the backup node "weight" value and the "value", the primary, standby switchover will occur.

Master node "Vrrp_script" script detection succeeds, if the master node "weight" value and "priority" value is greater than the backup node "weight" value and "priority" value of the sum, the master node remains the primary node, No switchover occurs.

2. when the "weight" value is negative

If the script specified in "Vrrp_script" is successful, the master node's weight is still the "priority" value, and when script detection fails, the master node's weight will be the difference between the "priority" value and the "weight" value, so the switching policy is:

Master node "vrrp_script" script detection fails, if the difference between the master node "priority" value and "weight" value is less than the value of the backup node, the primary, standby switchover occurs.

When the master node "vrrp_script" script detects success, if the master node "priority" value is greater than the backup node "key" value, the master node remains the primary node, and no switchover occurs.

After familiar with the keepalived master, the role of the election strategy, and then to analyze the example, because a, b two nodes set the "weight" value is 10, so according to the first of the election strategy, after a node stop MySQL service, a-node script detection will fail, At this point the weight of a node will remain the "priority" value set on the a node, that is, 100, and the weight of the B node will be changed to "weight" value and "priority" value of the sum, that is, 90 (10+80), so that a node weight is still greater than the B-node weight of the case, Therefore, master and standby switching will not occur.

For the setting of the "weight" value, there is a simple criterion that the absolute value of the "weight" is greater than the difference between the "priority" value of the master and the backup node. For an example of a and B two nodes above, it is possible to set the "weight" value above 20 to ensure that the cluster runs and switches properly. Thus, for the "Weight value setting, be very cautious, if not set up, will cause the cluster role election failure, the cluster is paralyzed."

This article is from the "Technical Achievement Dream" blog, please be sure to keep this source http://ixdba.blog.51cto.com/2895551/1544858

Keepalived Master and backup role election strategy