故事背景

线上有3台Cassandra组成的小集群，随着数据增长，硬盘使用量达到了90%以上，急需扩容。

于是，就查文档，按文档一步步添加新节点，来增加集群规模。

但是，看文档就像看新闻联播，一切都很美好，可实操起来就干啥啥不行，走哪哪是坑。

于是，就有了这篇笔记，把踩坑过程做个记录，希望能帮到深陷泥潭的小伙伴。

第一关：新节点安装配置

按照文档安装、配置新节点。

文档：https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_add_node_to_cluster_t.html

第二关：清空垃圾数据

按照文档启动新节点后，数据同步到20G左右，就会停滞不前，之后再也没动静。

看下日志：

tail -1000 $CASSANDRA_HOME/logs/debug.log

发现有同步到某个表时，有WARN日志。

删除了新节点的data，重来一遍，发现还是一样的情况。

实验过修改Cassandra内存，仍然没有解决问题，况且，其他更大的表都能同步成功，于是怀疑是不是这个表本身有问题呢？

与业务方沟通后，得知这些都是很久不用的，早已废弃，而且数据是从2.1.x的Cassandra迁移过来的，可能存在兼容问题，所以直接干掉！

这样，就跳过了这个WARN，可以继续向下同步了。

如果，你也有这种已经废弃的垃圾数据，建议先删除，再进行同步，避免一些莫名其妙的问题。

删除数据方式：

• CQL：DROP TABLE tablename
• 手动删除每个节点对应的数据目录

第三关：资源优化

由于数据量很大，同步过程会对集群带来很大的负载，所以尽可能关闭或限制一些功能，避免对线上业务造成影响。

• 关闭压缩

$CASSANDRA_HOME/bin/nodetool disableautocompaction
$CASSANDRA_HOME/bin/nodetool stop COMPACTION

所有节点都关闭，包括新节点（新节点启动后关闭）。

• 限制流量

$CASSANDRA_HOME/bin/nodetool setstreamthroughput 32

所有节点都限制。

如果不限制，可能带宽全被数据同步给占用完了，就无法保障线上业务能及时响应了。

这取决于业务情况，如果无所谓，可以不限制。

32的单位是mbps，表示限制某节点用于数据同步的带宽为32mbps，可以根据自己的网络情况设置相应的值。

第四关：Session超时

有些表文件非常大，约60G，按照32mbps带宽估算，传输速度为4m/s，大约需要4.267小时才能完成。

这种情况下，查看日志，会收到一个WARN：

Remote peer xx.xx.xx.xx failed stream session

这是因为session超时了。

需要修改cassandra.ymal文件的streaming_socket_timeout_in_ms值。

默认值是3600000，即1小时，改成172800000（48小时），保证时间足够传输完所有数据。

第五关：飞一会儿

如果同步过程中有WARN，基本上已经失败了，可以停掉重来了。

当把所有WARN都解决后，就耐心等待，让它飞一会儿。

最好用网络工具监控下流量，时刻监控新节点的网络流入量是否正常。

如果用nodetool status查看状态，可能变化很慢，不要慌，只要传输流量正常，日志没有报WARN，基本就没问题。

以我们的情况为例，1T数据，没有限制网络流量的情况下，足足同步了30多小时，status才从UJ变为UN。

尾声：

查看集群状态

$CASSANDRA_HOME/bin/nodetool status

如果所有节点都变成UN，那么恭喜，新节点成功加入了。

接下来就是一些收尾工作了。

之前关闭了自动压缩，现在重新开启：

$CASSANDRA_HOME/bin/nodetool enableautocompaction

新增了节点，应该分担一部分数据压力，原节点数据量应该会减少，但是查看原节点磁盘使用量，发现并没有减少，需要手动清理一下：

$CASSANDRA_HOME/bin/nodetool cleanup

原节点每个都要执行一下，这个也比较费时，放后台跑着就行了。

总结：

虽然过程总遇到很多坑，但总结起来，解决办法无非做到以下几点

• 看日志，找错误、警告，并想办法解决掉
• 监控流量、进程，确保任务没有死掉
• 意志坚定、死磕到底

注意：

每次重来，一定要把新节点的数据目录清空，否则可能导致数据丢失、损坏。切记！