Это пример сценария, и мы хотели понять, можно ли его восстановить. А также лучше понять схему.
В гипотетическом сценарии с одним узлом Cassandra 3.11. У меня есть 1 ключевое пространство и 1 таблица.
root@dd85fa9a3c41:/# cqlsh -k cycling -e "describe tables;"
rank_by_year_and_name
Теперь я сбрасываю свою схему и перезапускаю Cassandra: (у меня нет узлов для ее повторной репликации)
root@dd85fa9a3c41:/# nodetool resetlocalschema
С новой схемой я больше не «вижу» свое пространство ключей + таблицу:
root@dd85fa9a3c41:/# cqlsh -e "describe keyspaces;"
system_traces system_schema system_auth system system_distributed
Я потерял свою исходную схему, где было мое пространство ключей + таблица. Но они все еще на диске:
root@dd85fa9a3c41:/# ls -l /var/lib/cassandra/data/cycling/
total 0
drwxr-xr-x 1 root root 14 Nov 22 11:32 rank_by_year_and_name-4eedbbf0
Как я могу восстановить это пространство ключей в этом сценарии? С помощью sstableloader я мог воссоздать таблицу ключей + таблицу и импортировать.
Я хотел бы восстановить эту схему и снова увидеть мое пространство ключей + таблицу. Я не нашел способа сделать это без воссоздания вручную и импорта с помощью sstableloader. Спасибо, если вы мне поможете!
Данные на диске и схема — это две разные вещи в Cassandra.
Чтобы иметь возможность восстановить схему пространства ключей, вам нужно сначала создать ее резервную копию с помощью nodetool snapshot
. Он сделает резервную копию sstable (жесткая ссылка) и создаст файл schema.cql
, содержащий схему.
Смотрите официальный документ здесь: https://cassandra.apache.org/doc/3.11/cassandra/operating/backups.html
Я понимаю, что это гипотетический сценарий, но запускать resetlocalschema
на кластере с одним узлом — плохая идея. Предполагается, что узел отбрасывает свою копию схемы и запрашивает последнюю копию с других узлов, но в случае кластера с одним узлом нет узлов, с которых можно получить схему.
Вам действительно не следует запускать resetlocalschema
на кластере с одним узлом, если только вы не выполняете какие-то конкретные тесты или пограничные действия, как описано в CASSANDRA-5094.
Теперь о вашем вопросе о том, как восстановить схему. Большинство предприятий имеют копию своей схемы, как правило, в системе управления изменениями (или в системе управления CI/Config). Прежде чем в рабочую схему могут быть внесены обновления, она обычно проходит тестирование, рецензирование, промежуточную/предварительную проверку и, наконец, развертывается в рабочей среде с помощью утвержденного запроса на изменение (условия могут различаться в разных организациях, но основная цель заключается в следующем). такой же).
Точно так же, когда вы выполняете регулярное резервное копирование, команда nodetool snapshot
сохраняет копию схемы вместе с резервными копиями SSTable. В этом примере, который я разместил в https://dba.stackexchange.com/questions/316520/, вы можете видеть, что папка snapshots/
содержит как manifest.json
(инвентарь SSTables, включенный в снимок), так и schema.cql
(схема во время снимка):
data/
community/
users-6140f420a4a411ea9212efde68e7dd4b/
snapshots/
1591083719993/
manifest.json
mc-1-big-CompressionInfo.db
mc-1-big-Data.db
mc-1-big-Digest.crc32
mc-1-big-Filter.db
mc-1-big-Index.db
mc-1-big-Statistics.db
mc-1-big-Summary.db
mc-1-big-TOC.txt
schema.cql
Из приведенного выше вы должны увидеть, что у вас есть два доступных варианта:
Выбор зависит от того, чего вы пытаетесь достичь. Ваше здоровье!
Добро пожаловать в Stack Overflow! Дружеское напоминание о том, что этот сайт предназначен для получения помощи в решении проблем с кодированием, алгоритмами или языками программирования, поэтому я проголосовал за то, чтобы ваш пост был перемещен в DBA Stack Exchange. Для дальнейшего использования вы должны публиковать вопросы по администрированию и эксплуатации БД на dba.stackexchange.com/questions/ask?tags=cassandra. Ваше здоровье!