Я использую Keepalived для управления двумя экземплярами Redis в конфигурации главный / подчиненный. Я столкнулся с ситуацией, когда, если Keepalived прерывается на главном блоке (тот, который имеет более высокий приоритет), сервер резервного копирования принимает на себя роль главного. Однако, когда Keepalived перезапускается в поле с более высоким приоритетом, сервер резервного копирования немедленно передает статус Master в поле с более высоким приоритетом, что эффективно очищает кеш Redis.
Я попытался добавить директиву nopreempt в свой keepalived.conf, но это поведение все еще происходит.
Ниже приведен файл keepalived.conf с резервного сервера (с более низким приоритетом).
global_defs{
router_id redis_server_2
}
vrrp_script chk_redis {
script "killall -0 redis-server"
interval 5
}
vrrp_instance VI_1{
interface eth0
virtual_router_id 100
priority 200
advert_int 1
state BACKUP
nopreempt
track_script {
chk_redis
}
virtual_ipaddress {
10.19.105.229
}
notify_master "/usr/bin/sudo /var/lib/redis/redis.sh -m"
notify_backup "/usr/bin/sudo /var/lib/redis/redis.sh -s"
notify_fault "/usr/bin/sudo /var/lib/redis/redis.sh -k"
Хорошо, я решил это, подумав над этим несколько минут.
В VRRP_instance V1 в поле с более высоким приоритетом у меня было следующее:
state MASTER
Теперь nopreempt не соблюдается, потому что блок с более высоким приоритетом запускается как главный. Поле с более низким приоритетом увидело ведущее устройство с более высоким приоритетом и переключилось в режим ведомого. Изменив эту строку на
state BACKUP
блок с более высоким приоритетом запускается как ведомое устройство, видит ведущее устройство с более высоким приоритетом и остается ведомым. Готово и сделано.