2015-10-08 5 views
8

У нас есть конфигурация redis с двумя серверами redis. У нас также есть 3 сторожа для контроля двух экземпляров и инициирования сбоя при необходимости.Как сделать redis FLUSHALL без инициирования отказа от сбоев?

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

sentinel down-after-milliseconds OurMasterName 5000

и делает Redis-кли FlushAll на сервере занимает> 5000 миллисекунд, поэтому Часовые инициировать при сбое.

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

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

+0

Если вы находитесь на какой-то облачной платформе, вы можете просто создать новый экземпляр: либо иметь готовые изображения машин, либо с помощью некоторых инструментов devops –

+0

@LiviuCostea Я думаю, что это, вероятно, правильный вариант. Если вы можете ссылаться на что-то более подробно описывающее, как это могло бы работать, я был бы рад принять ваш ответ. – jakejgordon

+0

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

ответ

1

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

0

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

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

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

+0

Я думаю, проблема в том, что это не гарантирует согласованности. В этом случае нам, вероятно, лучше просто увеличить тайм-аут до> 5000 мс (что мы на самом деле сделали - и временно решает нашу проблему - но не совсем приемлемое решение). – jakejgordon