Резервное копирование набора с отслеживанием состояния в Kubernetes

Я пытаюсь придумать стратегию резервного копирования данных в моем кэше apache ignite, размещенном в виде набора с отслеживанием состояния в облаке Google Kubernetes. В моем развертывании ignite используется нативная персистентность ignite и выполняется кластер ignite из 3 узлов, резервное копирование которого осуществляется с помощью томов персистентности в Kubernetes. Я использую binaryConfiguration для хранения двоичных объектов в кеше.

Я ищу надежный способ сделать резервную копию моих данных зажигания и восстановить их.

До сих пор я пытался создавать резервные копии только файлов сохранения, а затем восстанавливать их обратно. Он еще не работал надежно. Проблема, с которой я столкнулся, заключается в том, что после восстановления данные кеша, которые не являются двоичными объектами, восстанавливаются правильно, например. строки или числа. Я могу получить доступ к числовым или строковым данным. Но бинарные объекты недоступны. Кажется, бинарные объекты восстановлены, но я не могу их получить.

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

Может ли кто-нибудь предложить надежный способ резервного копирования и восстановления данных собственного сохранения?


kubernetes persistence backup ignite statefulset
person Chinmoymohanty85    schedule 30.01.2019    source источник
comment
Как вы выполняете резервное копирование? Выключаете ли вы кластер перед тем, как сделать копию?   -  person Stephen Darlington    schedule 31.01.2019
comment
@StephenDarlington Я не закрываю кластер перед копированием. Все примитивные данные в резервной копии доступны после восстановления, но только двоичные данные вызывают проблему.   -  person Chinmoymohanty85    schedule 01.02.2019
comment
Но если кластер работает, ваша резервная копия может быть несогласованной. Вам нужно, чтобы файлы данных и WAL со всех узлов были в одно и то же время. У вас возникает та же проблема, если вы выполняете резервное копирование, когда кластер не работает?   -  person Stephen Darlington    schedule 01.02.2019

Ответы (2)


arrow_upward
0
arrow_downward

Вы должны либо сделать резервную копию каталога ${ignite.work.dir}/marshaller, либо вызвать ignite.binary().type(KeyOrValue.class) для каждого типа, который у вас есть в кеше, чтобы запустить двоичный маршаллер.

person alamar    schedule 31.01.2019
comment
Привет @аламар. Я думаю, это то, что может сработать. Похоже, бинарный маршаллер почему-то не срабатывает после восстановления. Я попробую это как можно скорее. - person Chinmoymohanty85; 31.01.2019
comment
к сожалению, это не работает. Единственный способ заставить его работать - добавить/обновить двоичный объект того же типа в кеше. Есть ли рекомендуемый способ резервного копирования кешей персистентности, чтобы восстановление было надежным. - person Chinmoymohanty85; 01.02.2019
comment
@ Chinmoymohanty85, как я уже сказал, резервное копирование каталога marshaller должно быть надежным. Это или использование снимков GridGain. - person alamar; 01.02.2019
comment
Кажется, теперь это работает. как-то я пропустил несколько шагов при восстановлении. Восстановление папки marshaller фактически решает проблему. Спасибо. - person Chinmoymohanty85; 02.02.2019

arrow_upward
0
arrow_downward

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

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

person Rico    schedule 30.01.2019