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 также делает предположение, что файлы являются неизменяемыми после их написания.