Я новичок в cassandra и пытаюсь определить хорошую стратегию резервного копирования и восстановления для нашей системы cassandra. Подход, идентифицированный до сих пор (основанный на большом количестве чтения и наших потребностях):
- ежедневное резервное копирование моментальных снимков (включая резервное копирование журналов и схемы фиксации)
- ежечасные инкрементные резервные копии (настраиваемая частота).. включая резервное копирование журналов фиксации)
Резервные копии копируются в облачное хранилище google (создайте сжатый файл со всеми sstable-файлами - снимок / incremenmtals и скопируйте в GCS), который я использую (пользовательскийверсия) этого сценария: https://github.com/GoogleCloudPlatform/cassandra-cloud-backup/blob/master/cassandra-cloud-backup.sh
Пока что это кажется хорошим подходом, однако у меня есть несколько вопросов относительно наилучшего подхода (настройка надежного резервного копирования и восстановления). Я заметил очень частые сбои при попыткерезервное копирование / копирование коммит-логов. Поскольку я выполняю резервное копирование на активных узлах, журналы фиксации циклически повторяются, и в процессе резервного копирования не удается скопировать файлы в GCS. Я еще не планировал использовать архивирование коммитов, поэтому не настроил их для узлов, однако хотел скопировать журналы коммитов с целью ведения записей (и, возможно, ручного воспроизведения при необходимости). У меня вопрос:
- действительно ли это (копирование коммитов) в дополнение к инкрементным файлам? Если да, то какое преимущество / добавленную стоимость они могут предложить?
- Я прочитал здесь , что архивирование и извлечение коммит-журнала работают, только если вы восстанавливаете файлы на одном узле. Означает ли это, что восстановление журнала фиксации не может быть выполнено при запуске нового узла? Как это работает, если я пытаюсь настроить резервный кластер (независимый резервный кластер для DR)? Имеет ли смысл архивация коммитов в этом случае?