Cassandra 节点卡在 Joining 状态

Question

我正在尝试使用 auto_bootstrap: true 选项将新节点添加到现有 Cassandra 3.11.1.0 集群。新节点完成了来自其他节点的数据流传输、二级索引构建和主表的压缩过程，但之后它似乎卡在了 JOINING 状态。节点的 system.log 中没有错误/警告 - 只是 INFO 消息。

在二级索引构建和压缩过程中，节点上的 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 表明对 Small/Gossip 消息的 Completed 请求的计数器正在增加：

# 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 池的 Completed 请求的计数器正在增加：

# 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% 的 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'), ...]**

由于清理是本地过程，它不会在引导期间影响新节点。但我可能是错的。

任何帮助将不胜感激。

Answer 1

有时会发生这种情况。可能是八卦通信存在问题，表明加入已完成，或者另一个节点很快报告为DN 并中断了该过程。

发生这种情况时，您有两种选择：

1. 您可以随时停止节点，将其擦除，然后再次尝试加入。
2. 如果您确定所有（或大部分）数据都在那里，您可以停止节点，并在auto_bootstrap: false 的 cassandra.yaml 中添加一行。该节点将启动、加入集群并提供其数据。对于此选项，通常最好在节点启动后运行修复。

Answer 2

只是 Auto_bootstrap: false 在新节点的 cassandra.yaml 上。然后重启节点。它将作为联合国加入。一段时间后运行完全修复，这将确保一致性。