在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值的設置，要非常謹慎，如果設置不好，將導致集羣角色選舉失敗，使集羣陷於癱瘓狀態。