使用 Vnode 重新平衡 Cassandra 环答案

【问题标题】：Rebalancing a Cassandra Ring with Vnodes使用 Vnode 重新平衡 Cassandra 环
【发布时间】：2015-02-05 21:30:42
【问题描述】：

我们有一个带有 3 节点 Cassandra 2.0.6 环的系统。随着时间的推移，该系统上的应用程序负载增加，直到环无法再处理它的限制，导致典型的节点过载故障。

我们将环的大小增加了一倍，最近甚至增加了一个节点来尝试处理负载，但仍然只有 3 个节点承担所有负载；但不是初始环的原始 3 个节点。

我们执行了adding nodes guide 中描述的bootstrap + cleanup 过程。在没有看到环负载有很大改善后，我们还在每个节点上尝试了repairs。我们的负载是这个系统上 99.99% 的写入。

这是说明问题的集群负载图表：

负载最高的表在分区键上具有高基数，我希望它可以很好地分布在 vnode 上。

编辑：节点工具信息

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens  Owns   Host ID                               Rack
UN  x.y.z.92     56.83 GB   256     13.8%  x-y-z-b53e8ab55e0a  rack1
UN  x.y.z.253    136.87 GB  256     15.2%  x-y-z-bd3cf08449c8  rack1
UN  x.y.z.70     69.84 GB   256     14.2%  x-y-z-39e63dd017cd  rack1
UN  x.y.z.251    74.03 GB   256     14.4%  x-y-z-36a6c8e4a8e8  rack1
UN  x.y.z.240    51.77 GB   256     13.0%  x-y-z-ea239f65794d  rack1
UN  x.y.z.189    128.49 GB  256     14.3%  x-y-z-7c36c93e0022  rack1
UN  x.y.z.99     53.65 GB   256     15.2%  x-y-z-746477dc5db9  rack1

编辑：tpstats（节点高负载）

Pool Name                    Active   Pending      Completed   Blocked  All time blocked
ReadStage                         0         0       11591287         0                 0
RequestResponseStage              0         0      283211224         0                 0
MutationStage                    32    405875      349531549         0                 0
ReadRepairStage                   0         0           3591         0                 0
ReplicateOnWriteStage             0         0              0         0                 0
GossipStage                       0         0        3246983         0                 0
AntiEntropyStage                  0         0          72055         0                 0
MigrationStage                    0         0            133         0                 0
MemoryMeter                       0         0            205         0                 0
MemtablePostFlusher               0         0          94915         0                 0
FlushWriter                       0         0          12521         0                 0
MiscStage                         0         0          34680         0                 0
PendingRangeCalculator            0         0             14         0                 0
commitlog_archiver                0         0              0         0                 0
AntiEntropySessions               1         1              1         0                 0
InternalResponseStage             0         0             30         0                 0
HintedHandoff                     0         0           1957         0                 0

Message type           Dropped
RANGE_SLICE                  0
READ_REPAIR                196
PAGED_RANGE                  0
BINARY                       0
READ                         0
MUTATION              31663792
_TRACE                   24409
REQUEST_RESPONSE             4
COUNTER_MUTATION             0

如何进一步解决此问题？

【问题讨论】：

能把nodetool status和nodetool netstats的输出加起来吗？
@StefanPodkowinski 添加了nodetool info。 nodetool netstats 目前可能不准确，因为我们正在环上执行一些操作。
@maasg，查看 nodetool info 的输出看起来负载分布相当均匀。但似乎以前的数据在某些节点中没有被删除。清理是否在这些节点上运行？
@DesertIce cleanup 应该在原始节点上运行。集群上的负载是 99.99% 的写入。

标签： performance cassandra load cassandra-2.0

【解决方案1】：

您需要在之前属于环的节点上运行 nodetool cleanup。 Nodetool cleanup 将删除节点当前不拥有的分区键。

似乎在添加节点之后，键并没有被删除，因此导致先前节点上的负载更高。

尝试运行

nodetool cleanup

     on the previous nodes

【讨论】：

这会影响写入吗？
@maasg，它应该会影响以前机器上的磁盘负载。当您说集群写入负载是 99.9% 写入时，这实际上是什么意思。你是怎么定义的？
该系统的写入负载约为 500-1000 msgs/sec - 写入主要是现有键上的新列，从不覆盖。我们的阅读是偶尔的，基于汇总报告。 99.99% 是“有根据的猜测”。我们有第二个类似大小的系统，Cassandra 在 6 个节点上以 10% 的 CPU 平稳运行。
所以您将写入负载定义为消息数？根据 CPU 或磁盘负载来定义它不是有意义吗？
@maasg，你能粘贴 nodetool tpstats 的输出吗？