Cassandra节点卡在连接状态
我正在尝试使用auto_bootstrap:true选项向现有Cassandra 3.11.1.0集群添加一个新节点。新节点完成了来自其他节点的数据流、主表的二级索引构建和压缩过程，但之后它似乎陷入了连接状态。节点的Cassandra节点卡在连接状态,cassandra,cassandra-3.0,Cassandra,Cassandra 3.0,我正在尝试使用auto_bootstrap:true选项向现有Cassandra 3.11.1.0集群添加一个新节点。新节点完成了来自其他节点的数据流、主表的二级索引构建和压缩过程，但之后它似乎陷入了连接状态。节点的系统日志中没有错误/警告-只有信息消息 另外，在二级索引构建和压缩过程中，节点上有大量的CPU负载，现在没有了。因此，看起来节点在引导过程中被卡住，当前处于空闲状态 # nodetool status Datacenter: dc1 =============== Status=Up
系统日志中没有错误/警告-只有信息消息
另外，在二级索引构建和压缩过程中，节点上有大量的CPU负载，现在没有了。因此，看起来节点在引导过程中被卡住，当前处于空闲状态
# 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
显示有一些compactions挂起，但我不知道是否有一些活动或它只是卡住了：
# nodetool compactionstats
pending tasks: 4
- keyspace_name.table_name: 4
nodetool netstats
显示，已完成的小型/八卦消息请求的计数器正在增加：
# 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
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
nodetool tpstats
显示CompactionExecutor、MigrationStage和GossipStage池的已完成请求的计数器正在增加：
# 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
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
所以看起来node仍然在从其他节点接收数据并应用它，但我不知道如何检查进度，我应该等待还是取消引导。我已经尝试重新引导此节点，但出现以下情况：节点长时间（16小时）处于UJ状态，有一些等待压缩，99.9%的CPU空闲。另外，我在大约一个月前将节点添加到集群中，没有任何问题-节点在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'), ...]**
由于清理是本地过程，因此在引导过程中不会影响新节点。但我可能错了
任何帮助都将不胜感激。有时会发生这种情况。可能是由于八卦通信问题导致加入已完成，或者可能是另一个节点很快报告为DN
，并中断了该过程
发生这种情况时，您有两个选择：
您始终可以停止节点，擦除它，然后再次尝试加入它
如果您确定所有（或大部分）数据都在那里，则可以停止节点，并在auto\u bootstrap:false的cassandra.yaml中添加一行。节点将启动、加入集群并为其数据提供服务。对于此选项，通常最好在节点启动后运行修复
仅自动引导：在新节点的cassandra.yaml上为false。然后重新启动节点。它将作为联合国会员国加入。一段时间后，运行全面修复，以确保一致性