Cassandra 异常缓存架构版本 X 与当前架构版本 Y 不匹配

Posted 2023-03-22

【中文标题】Cassandra 异常缓存架构版本 X 与当前架构版本 Y 不匹配

【英文标题】：Cassandra Exception Cache schema version X does not match current schema version Y

【发布时间】：2016-07-03 05:39:20

【问题描述】：

我们在盒子上安装了 DataStax Cassandra Community Server 3.0.2，创建了几个键空间，并将一些数据从旧数据库迁移到 Cassandra（大约 10GB 数据）。在迁移过程中，我们在这些表上创建了materialized views。创建后几分钟（不确定到底多长时间），我们的服务（部署在 2 个数据中心架构中的约 2x3 个节点上）随机停止，完全没有关于它停止原因的日志信息。之后我们尝试启动我们的服务，我们的日志中出现以下错误

java.lang.RuntimeException: Cache schema version a2c390a1-f2cd-3d59-8b5c-a0a1d794d0fe does not match current schema version 8d1347d7-7729-3698-8537-4b91ae9ce7dd
    at org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:198) ~[apache-cassandra-3.0.2.jar:3.0.2]
    at org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:157) [apache-cassandra-3.0.2.jar:3.0.2]
    at org.apache.cassandra.cache.AutoSavingCache$3.call(AutoSavingCache.java:153) [apache-cassandra-3.0.2.jar:3.0.2]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_66]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_66]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_66]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 

我们试图查看可能导致此异常的代码。这给了我们一些关于导致它的信息 - 显然服务试图将当前模式版本与缓存中存在的模式版本匹配（我假设它在服务停止/创建物化视图之前） 我们非常确定，除了创建物化视图之外，我们没有对键空间进行任何架构更改。

那么让我感到奇怪的是，过去没有人报告过任何此类问题？所以我们不确定我们这边出了什么问题。我们在没有帮助的情况下在我们的节点上运行了 nodetool cleanup。我们不想丢失任何数据。我们正在尝试恢复，因此我们删除了$CASSANDRA_HOME\data\saved_caches 文件夹并重新启动服务。启动服务器时，它正在重播提交日志，并且需要很长时间。我认为这可能是由于我们拥有的数据量很大，或者机器完全没有了，需要更换？

与该问题相关的任何指针都可能非常有用！先感谢您。

如果有帮助，我们将在 Windows 机器上运行 DataStax Cassandra Server，并将 Cassandra 作为 Windows 服务运行。

【问题讨论】：

我在尝试通过 cqlsh 导入 22GB csv 文件时遇到了同样的问题。重新启动后出现相同的错误消息。这方面有什么进展吗？编辑：我正在使用 Cassandra 3.3

我最终重建了集群。我无法修复，也无法在网络上找到任何好的资源。抱歉，帮不上忙！

嗯，不完全是一个解决方案，但与其重建整个集群，你可以删除 KeyCache-d.db 和 CommitLog-x-xxx.log。这主要会导致数据丢失。所以这只是暂时的解决方法，希望有人知道真正的解决方案并分享！

前面的那一行写着“读取保存的缓存/var/lib/.../KeyCache.db 的无害错误”我相信忽略它是安全的。如果在节点加入集群时发生这种情况，则意味着磁盘保存的密钥缓存不同步，它将重新同步。

我也有同样的问题，我不想丢失数据。我被卡住了，我该怎么办？

【参考方案1】：

清除提交日志目录并重新启动它为我做了。

rm -rf /path/to/cassandra/data/commitlog

晚了，但我希望它可以帮助任何陷入困境的人。

【讨论】：

删除提交日志文件也为我修复了它。我猜数据库架构发生了更改，并且由于架构的更改，重新启动后提交日志无法应用。更改架构似乎会导致各种问题。尽可能避免它。如果必须这样做，则需要刷新所有节点上的提交日志。

这不起作用，很遗憾，我的缓存数据无法加载。

@GünayGültekin 你需要删除saved_caches 而不是提交日志目录。

【参考方案2】：

缓存架构版本...

清除saved_caches 目录不是commit_log 目录。删除 commit_logs 是危险的。如果您的节点意外崩溃并且您的 memtable 数据未刷新，Commit logs 可以节省时间并防止数据丢失。