在Keepalived集群中，其實并沒有嚴格意義上的主、備節點，雖然可以在Keepalived配置文件中設置“state”選項為“MASTER”狀態，但是這并不意味著此節點一直就是Master角色。控制節點角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有節點的角色，另一個能改變節點角色的是在vrrp_script模塊中設置的“weight”值，這兩個選項對應的都是一個整數值，其中“weight”值可以是個負整數，一個節點在集群中的角色就是通過這兩個值的大小決定的。
在一個一主多備的Keepalived集群中，“priority”值最大的將成為集群中的Master節點，而其他都是Backup節點。在Master節點發生故障后，Backup節點之間將進行“民主選舉”，通過對節點優先級值“priority”和““weight”的計算，選出新的Master節點接管集群服務。
在vrrp_script模塊中，如果不設置“weight”選項值，那么集群優先級的選擇將由Keepalived配置文件中的“priority”值決定，而在需要對集群中優先級進行靈活控制時，可以通過在vrrp_script模塊中設置“weight”值來實現。下面列舉一個實例來具體說明。
假定有A和B兩節點組成的Keepalived集群，在A節點keepalived.conf文件中，設置“priority”值為100，而在B節點keepalived.conf文件中，設置“priority”值為80，并且A、B兩個節點都使用了“vrrp_script”模塊來監控mysql服務，同時都設置“weight”值為10，那么將會發生如下情況。
在兩節點都啟動Keepalived服務后，正常情況是A節點將成為集群中的Master節點，而B自動成為Backup節點，此時將A節點的mysql服務關閉，通過查看日志發現，并沒有出現B節點接管A節點的日志，B節點仍然處于Backup狀態，而A節點依舊是Master狀態，在這種情況下整個HA集群將失去意義。
下面就分析一下產生這種情況的原因，這也就是Keepalived集群中主、備角色選舉策略的問題。下面總結了在Keepalived中使用vrrp_script模塊時整個集群角色的選舉算法，由于“weight”值可以是正數也可以是負數，因此，要分兩種情況進行說明。
1. “weight”值為正數時
在vrrp_script中指定的腳本如果檢測成功，那么Master節點的權值將是“weight值與”priority“值之和，如果腳本檢測失敗，那么Master節點的權值保持為“priority”值，因此切換策略為：
Master節點“vrrp_script”腳本檢測失敗時，如果Master節點“priority”值小于Backup節點“weight值與”priority“值之和，將發生主、備切換。
Master節點“vrrp_script”腳本檢測成功時，如果Master節點“weight”值與“priority”值之和大于Backup節點“weight”值與“priority”值之和，主節點依然為主節點，不發生切換。
2. “weight”值為負數時
在“vrrp_script”中指定的腳本如果檢測成功，那么Master節點的權值仍為“priority”值，當腳本檢測失敗時，Master節點的權值將是“priority“值與“weight”值之差，因此切換策略為：
Master節點“vrrp_script”腳本檢測失敗時，如果Master節點“priority”值與“weight”值之差小于Backup節點“priority”值，將發生主、備切換。
Master節點“vrrp_script”腳本檢測成功時，如果Master節點“priority”值大于Backup節點“priority”值時，主節點依然為主節點，不發生切換。
在熟悉了Keepalived主、備角色的選舉策略后，再來分析一下剛才實例，由于A、B兩個節點設置的“weight”值都為10，因此符合選舉策略的第一種，在A節點停止Mysql服務后，A節點的腳本檢測將失敗，此時A節點的權值將保持為A節點上設置的“priority”值，即為100，而B節點的權值將變為“weight”值與“priority”值之和，也就是90（10+80），這樣就出現了A節點權值仍然大于B節點權值的情況，因此不會發生主、備切換。
對于“weight”值的設置，有一個簡單的標準，即“weight”值的絕對值要大于Master和Backup節點“priority”值之差。對于上面A、B兩個節點的例子，只要設置“weight”值大于20即可保證集群正常運行和切換。由此可見，對于“weight值的設置，要非常謹慎，如果設置不好，將導致集群角色選舉失敗，使集群陷于癱瘓狀態。