Восстановление Cassandra Priam Backup с помощью sstableloader

Ранее я писал о настройке Cassandra и Priam для резервного копирования и управления кластером. Однако приведенный мною пример для восстановления из резервной копии не применим в каждой ситуации — например, он может не работать на совершенно отдельном кластере. Или в случае частичного восстановления только одной таблицы, а не всей базы данных.

В таких случаях вы можете выполнить восстановление с помощью утилиты sstableloader . Он имеет простой синтаксис:

Если вы посмотрите на сгенерированную Priam резервную копию, похоже, что вы можете просто скопировать файлы (например, через s3 aws cp на AWS) для конкретных таблиц и импортировать их с помощью sstableloader. Однако есть одна загвоздка. Чтобы сэкономить место, Priam использует Snappy для сжатия всех файлов. Поэтому, если вы попытаетесь передать их какой-либо утилите Cassandra, она будет жаловаться, что они повреждены.

Поэтому вы должны распаковать их перед использованием sstableloader или чего-либо еще. Но как? Что ж, Priam предлагает услугу для этого — вы вызываете его, передавая абсолютный путь к сжатому файлу и абсолютный путь к месту, где должен быть размещен несжатый файл, и он выполняет простую работу по потоковой передаче оригинала через декомпрессор. Для распаковки всей резервной копии я написал скрипт на python. Он предполагает определенную структуру, но вы можете параметризовать его, чтобы сделать его более гибким. Вот код (извините за неидиоматический Python, я использую его только для простых сценариев):

Теперь у вас есть распакованные резервные файлы, которые вы можете восстановить с помощью sstableloader. Это может занять некоторое время, если у вас много данных, и вы не должны запускать восстановление в то же время, когда выполняется резервное копирование моментального снимка, так как это может дать сбой (было предупреждено документацией).

И тогда, если вам повезет, все пройдет. К сожалению, бывают случаи, когда это не так. Этот инструмент далек от совершенства, поэтому, например, если вы удалили столбец, восстановление старого sstable не удастся, так как он попытается вставить его в отсутствующий столбец. Это звучит как большая проблема для реальных производственных систем, и об этом сообщалось, но еще не решено . Иногда таблица может просто не восстановиться по неизвестным причинам (сбой во время потоковой передачи, предполагаемые поврежденные данные). В этих случаях вы можете захотеть вывести sstables в JSON, используя sstabledump, а затем преобразовать JSON в CQL, чтобы вставить его. Конечно, нет никакого инструмента для этого, поэтому вот один, написанный на Java . Он не идеален и не поддерживает пользовательские типы, наборы и карты. Обратите внимание, что это, вероятно, не очень хорошая идея для больших таблиц, только для небольших.

Как общее замечание в заключение, очень важно иметь резервные копии, но гораздо важнее иметь возможность восстановить их. Резервное копирование бесполезно, если у вас нет процедуры восстановления. И просто наличие доступных инструментов (например, Priam) не означает, что вы можете выполнить процедуру восстановления, готовую к выполнению. Вы должны выполнять тестовое восстановление активных промежуточных данных, а также полное восстановление в пустом, недавно сформированном кластере, поскольку существуют разные сценарии восстановления.