Riak Cluster Backup

Question

У нас есть кластер Riak с пятью узлами (n_val - 3), работающий на Amazon EC2, распространяющийся по нескольким зонам доступности. Поскольку у нас нет корпоративной версии, у нас нет роскоши репликации нескольких центров обработки данных и полной синхронизации с другой зоной/регионом.

Наша текущая стратегия резервного копирования заключается в следующем:

• SSH для каждого узла в кластере, один узел в то время
• Stop Riak услуги с использованием riak stop (потому что мы используем leveldb бэкенд)
• Issue мгновенный снимок EBS для объема данных, который имеет данные riak
• Запуск службы riak с использованием riak start
• Перейдите к другому узлу и повторите выше этапов

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

Заранее благодарен!

Answer 1

backup documentation утверждает, что

Riak резервные копии могут быть выполнены с использованием функций ОС или файловых систем, которые поддерживают снимки, такие как LVM или ZFS, или с помощью таких инструментов, как Rsync или очернить

I» никогда не использовал моментальный снимок EBS, но я уверен, что его можно рассматривать как «файловую систему, поддерживающую моментальные снимки».

Итак, до тех пор, пока вы закрываете каждый узел перед резервным копированием, вы должны быть хорошими.

О передаче обслуживания: я бы рекомендовал после резервного копирования узла A до резервного копирования следующего узла B, вы будете ждать для всех созданных переключений (потому что А было вниз), были переданы А.

Будьте осторожны, чтобы не учитывать резервное копирование всех отдельных узлов так же, как «резервное копирование всего кластера». Каждый узел будет резервироваться отдельно. Если ваш кластер находится под большой нагрузкой на запись, и вы ожидаете переноса передачи между резервными копиями, вы не можете считать, что резервная копия ваших узлов была выполнена одновременно.

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