修复
如果一个节点在删除发生时处于宕机状态，而且离线的时间超过了为了当前这个表定义的宽限时间 gc_grace_seconds，那么当这个节点恢复上线时，它就会"复活"本应该已经删除的数据。Cassandra提供了多种逆熵机制来帮助环节这种不一致。
命令： nodetool repair <keyspace> {<table(s)>}
例如： nodetool repair hotel hotels_by_poi
限制修复范围
可以通过 -local 选项限制repair命令只在本地数据中心运行(也可以通过长选项 --in-local-dc 指定)。或者，可以通过 -dc<name>选项 (或 --in-dc<name>) 限制只在指定的数据中心运行这个命令
完全修复、增量修复和反合并
完成一个修复意味着修复时会检查一个节点中的所有SSTable，限制这种方式被称为完全修复。2.1版本引入了增量修复。利用增量修复，已经修复的数据会与尚未修复的数据分开。这个过程称为合并。
Cassandra会为各个SST able文件增加一些元数据来跟踪其修复状态。可以使用 tools/bin/sstablemetadata 工具查看修复时间。
2.2版本中增量修复已经称为默认的修复方式。如果想要请求完全修复，必须使用 -full 选项。
顺序和并行修复
顺序修复是指一次修复一个节点，而并行修复是同时修复包含相同数据的多个节点。顺序修复是2.1以前版本的默认做法。从2.2版本开始并行修复称为默认设置。
使用 -seq 选项启动一个顺序修复时，会在协调器节点和各个副本节点上生成一个快照，这些快照用来构造 Merkle 树。会在协调器节点和各个副本之间一次完成修复。在顺序修复期间，cassandra的动态 snitch 可以帮助保持性能。因为当前不参与修复的副本能够更快的响应请求，所以动态snitch往往会把请求路由到这些节点。
并行修复使用 -par 选项启动。现在并行修复中，所有副本都将同时参与修复，不需要快照。与顺序修复相比，并行修复对集群的负载要大得多，不过也能更快的完成修复。
分区器区级修复
在一个节点上运行修复时，默认情况下，Cassandra会修复这个节点作为副本存错的所有令牌区间。如果只有一个节点需要修复，这会很合适，例如一个节点宕机，正在准备上线。nodetool repair命令提供了 -pr 选项，允许只修复主令牌区间或者分区器区间。只要修复各个节点的主区间，整个环就能得到修复
子区间修复
即使使用了 -pr 选项，修复仍然是一个开销很大的操作，因为一个节点的主区间可能表示大量的数据，由于这个原因，cassandra支持将一个节点的令牌区间分解为较小的取快来完成修复。这个过程称为子区间修复。
要启动一个子区间修复操作，需要指定所修复区间的开始令牌 (-st) 和结束令牌 (-et)
$ nodetool repair -st <start token> -et <end token>
修复的最佳实践
在实际中，选择和执行适当的修复策略是维护Cassandra集群的比较困难的任务之一。
一、修复频率
要记住，应用观察到数据一致性取决于你使用的读写一致性级别，另外还取决于你使用的修复策略。如果想要使用不能保证直接一致性的读/写一致性级别，可能就需要做更频繁的修复。
二、修复调度
可以调度在应用不忙的时间完成修复，从而尽量减少修复对应用的影响。或者，可以在不能的开始时间对各个键空间和表使用子区间修复或分段修复来摊分这个过程。
三、需要修复的操作
不要忘记有些操作需要完全修复 (如改变一个集群的 snitch 或改变一个键空间的副本因子)
四、避免冲突的修复
Cassandra 不允许对一个给定的令牌区间同时完成多个修复，因为根据定义，修复涉及节点间的交互。由于这个原因，最好在集群以外的一个位置管理修复，而不要试图在各个几点上实现自动过程本地修复自己的区间。
在一共一个更健壮的修复状态机制 (例如，参加JIRA问题CASSANDRA-10302) 之前，可以使用nodetool netstats查看修复状态