Cassandra не запускается, в логе ошибка:
ERROR [main] 2024-02-26 00:57:32,905 JVMStabilityInspector.java:82 - Exiting due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException: Mutation checksum failure at 3984 in Next section at 600 in CommitLog-6-1708329368008.log
at org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:344) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:201) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:84) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:140) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:177) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:158) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:325) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) [apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689) [apache-cassandra-3.11.0.jar:3.11.0]
Apache Cassandra — это популярная колоночная база данных, оптимизированная для обработки больших объемов данных на множестве узлов.
Apache Cassandra — распределённая СУБД, относящаяся к классу NoSQL-систем и рассчитанная на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша.
Обращаем внимание на строку:
Mutation checksum failure at 3984 in Next section at 600 in CommitLog-6-1708329368008.log
Вы только послушайте как это звучит: "Сбой контрольной суммы мутации". Киберпанк, едрить-колотить. Если упростить, то повреждены данные в файле CommitLog-6-1708329368008.log.
Commit Log представляет из себя структуру данных (это может быть несколько файлов), которая располагается на жёстком диске и логирует все операции записи для повышения живучести данных (data durability) при различных сбоях, таких как потеря питания. В других СУБД такие логи известны как WAL (write-ahead log) файлы. Эти данные попали на сервер, но ещё не успели записаться в саму БД, т.е. в SSTables.
При некоторых видах сбоев данные могут записаться в лог неполностью, их контрольная сумма (checksum) не совпадает, поэтому Cassandra не может восстановить эти данные при запуске и не стартует, хотя, в настройках такое поведение можно изменить. Не представляю в каких случаях нам может понадобиться Cassandra, в которой данные могут быть в несогласованном состоянии.
Видео про Commit Log, в конце видео приводятся ещё типы ошибок, которые нужно лечить таким же способом:
- CommitLogReplayException: Encountered bad header at position 0000000 of commit log
CommitLogReplayException: Could not read commit log descriptor in file - CommitLogReplayException: Unexpected error deserializing mutation — This may be caused by replaying a mutation against a table with the same name but incompatible schema
UnknownColumnFamilyException
Лечение
Поскольку Commit Log повреждён, то его нужно удалить. Удаляем файл CommitLog-6-1708329368008.log, возможно, понадобится удалить несколько файлов.
rm -f /opt/cassandra/data/commitlog/CommitLog-6-1708329368008.log
systemctl restart cassandra
В крайнем случае можно удалить все логи, но я не рекомендую:
rm /opt/cassandra/data/commitlog/CommitLog*
systemctl restart cassandra
После того как мы избавимся от кривых логов, кассандра запустится.
systemctl status cassandra
Но данные на ней будут несогласованны. Утерянные данные вручную мы не восстановим, нужно запустить процедуру восстановления: repair.
/opt/cassandra/bin/nodetool repair --full
Потерянные данные будут восстановлены с других нод. Процедура долгая и потребляет много ресурсов.
Примечание
Опция для игнорирования поврежденных логов. Может использоваться при наличие периодического расписания полного восстановления:
-Dcassandra.commitlog.ignorereplayerrors=true
Примечание 2
Некоторые виды ошибок с логами последние версии кассандры умеют восстанавливать автоматически.
