Резервный мастер Redis после отработки отказа

Мы пытаемся обновить наш кластер redis/sentinel с 2.8 до 3.2. Обновление будет происходить при интенсивном трафике. Для нас неприемлемы простои.

Наша установка имеет 6 redis/sentinels (3 сайта, 2 сервера на каждом сайте, на каждом сервере работает один экземпляр redis и sentinel). Очевидно, у нас есть 1 мастер и 5 рабов. Мы планируем обновлять наш сервер один за другим, оставляя наш главный сервер последним для обновления.

К тому времени, когда мы будем готовы обновить наш главный сервер, все подчиненные устройства будут работать на 3.2, и эти подчиненные устройства смогут синхронизироваться с главным устройством, работающим на 2.8.
Как только мы остановим наш главный сервер (2.8) или вручную запросим отработку сервер (3.2) станет главным.

Мы хотим оставить наш старый мастер (2.8) на некоторое время, чтобы иметь возможность откатиться в случае, если мы обнаружим какие-либо проблемы с нашей новой настройкой. К сожалению, старое подчиненное устройство redis (2.8) не может синхронизироваться с новым ведущим устройством (3.2) из-за другого формата RDB. Мы можем остановить наш старый сервер, ведомый (2.8), но мы также хотим иметь возможность вернуться к 2.8 в качестве главного на случай, если мы обнаружим проблему с 3.2. Поскольку 2.8 не может синхронизироваться с 3.2, у него не будет никаких данных, поэтому часовой не может выбрать его в качестве нового мастера.

Вопрос как откатиться с 3.2 на 2.8 без потери данных?


person pcapcanari    schedule 26.10.2016    source источник
comment
Нам удалось обновить наш кластер после большого количества тестов на промежуточной среде. В итоге откатиться после миграции не пришлось, т.к. новый кластер стабильно работал 2 недели. Мы подготовили процедуру для отката. Процедура использует файл redis AOF. Файл AOF был взят с обновленного узла и перенесен на старый. Это было автоматизировано, чтобы свести к минимуму время простоя и количество потерянных запросов.   -  person pcapcanari    schedule 20.07.2017


Ответы (1)


Я бы не рекомендовал использовать узел 2.8 в качестве запасного варианта. Как вы упомянули, вы не можете синхронизировать 3.2 -> 2.8, поэтому возврат к 2.8 будет означать, что все записи, сделанные в 3.2, будут потеряны.

Я бы порекомендовал настроить промежуточную среду, в которой работает 3.2, и выполнить там все необходимые тесты. Как только вы почувствуете относительную уверенность в этом, сделайте резервную копию своей производственной базы данных и выполните процесс миграции.

person davissp14    schedule 02.12.2016
comment
Спасибо за предложение. - person pcapcanari; 20.07.2017