Блог

Я использую Cassandra 3.11.6 на Centos 7 с 3-узловым кластером, я внес некоторые изменения в схему, удалил таблицы / материализованные представления, изменил таблицы и т. Д., После этого одно из материализованных представлений не удалось с этой ошибкой: org.apache.cassandra.schema.SchemaKeyspace $MissingColumns: в таблице схемы для my_keyspace.my_materialized_view не найдено ключевых столбцов раздела.

Я хотел заменить это материализованное представление таблицей с тем же именем, хотя, возможно, именно поэтому он терпит неудачу

Я запустил nodetool describecluster и обнаружил, что версия схемы отличается, я попытался запустить восстановление, оно не сработало, я перезапустил узлы, но они не запустились.

Это ошибка, которая отображается в cassandra.log

ОШИБКА [main] 2020-12-09 10:13:15,827 SchemaKeyspace.java: 1017 — Не найдено столбцов раздела для таблицы my_keyspace.my_materialized_view в system_schema.columns. Это может быть связано с повреждением или одновременным удалением и изменением таблицы. Если предполагается, что эта таблица будет удалена, выполните следующий запрос для очистки: «УДАЛИТЬ ИЗ system_schema.tables, ГДЕ keyspace_name = ‘my_keyspace’ И table_name = ‘my_materialized_view’; УДАЛИТЬ ИЗ system_schema.columns, ГДЕ keyspace_name = ‘my_keyspace’ И table_name = ‘my_materialized_view’;» Если таблица не должна быть удалена, восстановите системные таблицы system_schema.columns из backup. org.apache.cassandra.schema.SchemaKeyspace $MissingColumns: в таблице схемы не найдено ключевых столбцов раздела для my_keyspace.my_materialized_view в org.apache.cassandra.schema.SchemaKeyspace.fetchColumns(SchemaKeyspace.java: 1106) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.schema.SchemaKeyspace.Извлекаемая таблица (SchemaKeyspace.java: 1046) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.schema.SchemaKeyspace.Извлекаемые таблицы (SchemaKeyspace.java: 1000) [apache-cassandra-3.11.6.jar: 3.11.6] в организации.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:959) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:936) [apache-cassandra-3.11.6.jar:3.11.6] в org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:924) [apache-cassandra-3.11.6.jar:3.11.6] в org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:92) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:82) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java: 269) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630) [apache-cassandra-3.11.6.jar: 3.11.6] в org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:757) [apache-cassandra-3.11.6.jar: 3.11.6]

Я попытался запустить Cassandra с помощью -Dcassandra.ignore_corrupted_schema_tables=true, и это не сработало

Похоже, вы либо одновременно обновили свою схему, либо, по крайней мере, сделали несколько операторов DDL близко друг к другу, чтобы вызвать несогласие схемы в вашем кластере.

Предполагается, что вы должны дождаться, пока одно изменение DDL распространится по кластеру, и проверить, что схема согласована, прежде чем вносить следующее изменение DDL, чтобы предотвратить разногласия.

Я предлагаю попытаться запустить узел, на котором вы выполняли изменения схемы, и временно отключить другие узлы. Надеюсь, это также начальный узел.

Удалите ignore_corrupted_schema_tables и посмотрите, сможете ли вы вернуть его в оперативный режим. Если это произойдет, перейдите к следующему узлу и просмотрите последовательность запуска (выполните a tail -f в system.log ). Продолжайте, пока все узлы не будут подключены к сети.

Проблема в том, что в зависимости от состояния схемы на каждом узле будет сложно «расшифровать яйцо». Удачи!