架构更改后 Cassandra 无法启动

Posted 2023-03-22

【中文标题】架构更改后 Cassandra 无法启动

【英文标题】：Cassandra fails to start after schema changed

【发布时间】：2021-03-21 06:46:14

【问题描述】：

我在带有 3 节点集群的 Centos 7 上使用 Cassandra 3.11.6，我运行了一些架构更改、删除表/物化视图、更改表等，之后其中一个物化视图因以下错误而失败： 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 - 在 system_schema.columns 中找不到表 my_keyspace.my_materialized_view 的分区列。这可能是由于损坏或同时删除和更改表。如果应该删除此表，请运行以下查询进行清理：“DELETE FROM system_schema.tables WHERE keyspace_name = 'my_keyspace' AND table_name = 'my_materialized_view'; DELETE FROM system_schema.columns WHERE keyspace_name = 'my_keyspace' AND table_name = ' my_materialized_view';"如果不应该删除该表，请从备份中恢复 system_schema.columns sstables。 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.fetchTable(SchemaKeyspace.java:1046) [apache-cassandra-3.11.6.jar:3.11.6] 在 org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:1000) [apache-cassandra-3.11.6.jar:3.11.6] 在 org.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]

我尝试使用 -Dcassandra.ignore_corrupted_schema_tables=true 启动 Cassandra，但它不起作用

【参考方案1】：

看起来您要么对架构进行了并发更新，要么至少使多个 DDL 语句彼此靠近，从而导致集群中的架构不一致。

您应该等待单个 DDL 更改通过集群传播并检查架构是否一致，然后再进行下一次 DDL 更改以防止不一致。

我的建议是尝试启动您正在执行架构更改的节点并暂时关闭其他节点。希望它也是一个种子节点。

删除ignore_corrupted_schema_tables，看看你能不能让它重新上线。如果是，则继续到下一个节点并观察启动顺序（在system.log 上执行tail -f）。继续，直到所有节点都重新上线。

问题在于，根据每个节点上模式的状态，很难“解读鸡蛋”。祝你好运！

【讨论】：

我使用脚本一个接一个地更改了架构，所以这可能是我的错误，集群没有时间确认更改并且它损坏了。

这很不幸。出于这个原因，我不鼓励所有人以编程方式更改架构。