#java #cassandra #nodetool
#java #cassandra #nodetool
Вопрос:
У нас есть кластер Cassandra с 3 узлами, работающий под управлением следующей версии
[cqlsh 5.0.1 | Cassandra 3.11.6 | CQL spec 3.4.4 | Native protocol v4]
Node1 прекратил связь с остальной частью кластера этим утром, журналы показали это:
ERROR [CompactionExecutor:242] 2020-09-15 19:24:48,753 CassandraDaemon.java:235 - Exception in thread Thread[CompactionExecutor:242,1,main]
ERROR [MutationStage-2] 2020-09-15 19:24:54,749 AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread Thread[MutationStage-2,5,main]
ERROR [MutationStage-2] 2020-09-15 19:24:54,771 StorageService.java:466 - Stopping gossiper
ERROR [MutationStage-2] 2020-09-15 19:24:56,791 StorageService.java:476 - Stopping native transport
ERROR [CompactionExecutor:242] 2020-09-15 19:24:58,541 LogTransaction.java:277 - Transaction log [md_txn_compaction_c2dbca00-f780-11ea-95eb-cf88b1cae05a.log in /mnt/cass-a/data/system/local-7ad54392bcdd35a684174e047860b377] indicates txn was not completed, trying to abort it now
ERROR [CompactionExecutor:242] 2020-09-15 19:24:58,545 LogTransaction.java:280 - Failed to abort transaction log [md_txn_compaction_c2dbca00-f780-11ea-95eb-cf88b1cae05a.log in /mnt/cass-a/data/system/local-7ad54392bcdd35a684174e047860b377]
ERROR [CompactionExecutor:242] 2020-09-15 19:24:58,566 LogTransaction.java:225 - Unable to delete /mnt/cass-a/data/system/local-7ad54392bcdd35a684174e047860b377/md_txn_compaction_c2dbca00-f780-11ea-95eb-cf88b1cae05a.log as it does not exist, see debug log file for stack trace
Cassandra нормально запускается на «сломанном узле», но отказывается присоединяться к кластеру.
Когда я выполняю статус nodetool, я получаю это:
**Error: The node does not have system_traces yet, probably still bootstrapping**
Сплетни не запущены, я пробовал отключать и повторно включать, никакой радости.
Я также пробовал как ремонт, так и перестройку, оба вернулись без ошибок вообще.
Любая помощь будет оценена.
Спасибо.
Ответ №1:
Описанные вами симптомы указывают на то, что у узла произошел какой-то аппаратный сбой, и data/ диск, возможно, недоступен.
В подобных случаях срабатывает политика сбоев диска cassandra.yaml :
disk_failure_policy: stop
Это объясняет, почему gossip недоступен (на порту по умолчанию 7000 ), и узел также не будет принимать никаких клиентских подключений (на порту CQL по умолчанию 9042 ).
Если происходит надвигающийся аппаратный сбой, есть большая вероятность, что диск / том смонтирован как доступный только для чтения. Также существует вероятность того, что диск заполнен. Проверьте журналы операционной системы на наличие подсказок, и вам, вероятно, потребуется передать проблему вашей команде системных администраторов. Приветствия!
Комментарии:
1. Эй, Эрик, ты прав, похоже, произошел сбой политики диска. Я пытался вручную создать файл на диске и не смог. tI может подтвердить, что виртуальная машина не пострадала от каких-либо «аппаратных» сбоев, и на хосте, на котором запущена виртуальная машина, также запущено много других виртуальных машин, и все они выглядят нормально, а также общее хранилище, к которому подключена виртуальная машина. Как мне решить эту проблему, я перезагрузил виртуальную машину, и cassandra запускается нормально, но сплетни и клиентские подключения не происходят.
2. Как я уже сказал, убедитесь, что (а) диск / том не смонтирован как доступный только для чтения, и (б) диск не заполнен. Любой из них предотвратил бы работу gossip и вызвал бы политику сбоев диска. Приветствия!
3. Итак, оказывается, что именно эти надоедливые inode #screamingface выполнили clearsnapshot nodetool, который очистил все inode, перезапустил cassandra, и мир стал лучше. 🙂 Спасибо за вашу помощь, Эрик.
4. Рад слышать, что вы определили проблему. Приветствия!