我正在尝试使用auto\u bootstrap:true选项向现有的cassandra3.11.1.0集群添加一个新节点。新节点完成了其他节点的数据流、二级索引的建立和主表的压缩过程，但之后似乎陷入了连接状态。节点中没有错误/警告 system.log -只是信息信息。
另外，在二级索引构建和压缩过程中，节点上有大量的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` 显示有一些压缩挂起，但我不知道是否有一些活动或只是卡住了：

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` 显示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

所以看起来node仍在从另一个节点接收一些数据并应用它，但我不知道如何检查进度，我应该等待还是取消引导。我已经尝试过重新引导这个节点，但出现了以下情况：节点长时间处于uj状态（16小时），有一些等待压缩，99.9%的cpu空闲。另外，我在大约一个月前将节点添加到集群中，没有任何问题—节点在2-3小时内加入，并处于非状态。
也 `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'), ...]

因为清理是本地过程，所以在引导过程中它不会影响新节点。但我可能错了。
任何帮助都将不胜感激。