Как выполнить redis FLUSHALL, не инициируя аварийное переключение дозорного?

У нас есть конфигурация Redis с двумя серверами Redis. У нас также есть 3 стража для мониторинга двух экземпляров и инициирования аварийного переключения при необходимости.

В настоящее время у нас есть процесс, в котором нам периодически приходится выполнять FLUSHALL на сервере Redis. Это блокирующая операция, которая занимает больше времени, чем время, отведенное нами для тайм-аута часовых. Другими словами, у нас есть наша конфигурация дозорного с:

sentinel down-after-milliseconds OurMasterName 5000

и выполнение redis-cli FLUSHALL на сервере занимает> 5000 миллисекунд, поэтому дозорные инициируют отработку отказа.

Мы признаем, что делать FLUSHALL не очень хорошо, и мы также знаем, что можем увеличить время ожидания после миллисекунд до, но для целей этого вопроса предположим, что ни один из этих вариантов не подходит.

Возникает вопрос: как мы можем выполнить FLUSHALL (или аналогичную операцию) БЕЗ того, чтобы наши часовые инициировали отработку отказа из-за блокировки FLUSHALL более чем на 5000 миллисекунд? Кто-нибудь сталкивался и решал эту проблему?


redis redis-sentinel sentinel
person jakejgordon    schedule 08.10.2015    source источник
comment
если вы находитесь на какой-то облачной платформе, вы можете просто создать новый экземпляр: либо иметь готовые образы машин, либо использовать некоторые инструменты devops   -  person Liviu Costea    schedule 09.10.2015
comment
@LiviuCostea Думаю, это правильный вариант. Если вы можете сослаться на что-то, что более подробно описывает, как это может работать, я был бы рад принять ваш ответ.   -  person jakejgordon    schedule 22.10.2015
comment
Если вы используете что-то вроде AWS или Azure, у вас есть API для создания нового кластера Redis. Запустите его, загрузите данные и, когда все будет готово, просто измените DNS, опять же с вызовом API, чтобы все это могло быть обработано какой-то частью вашего приложения. Но в помещении все может стать более сложным, потому что потребуется некоторая автоматизация с помощью ansible/chef/puppet.   -  person Liviu Costea    schedule 23.10.2015
comment
@LiviuCostea Правда - все еще законный ответ. Если вы поместите это в форму ответа, я могу принять это.   -  person jakejgordon    schedule 23.10.2015

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете просто создать новые экземпляры: если вы используете что-то вроде AWS или Azure, у вас есть API для создания нового кластера Redis. Запустите его, загрузите данные и, когда все будет готово, просто измените DNS, опять же с вызовом API, чтобы все это могло быть обработано какой-то частью вашего приложения. Но в помещении все может стать более сложным, потому что потребуется некоторая автоматизация с помощью ansible/chef/puppet.

person Liviu Costea    schedule 23.10.2015

arrow_upward
0
arrow_downward

Следующий лучший вариант, который вам сейчас нужен, — это удалять ключи партиями, чтобы сократить объем работы до одного раза. Вы можете создать список, если у вас его нет, используя scan Затем удалите любой размер пакета, который вам подходит.

Изменить: поскольку вы не заинтересованы в сохранении данных, отключите сохранение, удалите файл RDB, а затем просто перезапустите экземпляр. Таким образом, вам не нужно обновлять Sentinel, как если бы вы брали новые хосты.

Из любопытства, если вы просто собираетесь все время сбрасывать данные и не заботитесь о данных, поскольку вы будете их стирать, зачем возиться с часовым?

person The Real Bill    schedule 09.10.2015
comment
Я думаю, что проблема здесь в том, что это не гарантирует согласованности. В этом случае нам, вероятно, лучше просто увеличить время ожидания до › 5000 мс (что мы действительно сделали — и временно решили нашу проблему — но не совсем приемлемое решение). - person jakejgordon; 22.10.2015