HAProxy для Redis Sentinel: требуется РЕЗЕРВНОЕ КОПИРОВАНИЕ, а не DOWN

Я настроил службу HAProxy для моей установки Redis Cluster (3 узла с Redis Sentinel, управляющими главным делегированием), и он работает хорошо: клиенты перенаправляются только на главный узел и всякий раз, когда подчиненный узел становится главным, HAProxy внезапно меняет активного члена на бэкэнд.

Чтобы быть внимательным, подчиненные узлы показаны как «ВНИЗ» (красный цвет) в отчете статистики HAProxy (тайм-аут Layer7: на шаге 5 tcp-check (ожидаемая строка 'роль: мастер')) . Есть ли способ показать их как «резервное копирование UP» (синий цвет) , что является правильным определением?

Это потому, что красные узлы кажутся проблемой, но это не так, как подчиненные участники ВЕРСИИ, но они просто подчиненные, поэтому они не активны. Я думаю, что это правильное определение состояния «резервное копирование UP» в HAProxy.

Это конфигурация HAProxy:

frontend Redis
    bind            192.168.70.90:6379 name 192.168.70.90:6379   
    mode            tcp
    log         global
    timeout client      30000
    default_backend     Redis_tcp_ipvANY

backend Redis_tcp_ipvANY
    mode            tcp
    timeout connect     30000
    timeout server      30000
    retries         3
    option tcp-check
    tcp-check connect
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    tcp-check send info\ replication\r\n
    tcp-check expect string role:master
    tcp-check send QUIT\r\n
    tcp-check expect string +OK
    server          redis1 192.168.70.91:6379 check inter 1000  maxconn 1024 
    server          redis2 192.168.70.92:6379 check inter 1000  maxconn 1024 
    server          redis3 192.168.70.93:6379 check inter 1000  maxconn 1024 

Вы хоть представляете, как можно делать то, что я хочу?

Спасибо!

1
задан 2 November 2017 в 00:01
1 ответ

Это возможно, но поскольку у вас более двух узлов, ЭТО НЕ ПРЕВЫШАЕТ ПОВРЕЖДЕНИЕ . Но поскольку вы спросили:

backend Redis_tcp_ipvANY
    mode            tcp
    timeout connect     30000
    timeout server      30000
    retries         3
    option tcp-check
    tcp-check connect
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    tcp-check send QUIT\r\n
    tcp-check expect string +OK
    server          redis1 192.168.70.91:6379        inter 1000  maxconn 1024 check
    server          redis2 192.168.70.92:6379 backup inter 1000  maxconn 1024 check
    server          redis3 192.168.70.93:6379 backup inter 1000  maxconn 1024 check

Состояние haproxy BACKUP просто означает, что сервер не будет рассматриваться для балансировки нагрузки, пока любой нормальный сервер находится в состоянии UP . Думаю, ваша нынешняя установка лучше.

1
ответ дан 3 December 2019 в 23:23

Теги

Похожие вопросы