内容简介：关于Cassandra中的删除和墓碑（六）
墓碑清除
只有在local_delete_time + gc_grace_seconds以后墓碑才会在压实的时候完全清除掉。记住，这是假定所有节点都在gc_grace_seconds时间内repair过了，以保证墓碑在所有节点上都正确分布，这是为了防止删除的数据再出现，上面已经说过了。
gc_grace_seconds参数是墓碑在磁盘上存在的最短时间。我们需要保证所有的副本都收到了这个删除操作，并且写入了墓碑，从而避免僵尸数据的问题。为了达到这个目的，我们唯一的方法就是全量repair。在gc_grace_seconds以后，墓碑最终会请清除，如果其中一个节点没有写入这个墓碑，我们就会进入上面描述的数据又出现的境地。TTL没有影响，因为没有节点可以保留数据而错过ttl，它是一个原子操作，数据和ttl是一条记录。任何有数据的节点都知道什么时候必须删除数据。
另外，为了删除数据和墓碑，还有一些安全守则需要Cassandra节点必须遵守。我们需要一行数据或者一个分区key的所有的片段数据以及墓碑都要在同一个压实中。假设一个压实操作包含1-4个文件，如果一些数据在文件5上面，墓碑被清除后，我们仍需要留下一个标记数据（译者注:墓碑）,表示文件5里的数据被清除了，否则文件5里的数据又会回来了（成为僵尸数据）。
这些条件有时候让删除墓碑成为一件很复杂的事情，它经常给Cassandra的使用者带来麻烦。墓碑不被清除意味着占用更多的磁盘，更慢的读，以及更多的repair工作，高概率的GC压力，更多的资源利用等等。当你的sstable的墓碑占到一个很高的的比率（90%的数据都是墓碑），读取一个值或者一段相关的数据会变的相当困难，存储的成本也越来越高。这些问题最终会导致磁盘空间耗尽。
很多使用情况下会导致数据删除（TTL或者delete操作），作为Cassandra的使用者我们必须克制，控制这些事情。
再次回到我们这个例子，我重启了这个节点在很多天以后（>10天，gc_grace_seconds的默认值）。Cassandra重新打开压实过的mb-14-big文件，它立马又进行了压实操作。
MacBook-Pro:tombstones alain$ grep ‘mb-14-big’ /Users/alain/.ccm/Cassa-3.7/node1/logs/system.log
DEBUG [SSTableBatchOpen:1] 2016-06-28 15:56:17,947 SSTableReader.java:482 – Opening /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big (0.103KiB)
DEBUG [CompactionExecutor:2] 2016-06-28 15:56:18,525 CompactionTask.java:150 – Compacting (166f61c0-3d38-11e6-bfe3-e9e451310a18) [/Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big-Data.db:level=0, ]
此时，gc_grace_seconds已经过去了，墓碑有条件被清除了，所以所有的墓碑都被清除了，最后表里没有任何数据了，数据目录最终也是空的：
MacBook-Pro:tombstones alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 0
drwxr-xr-x 3 alain staff 102 Jun 28 15:56 .
drwxr-xr-x 3 alain staff 102 Jun 16 20:25 ..
MacBook-Pro:tombstones alain$
如果墓碑在所有副本都都正确存在，我们就会有完全一致的删除操作，删除的数据就不会再出现。而且我们还可以释放一些磁盘空间，让其他数据的读变的更容易，尽管为了证明这个事情，我的例子有点傻，但最后这个表是完全变空了。
监控墓碑比率和到期时间
因为Cassandra的设计，当我们删除数据或者使用ttl的时候很正常的就产生了墓碑。当然这个是我们必须要控制的。
使用sstablemetadata我们可以指定一个sstable的墓碑占有率，以及一个大概的墓碑清除时间分布情况。
alain$ SSTablemetadata /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big-Data.db
—
Estimated droppable tombstones: 2.0
—
Estimated tombstone drop times:
1466154851: 2
1466156036: 1
1466156332: 1
—
上面的比率很可能是错误的，因为这个特别的状态，我们把所有的数据都清除了，在mb-14-big文件中，只剩下墓碑了，没有有用的数据。但是对于墓碑而言这个通常是显示sstable状态是否良好的一个很有用的指标。
同时，Cassandra为每个表提供了一个叫TombstoneScannedHistogram的统计值，可以通过jmx获取到。再说明一下，命令里scope=tombstones就是指表的名字。
org.apache.cassandra.metrics:type=Table,keyspace=tlp_lab,scope=tombstones,name=TombstoneScannedHistogram
这个值很有必要用监控 工具 监控起来，比如Graphite / Grafana, Datadog, New Relic等等。
上面的例子，在墓碑被压实清除之前，使用jconsole输出来是这样的：
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 关于Cassandra中的删除和墓碑（七）
- 关于Cassandra中的删除和墓碑（五）
- 关于Cassandra中的删除和墓碑（四）
- 关于Cassandra中的删除和墓碑（三）
- 关于Cassandra中的删除和墓碑（二）
- 关于Cassandra中的删除和墓碑（一）
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
