Мне просто интересно, что будет лучшим способом резервного копирования всего пространства ключей в Cassandra... как вы думаете?
Ранее я просто скопировал папку данных на мой резервный жесткий диск, но потом у меня возникли проблемы с восстановлением базы данных после обновления.
Лучший способ - сделать снимки (nodetool snapshot). Вы можете много узнать о том, как это работает и как лучше всего использовать его в этой Документация Datastax (отказ от ответственности: я работаю для Datastax).
Вы хотите, чтобы у вас включен JNA (некоторые соответствующие инструкции можно найти на на этой странице). Если вы это сделаете, моментальные снимки будут очень быстрыми; они просто жесткие ссылки на существующие sstables. Копирование не требуется. Вы можете комбинировать снимки с другими инструментами резервного копирования (или просто rsync, cp и т.д.), Если вы хотите отслеживать свои резервные копии определенным образом.
Помимо чтения документации Datastax, я нашел статью "поэтапное резервное копирование cassandra с amanda" проницательным, Это о том, как использовать инкрементные резервные копии и моментальные снимки.
В конце он рекомендует следующие процедуры:
nodetool snapshotnodetool clearsnapshot и удалите символические ссылки.nodetool flushЯ написал простой инструмент python для автоматизации снимков и резервных копий кластеров и их хранения на S3.
https://github.com/tbarbugli/cassandra_snapshotter - это страница github, там вы также можете найти документацию
Другим вариантом является мониторинг записываемых sstables и постепенное резервное копирование этих файлов.
Посмотрите tablesnap, например.
Из документации:
Tablesnap - это script, который использует inotify для мониторинга каталога для событий IN_MOVED_TO и реагирует на них, создавая новый поток для загрузки этого файла в Amazon S3 вместе с JSON-форматированным списком других файлов в каталог на момент копирования.
При запуске кластера Cassandra это поведение может быть весьма полезным, поскольку оно позволяет автоматически создавать резервные копии SSTables в момент времени. Теоретически, tablenap должен работать для любого приложения, где файлы записываются в какое-то временное местоположение, а затем перемещается в свое конечное местоположение после записи данных на диск. Tablesnap также делает предположение, что файлы являются неизменяемыми после их написания.