Apache Cassandra. Документация DataStax – Backing up and restoring data. Restoring from a Snapshot

Перевод статьи “Backing up and restoring data. Restoring from a Snapshot” из официальной документации DataStax.

Восстановление данных из снимка

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

Как правило, перед восстановлением данных из снимка, вы должны очистить таблицу с помощью команды “truncate” ¹. Если резервное копирование данных произошло перед операцией удаления (delete ²) и вы восстановили резервную копию после удаления без изначальной очистки (truncate), вы не получите назад оригинальные данные (записи). До операции сжатия SSTable (compaction), надгробия и оригинальные записи находятся в разных SSTable. Таким образом восстановление SSTable, которые содержат оригинальные записи, не удаляет надгробия и данные по-прежнему будут ожидать удаления.

Cassandra может восстановить данные из снимка только когда существует схема таблицы. Если у вас нет резервной копии схемы, вы можете пойти двумя путями:

Метод №1
1) Восстановить снимок как описано ниже;
2) Пересоздать схему.

Метод №2
1) Пересоздать схему;
2) Восстановить данные из снимка, как описано ниже;
3) Запустить команду “nodetool refresh” ³.

Процедура

Вы можете восстановить данные из снимка несколькими путями:

• использовать утилиту sstableloader ⁴;
• скопировать директорию снимков SSTable (см. статью “Создание снимка данных”) в директорию data/имя_пространства_ключей/имя_таблицы и затем вызвать метод loadNewSSTables() в колоночном семействе MBean для каждого колоночного семейства через консоль JConsole. Вы можете использовать “nodetool refresh” вместо вызова loadNewSSTables().
  Расположение каталога данных зависит от типа установки:
  1) по умолчанию: /var/lib/cassandra/data
  2) произвольная установка: install_location/data/data
• использовать метод перезапуска узла (Node Restart Method) как описано ниже.

Метод перезапуска узла

Если производится восстановление одиночного узла, вы должны сначала выключить службу Cassandra. Если восстанавливаются данные всего кластера, вы должны с самого начала выключить Cassandra на всех узлах, восстановить данные снимка и затем запустить службы снова.
Примечание: Восстановление из снимка и восстановление икрементных резервных копий временно вызовут интенсивное использование жесткого диска и процессора узла (или узлов, в случае восстановления данных всего кластера).

Процедура
1) Отключение службы Cassandra;

2) Очистить содержимое каталога commitlog:
– для установки по умолчанию: /var/lib/cassandra/commitlog
– для установки в произвольный каталог: install_location/data/commitlog
Это предотвратит воспроизведение данных из commitlog при запуске службы на узле, которое будет мешать восстановлению данных на конкретный момент времени.

3) Удалите все файлы с расширением .db в каталоге каталог_данных/имя_пространства_ключей/имя_таблицы, но НЕ УДАЛЯЙТЕ подкаталоги /snapshots и /backups.
где каталог_данных это:
– для установки по умолчанию: /var/lib/cassandra/data
– для установки в произвольный каталог: install_location/data/data

4) Найдите самую свежую папку со снимками данных в каталоге:
каталог_данных/имя_пространства_ключей/имя_таблицы/snapshots/имя_снимка

5) Скопировать содержимое этой папки в каталог:
каталог_данных/имя_пространства_ключей/имя_таблицы

6) Если используется инкрементное резервное копирование, скопируйте все содержимое каталога:
каталог_данных/имя_пространства_ключей/имя_таблицы/backups

7) В каталог
каталог_данных/имя_пространства_ключей/имя_таблицы

8) Перезапустите службу Cassandra
После перезапуска будет временное увеличение использования жестких дисков и процессора.

9) Запустите “nodetool repair” ⁵.

Оригинал статьи: Restoring from a Snapshot