Автоматическая конфигурация аварийного переключения Predis + Elasticache

Я использую Predis для кластера Elasticache на AWS, который имеет мастер записи и две реплики чтения. Predis настроен для репликации master/slave примерно следующим образом.

self::$client = new Predis\Client(
[
    'tcp://' . REDIS_MASTER  . '?alias=master',
    'tcp://' . REDIS_SLAVE01 . '?alias=slave-01',
    'tcp://' . REDIS_SLAVE02 . '?alias=slave-02'
],
['replication' => true]
);

Я нахожусь в процессе настройки автоматического аварийного восстановления. Elasticache поддерживает восстановление после сбоя главного узла, продвигая ведомое устройство для чтения и обновляя запись DNS для имени хоста главного узла. В случае сбоя Predis не следует мудрить с приведенной выше конфигурацией, поскольку имя хоста мастера не изменится.

Однако с приведенной выше конфигурацией у меня возникла бы проблема. Я бы фактически перешел от кластера с тремя узлами к кластеру с двумя узлами, пока не вмешался человек (или не был написан какой-то героический код).

Чтобы прояснить мою точку зрения.. Перед неудачей..

REDIS_MASTER -> node1
REDIS_SLAVE01 -> node2
REDIS_SLAVE01 -> node3

После сбоя... (узел 1 выходит из строя, а узел 2 повышается)

REDIS_MASTER -> node2
REDIS_SLAVE01 -> node2
REDIS_SLAVE01 -> node3

Это нормально в течение ограниченного времени, но в идеале я хотел бы, чтобы это решилось само собой.

Когда восстановление будет завершено, elasticache восстановит node1 как реплику чтения. Я хотел бы, чтобы он начал работать как реплика для чтения, как только он станет доступен.

Я думал, что смогу обойти это, настроив Predis так.

self::$client = new Predis\Client(
[
    'tcp://' . REDIS_MASTER  . '?alias=master',
    'tcp://' . REDIS_SLAVE01 . '?alias=slave-01',
    'tcp://' . REDIS_SLAVE02 . '?alias=slave-02',
    'tcp://' . REDIS_SLAVE03 . '?alias=slave-03'
],
['replication' => true]
);

... где REDIS_SLAVE03 указывает на тот же базовый экземпляр, что и REDIS_MASTER, но с именем хоста, которое не изменится в случае сбоя. По сути, все узлы всегда ведут себя как ведомые для чтения, а «указатель» на ведущий для записи смещается без ведома Предиса.

Итак, несколько вопросов...

1) как ведет себя Предис, когда раб перестает отвечать на запросы? Будет ли он игнорировать эту конфигурацию и маршрутизировать чтение к другим реагирующим ведомым устройствам?

2) будет ли главный экземпляр Redis удваивать количество операций чтения? (предположительно ответ да)

3) Есть ли недостатки в этом подходе, которые я упускаю?

4) Лучшая идея?

Любые советы приветствуются.


php redis predis
person rshepherd    schedule 15.07.2015    source источник
comment
Вы уверены, что у вас останется 2 узла после автоматического перехода на другой ресурс? Потому что я знаю, что новая реплика чтения будет создана вместо той, которая была назначена главной. И если вы используете URL-адреса (а не IP-адреса), все будет обрабатываться AWS на уровне DNS. Вы можете проверить это: aws.amazon.com/blogs/aws/ elasticache-redis-multi-az   -  person Liviu Costea    schedule 15.07.2015
comment
Спасибо за это, я посмотрю на это.   -  person rshepherd    schedule 15.07.2015
comment
Ливиу, ты прав. Если вы ссылаетесь на реплики чтения по их «конечным точкам чтения», все это работает так, как вы описываете.   -  person rshepherd    schedule 16.07.2015

Ответы (1)


arrow_upward
0
arrow_downward

Вся эта идея ошибочна. Ссылка на реплики по их конечным точкам чтения решает проблемы, поскольку aws также обновит DNS для этих имен в процессе восстановления.

person rshepherd    schedule 16.07.2015