Я пытаюсь добавить новый узел в существующий кластер Cassandra 3.11.1.0 с опцией auto_bootstrap: true.Новый узел Завершил потоковую передачу данных с других узлов, создание вторичного индекса и сжатые процедуры для главной таблицы, но после этого он, похоже, застрял в состоянии JOINING .Нет ошибок / предупреждений в узлах system.log - только INFO сообщений.
Также во время процедур создания вторичного индекса и компактных операций на узле была значительная нагрузка ЦП, а теперь ее нет.Таким образом, похоже, что узел застрял во время начальной загрузки и в настоящее время бездействует.
# nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN XX.XX.XX.109 33.37 GiB 256 ? xxxx-9f1c79171069 rack1
UN XX.XX.XX.47 35.41 GiB 256 ? xxxx-42531b89d462 rack1
UJ XX.XX.XX.32 15.18 GiB 256 ? xxxx-f5838fa433e4 rack1
UN XX.XX.XX.98 20.65 GiB 256 ? xxxx-add6ed64bcc2 rack1
UN XX.XX.XX.21 33.02 GiB 256 ? xxxx-660149bc0070 rack1
UN XX.XX.XX.197 25.98 GiB 256 ? xxxx-703bd5a1f2d4 rack1
UN XX.XX.XX.151 21.9 GiB 256 ? xxxx-867cb3b8bfca rack1
nodetool compactionstats показывает, что есть ожидающие сжатия, но я не знаю, есть ли какая-то активность или он просто застрял:
# nodetool compactionstats
pending tasks: 4
- keyspace_name.table_name: 4
nodetool netstats показывает, что счетчики завершенных запросов для сообщений Small / Gossip увеличиваются:
# nodetool netstats
Mode: JOINING
Bootstrap xxxx-81b554ae3baf
/XX.XX.XX.109
/XX.XX.XX.47
/XX.XX.XX.98
/XX.XX.XX.151
/XX.XX.XX.21
Read Repair Statistics:
Attempted: 0
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool Name Active Pending Completed Dropped
Large messages n/a 0 0 0
Small messages n/a 0 571777 0
Gossip messages n/a 0 199190 0
nodetool tpstats показывает, что счетчики завершенных запросов для пулов CompactionExecutor, MigrationStage, GossipStageувеличиваются:
# nodetool tpstats
Pool Name Active Pending Completed Blocked All time blocked
ReadStage 0 0 0 0 0
MiscStage 0 0 0 0 0
CompactionExecutor 0 0 251 0 0
MutationStage 0 0 571599 0 0
MemtableReclaimMemory 0 0 98 0 0
PendingRangeCalculator 0 0 7 0 0
GossipStage 0 0 185695 0 0
SecondaryIndexManagement 0 0 2 0 0
HintsDispatcher 0 0 0 0 0
RequestResponseStage 0 0 6 0 0
ReadRepairStage 0 0 0 0 0
CounterMutationStage 0 0 0 0 0
MigrationStage 0 0 14 0 0
MemtablePostFlush 0 0 148 0 0
PerDiskMemtableFlushWriter_0 0 0 98 0 0
ValidationExecutor 0 0 0 0 0
Sampler 0 0 0 0 0
MemtableFlushWriter 0 0 98 0 0
InternalResponseStage 0 0 11 0 0
ViewMutationStage 0 0 0 0 0
AntiEntropyStage 0 0 0 0 0
CacheCleanupExecutor 0 0 0 0 0
Message type Dropped
READ 0
RANGE_SLICE 0
_TRACE 0
HINT 0
MUTATION 124
COUNTER_MUTATION 0
BATCH_STORE 0
BATCH_REMOVE 0
REQUEST_RESPONSE 0
PAGED_RANGE 0
READ_REPAIR 0
Похоже, что узел все еще получает некоторые данные от других узлов и применяет их, но я не знаю, как проверить прогресс, и должен ли я ждать или отменить загрузку.Я уже пытался перезапустить этот узел и получил следующую ситуацию: узел долгое время находился в состоянии UJ (16 часов) с некоторым ожидающим сжатием и 99,9% простоя процессора.Также я добавил узлы в кластер около месяца назад, и никаких проблем не было - узлы присоединились в течение 2-3 часов и стали в состоянии UN .
Также nodetool cleanup работает на одном из существующих узлов на этом узле. Я вижу следующие предупреждения в system.log:
**WARN [STREAM-IN-/XX.XX.XX.32:46814] NoSpamLogger.java:94 log Spinning trying to capture readers [BigTableReader(path='/var/lib/cassandra/data/keyspace_name/table_name-6750375affa011e7bdc709b3eb0d8941/mc-1117-big-Data.db'), BigTableReader(path='/var/lib/cassandra/data/keyspace_name/table_name-6750375affa011e7bdc709b3eb0d8941/mc-1070-big-Data.db'), ...]**
Поскольку очистка является локальной процедурой, она не может повлиять на новый узел во времясамозагрузки.Но я могу ошибаться.
Любая помощь будет оценена.