Master and backup role election policies in keepalived

In a keepalived cluster, there are no master and slave nodes strictly. Although you can set the "State" option to "master" in the keepalived configuration file, however, this does not mean that this node has always been the master role. The "Priority" value in the keepalived configuration file controls the node role, but it does not control the roles of all nodes, the other option that can change the node role is the "weight" value set in the vrrp_script module. The two options correspond to an integer. The "weight" value can be a negative integer, the role of a node in the cluster is determined by the size of the two values.

In a keepalived cluster with one master node and multiple slave nodes, the master node with the highest "Priority" value will be the master node in the cluster, while the other nodes are backup nodes. After the master node fails, the backup nodes are "democratically elected". By calculating the node priority values "Priority" and "weight, select a new master node to take over the cluster service.

 

In the vrrp_script module, if the "weight" option value is not set, the cluster priority is determined by the "Priority" value in the keepalived configuration file, to flexibly control the priority of a cluster, you can set the "weight" value in the vrrp_script module. The following is an example.

 

Assume that a keepalived cluster consists of two nodes, namely, keepalived. in the conf file, set the value of "Priority" to 100, while in the B node keepalived. in the conf file, set "Priority" to 80, and both nodes A and B use the "vrrp_script" module to monitor the MySQL service, and set "weight" to 10, the following will happen.

 

After the keepalived service is started at both nodes, it is normal that node A becomes the master node in the cluster, and Node B automatically becomes the backup node. At this time, the MySQL service of node A is disabled, by checking the logs, it is found that no logs are generated for Node B to take over node A. Node B is still in the backup state, while node A is still in the master state, in this case, the entire HA cluster will be meaningless.

 

The following analyzes the cause of this situation, which is the primary and standby role election policy in the keepalived cluster. The following describes the Election Algorithm of the entire cluster role when the vrrp_script module is used in keepalived. Because the "weight" value can be positive or negative, we need to describe it in two cases.

 

1. When the "weight" value is positive

If the script specified in vrrp_script is detected successfully, the weight of the master node is the sum of the "Weight Value and" Priority "value. If the script fails to be detected, the master node's weight is kept as "Priority", so the switching policy is:

When the "vrrp_script" script of the master node fails to be detected, if the "Priority" value of the master node is less than the sum of the "weight" value and "Priority" value of the backup node, the master and slave switches.

When the "vrrp_script" script of the master node is detected successfully, if the sum of the "weight" value and "Priority" value of the master node is greater than the sum of the "weight" value and "Priority" value of the backup node, the master node is still the master node, and no switchover occurs.

 

2. When the "weight" value is negative

If the script specified in "vrrp_script" is successfully detected, the master node's weight is still "priority". When the script fails to be detected, the weight of the master node is the difference between the "Priority" value and the "weight" value. Therefore, the switching policy is as follows:

When the "vrrp_script" script of the master node fails to detect, if the difference between the "Priority" value of the master node and the "weight" value is less than the "Priority" value of the backup node, the master and slave switches.

When the "vrrp_script" script of the master node is detected successfully, if the "Priority" value of the master node is greater than the "Priority" value of the backup node, the master node is still the master node and does not switch over.

 

After familiarizing yourself with the keepalived primary and standby role election policies, let's analyze the instance. Because the values of "weight" set for nodes A and B are 10, therefore, if the MySQL service is stopped on node A, script detection on node A fails, at this time, the weight of node A will remain the "Priority" value set on node A, that is, 100, the weight of Node B is changed to the sum of the "weight" value and "Priority" value, that is, 90 (10 + 80 ), in this case, the weight of node A is still greater than the weight of Node B, so no Master/Slave switchover occurs.

 

There is a simple standard for setting the "weight" value, that is, the absolute value of the "weight" value must be greater than the value difference between the "Priority" of the master and backup nodes. For the example of the above two nodes A and B, you only need to set the "weight" value to be greater than 20 to ensure the normal operation and switch of the cluster. We can see that we should be very cautious about setting the weight value. If it is not set properly, the cluster role election will fail and the cluster will be paralyzed.

Master and backup role election policies in keepalived