Nous avions DataStax Cassandra Community Server 3.0.2 installé sur nos boîtes, nous avons créé quelques espaces de clés et nous avons migré des données de notre ancien DB à Cassandra (10 Go de Les données). Pendant que la migration se produisait, nous avons créé materialized views sur ces tables. Après quelques minutes (je ne sais pas exactement combien de temps) après la création, nos services (déployés sur ~ 2x3 nœuds dans 2 Data Center Architecture) se sont arrêtés aléatoirement avec absolument aucune information sur les raisons de l'arrêt. Après que nous avons essayé de commencer notre service, nous avons obtenu l'erreur suivante dans nos journauxCassandra Exception Cache schéma version X ne correspond pas à la version actuelle du schéma Y
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]
Nous avons essayé de regarder dans le code où cette excpetion pourrait être causé. Cela nous a donné quelques informations sur ce qui le provoque - apparemment, le service essaye de faire correspondre la version actuelle du schéma avec celle qui est présente dans le cache (je suppose que c'est soit avant l'arrêt du service/création de vues matérialisées) n'a pas effectué de modifications de schéma sur l'espace de clé en dehors de la création de vues matérialisées.
Alors qu'est-ce qui me fait réfléchir, c'est que personne n'a signalé de problème de ce genre dans le passé? Nous ne sommes donc pas sûrs de ce qui ne va pas de notre côté. Nous avons couru nodetool cleanup sur nos nœuds sans aide. Nous ne voulons pas perdre de données. Nous essayons de récupérer, donc nous avons supprimé le dossier $CASSANDRA_HOME\data\saved_caches et redémarrer le service. Au démarrage du serveur, il relit les commitlogs et cela prend beaucoup de temps. Je suppose que cela pourrait être dû à la quantité de données que nous avons ou les machines sont totalement disparu et doivent être remplacés? Tous les pointeurs liés à la question peuvent être vraiment utiles! Merci d'avance. Si cela peut vous aider, nous exécutons DataStax Cassandra Server sur des machines Windows et exécutons Cassandra en tant que service Windows.
J'ai rencontré le même problème en essayant d'importer un fichier csv de 22 Go via cqlsh. Après avoir redémarré le même message d'erreur apparaît. Des progrès à ce sujet? Edit: J'utilise Cassandra 3.3 – WaeCo
J'ai fini par reconstruire le cluster. Je ne pourrais pas résoudre ni trouver aucune bonne ressource sur le Web. Désolé, ne pourrait pas être d'une grande aide! – Learner
bien, pas exactement une solution, mais plutôt que de reconstruire l'ensemble du cluster, vous pouvez supprimer le KeyCache-d.db et CommitLog-x-xxx.log. cela entraînera principalement la perte de données. donc c'est seulement une solution temporaire, j'espère que quelqu'un là-bas connaîtra la vraie solution et partagera! – ken