Cassandra: резервное копирование всего пространства ключей

Мне просто интересно, что будет лучшим способом резервного копирования всего пространства ключей в Cassandra... как вы думаете?

Ранее я просто скопировал папку данных на мой резервный жесткий диск, но потом у меня возникли проблемы с восстановлением базы данных после обновления.

Ответы

Ответ 1

Лучший способ - сделать снимки (nodetool snapshot). Вы можете много узнать о том, как это работает и как лучше всего использовать его в этой Документация Datastax (отказ от ответственности: я работаю для Datastax).

Вы хотите, чтобы у вас включен JNA (некоторые соответствующие инструкции можно найти на на этой странице). Если вы это сделаете, моментальные снимки будут очень быстрыми; они просто жесткие ссылки на существующие sstables. Копирование не требуется. Вы можете комбинировать снимки с другими инструментами резервного копирования (или просто rsync, cp и т.д.), Если вы хотите отслеживать свои резервные копии определенным образом.

Ответ 2

Помимо чтения документации Datastax, я нашел статью "поэтапное резервное копирование cassandra с amanda" проницательным, Это о том, как использовать инкрементные резервные копии и моментальные снимки.

В конце он рекомендует следующие процедуры:

  • Полная резервная копия
    • Удалить старые инкрементные файлы и символические ссылки.
    • nodetool snapshot
    • Symlink всех файлов моментальных снимков в каталог резервного копирования
    • Резервное копирование символических ссылок разметки в каталоге.
    • nodetool clearsnapshot и удалите символические ссылки.
  • Инкрементальные резервные копии (не путать с инкрементными резервными копиями cassandra):
    • nodetool flush
    • Symlink все инкрементные файлы в каталог резервного копирования.
    • Резервное копирование символических ссылок разметки в каталоге.
  • Восстановление
    • Восстановить последнюю полную резервную копию и все инкременты.

Ответ 3

Я написал простой инструмент python для автоматизации снимков и резервных копий кластеров и их хранения на S3.

https://github.com/tbarbugli/cassandra_snapshotter - это страница github, там вы также можете найти документацию

Ответ 4

Другим вариантом является мониторинг записываемых sstables и постепенное резервное копирование этих файлов.

Посмотрите tablesnap, например.

Из документации:

Tablesnap - это script, который использует inotify для мониторинга каталога для событий IN_MOVED_TO и реагирует на них, создавая новый поток для загрузки этого файла в Amazon S3 вместе с JSON-форматированным списком других файлов в каталог на момент копирования.

При запуске кластера Cassandra это поведение может быть весьма полезным, поскольку оно позволяет автоматически создавать резервные копии SSTables в момент времени. Теоретически, tablenap должен работать для любого приложения, где файлы записываются в какое-то временное местоположение, а затем перемещается в свое конечное местоположение после записи данных на диск. Tablesnap также делает предположение, что файлы являются неизменяемыми после их написания.