Cassandra节点管理，cassandra节点
(1) 启动节点
添加新的节点被称为“引导”。
要引导一个节点，需要在配置文件storage-conf.xml中打开AutoBootstrap，并启动它。
如果您在配置文件storage-conf.xml中显式指定一个InitialToken，新的节点将引导到环上的指定位置。否则，它会选择一个Token，从磁盘空间使用最多的节点迁移一半的数据，也就是说，已经没有其他节点会引导到它的范围。
重要的事情需要注意：
1、你应该等待足够长的时间让集群中的所有节点通过Gossip消息来知道其它的正在引导的节点，在开始另一个节点的引导之前。新的节点将日志“自举”时，它才是安全的，大概是在启动2分钟以后。 （90秒的时间，以确保它获取其它节点精确的负载信息；30秒的时间，等待其他节点开始发送它插入在其将要承担的令牌环网的一部分的情况。）
2、和第1点相关，当采用自动选择Token的时候，一个节点每一时间仅仅能引导N节点，其中N是当前集群的节点数。如果您需要多将群集节点数扩大一倍的时候，您必须先为N个节点等待，直到完成您的群集大小2N个是前引导更多的节点。因此，如果您目前是5节点集群，你想添加7节点，引导5个节点并且让这5个节点启动完成，在启动其它2个节点之前。
3、作为一项安全措施，Cassandra不会自动删除源节点上被分出给新增节点的那一部分数据。在源节点上运行NodeProbe的cleanup方法（共享相同的Token区间的邻近节点），当你对新节点的启动满意并且新节点正常工作之后。如果你不这样做的话，旧数据仍会被计算在内，它不管该数据是否意见在新节点中加载啦，如果你在后续再次增加新的节点并且启动的时候将被抛弃。
4、当引导一个新的节点，在开始复制之前，现有节点必须划分Key的区间。这可能需要一段时间，所以要耐心等待。
5、在引导期间，一个节点将丢弃Thrift端口，并不会接受从NodeProbe的访问。
6、引导时，如果大量的数据被涉及有可能需要消耗几个小时。请参阅Streaming如何监测进展流。
如果您的EndpointSnitch配置正确，Cassandra是足够聪明的，它能从就近源节点（数据）传输数据。因此，新的节点并不需要和基础副本节点（该节点的数据被分一半给新增加的节点）在相同的数据中心，只要另一个副本与新的节点在同一个数据中心。
在使用Steam参数的情况下，引导进度能够使用NodeProbe监控。
在引导期间NodeProbe可能会报告说，新的节点不接收或发送任何Streams，这是因为发送节点首先需要将本地的需要复制给新加入节点的数据复制出来，上述信息能够从正在发送数据的节点上被监测到，通过“AntiCompacting ... AntiCompacted“日志信息。
(2) 加入节点
只需要选择合适的InitialToken，加入到现有集群即可。
如果您在配置文件storage-conf.xml中显式指定一个InitialToken，新的节点将引导到环上的指定位置。否则，它会选择一个Token，从磁盘空间使用最多的节点迁移一半的数据。
符合条件的数据会自动从现有节点流入到新加入的节点。
(3) 删除节点
你可以使用NodeProbe的decommission操作将一个活跃的节点退出当前集群，或者用NodeProbe的 removetoken操作来删除一个死亡的节点。这将原节点所负责的Token范围的迁移到其他节点负责，并有适当的数据复制。如果使用decommission操作，数据将从被退役节点Stream到其它节点。如果removetoken操作被使用的时候，数据将会从其余副本Stream到其它节点。
没有数据会自动删除，从被decommission的节点。所以如果你想把被退役的节点再次投入服务，在一个不同的Token环上，应该手动删除遗留的数据。
(4) 移动节点
NodeProbe move：移动目标节点到一个给定Token。迁移本质上是一种较方便的退役+引导
(5) 恢复节点
如果一个节点宕机之后又要恢复，通用的修复机制能够去处理任何不一致的数据。记得，如果一个节点宕机时长超过了你所配置的GCGraceSeconds (默认: 10 天)的时长，它可能就永久性的丢失了删除操作。除非你的应用没有执行删除操作，否则你应该删除掉该节点的数据目录，重新启动它，并且执行removetoken来删除掉GHE环上的旧数据。
如果一个节点彻底宕机了，那么你能做的事两件事：
1.（推荐的方法）弄一个备用节点，并且使用一个新的IP地址，将配置文件storage-conf.xml中AutoBootstrap设置为true。该配置能使备用节点在Cassandra集群中自动找到一个合适的位置。然后启动该节点，在启动期间，备用节点将不接受任何读请求，知道启动完成。在启动完成之后，运行nodetool 的removetoken 操作一次，并且应用死亡节点的Token到这个机器上，另外在集群中的每一个其它节点上执行Nodetool的cleanup操作一次。
2.通过在任何一个活跃节点上运行Nodetool的ring命令，你能够取得宕机节点的Token，除一个特别的场景之外，即在此期间又有节点宕机了。在这种情况下，你能够从活动节点System表（Table）中取得宕机节点的Token。
3.（可替换的方法）使用一个备用节点，使用和宕机节点相同的IP地址和Token，并且执行nodetool的repair操作。直到repair操作完成，客户端从这个节点所读取的数据有可能是老数据，当然我们一个更高的读一致性级别可以避免这个现象。
让你在其它每一个节点上运行nodetool 的cleanup操作的原因是去删除该节点记录下来的宕机节点的提示移交数据（Hinted Handoff writes）。
(6) 负载平衡
NodeProbe loadbalance：基本上也是一种较方便的退役+引导，而不是只告诉目标节点移动到环上，它将选择自己的位置与启动节点的时候相同。
Move和负载平衡操作能够被监控，通过NodeProbe的streams参数。
参考：http://wiki.apache.org/cassandra/Operations