运营cassandra集群的新功能。拥有一个运行@ DCE v.2.1.15的1个DC和14节点生产集群。
系统日志显示了许多TS警告，如下所示，并且想知道这是否正常，或者是由于应用程序natur vs太低（默认TS警告级别= 5000），或者我们应该在每晚修复之间运行手动压缩（每个节点）在@周被修复一次），提高TS警告级别......
提示赞赏！
WARN [SharedPool-Worker-1] 2016-08-18 11：45：02,536 SliceQueryFilter.java:320 - 读取0个实时和6251个墓碑单元格 密钥的KeyspaceMetadata.CF_RecentIndex：3230303230305febd8fc98e0bf11e 5b870502699f4d249（参见tombstone_warn_threshold）。 5000列是 请求，slices = [ - ] WARN [SharedPool-Worker-3] 2016-08-18 11：45：02,548 SliceQueryFilter.java:320 - 读取0直播和6251 KeyspaceMetadata.CF_MessageFlagsIndex中的墓碑单元格用于键： 3230303230305febd8fc98e 0bf11e5b870502699f4d249（见 tombstone_warn_threshold）。要求1列，slice = [1-1：！] WARN [SharedPool-Worker-2] 2016-08-18 11：45：04,566 SliceQueryFilter.java:320 - 读取1个实时和1123个墓碑单元格 KeyspaceMetadata.CF_UIDIndex for key：3230303230315f299f8d3ae0c011e593 3d7775140b84c3（参见tombstone_warn_threshold）。 5000列是 请求，slices = [ - ] WARN [SharedPool-Worker-2] 2016-08-18 11：45：11,853 SliceQueryFilter.java:320 - 读取0直播和6251 KeyspaceMetadata.CF_RecentIndex中的墓碑单元格用于键： 3230303230305febd8fc98e0bf11e 5b870502699f4d249（见 tombstone_warn_threshold）。请求5000列，slice = [ - ] WARN [SharedPool-Worker-2] 2016-08-18 11：45：11,864 SliceQueryFilter.java:320 - 读取0个实时和6251个墓碑单元格 KeyspaceMetadata.CF_MessageFlagsIndex for key：3230303230305febd8fc98e 0bf11e5b870502699f4d249（参见tombstone_warn_threshold）。 1列是 请求，slices = [1-1：！] WARN [SharedPool-Worker-1] 2016-08-18 11：46：09,624 SliceQueryFilter.java:320 - 阅读2直播和2537 KeyspaceMetadata.CF_TimeIndex中的逻辑删除单元格用于键： 3230303030385ffebcbd200d9411e6b 9750c94c36d1038（见 tombstone_warn_threshold）。请求5000列，slice = [ - ] WARN [SharedPool-Worker-3] 2016-08-18 11：47：31,434 SliceQueryFilter.java:320 - 读取2个实时和2544个墓碑单元格 密钥的KeyspaceMetadata.CF_TimeIndex：3230303030345f6b87b24afbe111e5b f7f828e02f15dd6（参见tombstone_warn_threshold）。 5000列是 请求，slices = [ - ] WARN [SharedPool-Worker-1] 2016-08-18 11：49：13,870 SliceQueryFilter.java:320 - 阅读3直播和2540 KeyspaceMetadata.CF_TimeIndex中的逻辑删除单元格用于键： 3230303030355f533d997cfbdf11e59 85390948f56b8a7（见 tombstone_warn_threshold）。请求5000列，slice = [ - ]
答案 0 :(得分：0)
Hai steffen请通过你的opscenter，看看有多少表的Ts超过5000，如果no.of表少，在这些特定的表上手动压缩将是一个很好的解决方案，正如你提到你正在修复一次一周我会建议检查密钥空间的数据模型，为什么它导致高的TS。 如果你没有使用Opscenter，你可以查看墓碑号 sstable2json full_path | grep \＆＃34; t \＆＃34; | wc -l </ p>