最近一个月一直在做服务向janusgraph over cassandra迁移的工作. 最近加入的写入的能力. 从kafka中读取数据然后持续的更新. 这个功能带了一些问题.

首先错误出现在janusgraph OLAP任务中, spark一直失败在读取图数据上, 错误信息如下

15:40:25,248 ERROR Executor:91 - Exception in task 744.2 in stage 0.0 (TID 1445)
com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded, 1 failed)

显然数据读取失败了, 而且这不是一个超时失败, 而是读取错误, 难道cassandra崩溃了么,检查了一下nodetool status发现没什么问题.

看看cassandra的log, 发现了这样可以的行

ERROR [ReadStage-14] 2019-07-04 07:50:50,118 MessageDeliveryTask.java:76 - Scanned over 100001 tombstones during query 'SELECT * FROM dbdump_full_190605_20190625_082349.edgestore WHERE token(key) >= token(d000000216436200) AND token(key) <= 2956105463827404139 LIMIT 5000' (last scanned row partion key was ((d000000216436200), b81ec0ff7ffffe3b9c4d2148c22e673462001a)); query aborted

tomestones是什么呢, 为什么会导致query aborted呢. 查了一下发现cassandra是一款只写数据库, 删除操作实际上是追加写, 会添加一个表示此key删除的标志数据, 属于较tombtone(墓碑). 这个数据很难被清除, 因为必须所有被它删除的数据被清除后这个标志才能清除, 而默认的tomestone保留时间是10天! 如果某行数据更新特别频繁的话 , 可想而知会有很多的tombstone留在数据里. 等待compaction才能清除, 在写比较多的load下很难让tombstone刚好和被shadow的数据都出现在一个sstable里, 因此也不能删除tombstone.

1. 把nodetool compact替换成nodetool compact --split-output
2. 执行nodetool gabagecollect -g CELL
3. 降低tombstone保留的时间gc_grace_seconds, 默认是10天, 超过这个时间tombstone才会被清除, 方法是在cqlsh中执行alter table <table_name> with GC_GRACE_SECONDS = <timeout>;
4. 提升tombstone_failure_threshold, 默认是100000, 这个比较危险, 因为保留太多tombstone的话, 表明这个数据有很多冗余,而cassandra必须把同一个key的这些数据都读入内存, 有OOM的风险

也可以对单独的表进修修改, 比如

alter TABLE  dbdump_full_190605_20190625_082349.edgestore with compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4', 'tombstone_compaction_interval': '3600', 'tombstone_threshold': '0.001'};