Redis — избегайте потери данных с помощью кластера (используя протокол сплетен)

Мы хотели бы развернуть приложение Airflow на Kubernetes в 2 центрах обработки данных.

Контейнер Airflow Scheduled генерирует DAG каждые 1, 5 и 10 минут. Эти DAG — это задачи, которые будут назначены контейнеру Airflow Worker.

В процессе назначения задач воркеру Airflow, Airflow Schedular отправляет данные о задачах как в MariaDb (может рассматриваться как источник правды), так и в Redis.

В MariaDB задача может иметь один из статусов 'queued', 'running', 'success', 'failed'. Когда задачи находятся в Redis, они будут в состоянии «queued».

MariaDB поддерживает то же самое, когда получает задачи от Airflow Scheduler. когда Redis передает конкретную задачу в очереди рабочему контейнеру, MariaDB изменяет статус этой конкретной задачи на «выполняется», и если она завершает процесс выполнения, статус задачи в MariaDB будет изменен на «Успех».

Настоящая проблема:

Когда Redis дает сбой, у нас есть задачи в очереди в MariaDB, но мы теряем данные в Redis. Когда k8s запускает новый сервер Redis, он теряет предыдущие задачи — здесь возникает ПОТЕРЯ ДАННЫХ.

Какое может быть решение для этого.

Можем ли мы использовать Redis Clustering - Gossip protocol, чтобы избежать потери данных:

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


person sireesha rk    schedule 29.08.2018    source источник
comment
Было бы хорошо, если бы вы могли предложить какие-либо решения уровня предприятия, чтобы полагаться на него для нашего сценария.   -  person sireesha rk    schedule 30.08.2018
comment
Может кто-нибудь дать предложения по использованию Hazelcast вместо Redis. Это решит мою проблему или создаст новую?   -  person sireesha rk    schedule 31.08.2018
comment
Вы действительно определили, что Redis необходим.   -  person Rick James    schedule 25.09.2018
comment
@RickJames James - Проект все еще находится на стадии исследования, Redis был предложен ранее, но у него есть некоторые недостатки при интеграции с Airflow.   -  person sireesha rk    schedule 16.10.2018


Ответы (1)


Кластеризация Redis могла бы помочь в этом, но ее сложно настроить, и она не является полной заменой резервным копиям.

В вашем случае, на мой взгляд, гораздо более простым решением было бы включить процедуру восстановления при запуске вашего модуля Redis. У вас нет необратимой потери данных, поскольку у вас есть источник правды MariaDB, поэтому вы можете добавить контейнер инициализации, который запускает скрипт для восстановления данных redis из MariaDB.

Другим подходом, который значительно ограничил бы вашу проблему, было бы использование постоянного тома для хранения данных Redis, поскольку Redis может делать снимки своего состояния в памяти через регулярные промежутки времени. При использовании StatefulSet вместо Deployment для управления вашими узлами Redis модули будут повторно подключать хранилище при перезапуске/перепланировании, и вы не испытаете потери данных (или, самое большее, крошечное окно с момента последнего снимка)

person Radek 'Goblin' Pieczonka    schedule 29.08.2018
comment
У нас есть план резервного копирования, включающий процедуру восстановления при запуске моего модуля Redis. Расписание может назначать задачи Redis, поскольку он уже подключен к MariaDB. Но это может быть сложный кусок! А пока я хотел бы узнать больше информации о кластеризации Redis для выполнения POC. Не могли бы вы предложить некоторую документацию по настройке кластера и тому, как вручную запускать узлы без простоев в кластере (если это возможно). Мы не думали о постоянных томах, но нас не очень интересует хранение данных на внешних томах. - person sireesha rk; 29.08.2018
comment
Можете ли вы предоставить дополнительную информацию о включении процедуры восстановления в запуск моего модуля Redis. Будет ли хорошо включить процедуру восстановления в расписание Airflow (вы можете считать это компонентом Producer) или при запуске модуля Redis? Не могли бы вы подробно рассказать мне об этом. - person sireesha rk; 30.08.2018