java OPENTSDB fsck修复程序不更正重复点

Question

我正在使用OPENTSDB，在查询时，我得到了以下信息：

net.opentsdb.core.IllegalDataException: Found out of order or duplicate data: cell=Cell([-35, 87], [0, 0, 0, 0, 0, 8, -34, 65]), delta=3541, prev cell=Cell([-35, 87], [0, 0, 0, 0, 0, 12, -82, 106]), last_delta=3541, in row=[KeyValue(key=[0, 8, -96, 81, -7, -77, 16, 0, 0, 1, 0, -73, 83, 0, 0, 3, 0, 47, 57, 0, 0, 69, 0, 44, 99, 0, 0, 71, 0, 48, 79, 0, 0, 75, 0, 47, -53, 0, 0, 76, 0, 13, -24, 0, 0, 77, 0, 114, 14, 0, 0, 85, 0, -16, -50], family="t", qualifier="\xDDW", value=[0, 0, 0, 0, 0, 12, -82, 106], timestamp=1375323607530), KeyValue(key=[0, 8, -96, 81, -7, -77, 16, 0, 0, 1, 0, -73, 83, 0, 0, 3, 0, 47, 57, 0, 0, 69, 0, 44, 99, 0, 0, 71, 0, 48, 79, 0, 0, 75, 0, 47, -53, 0, 0, 76, 0, 13, -24, 0, 0, 77, 0, 114, 14, 0, 0, 85, 0, -16, -50], family="t", qualifier=[-35, 87, -35, -41, -34, 103, -32, 7, -32, -57], value=[0, 0, 0, 0, 0, 8, -34, 65, 0, 0, 0, 0, 0, 1, -122, -123, 0, 0, 0, 0, 0, 3, -22, 23, 0, 0, 0, 0, 0, 13, -10, -32, 0, 0, 0, 0, 0, 10, -27, 6, 0], timestamp=1375323057833)] -- run an fsck.

我尝试过使用fsck--fix，但也就是说没有发现错误。 有没有办法： 1.除手动移除基准点外，解决此问题 2.了解发生了什么以及如何预防

谢谢

Answer 1

我无法让fsck修复我的副本，但将其添加到配置文件并重新启动OpenTSDB对我来说确实有效：

tsd.storage.fix_duplicates = true

这里找到了解决方案：https://github.com/OpenTSDB/opentsdb/issues/430

Answer 2

OpenTSDB是一个由HBase支持的非常特殊的时间序列数据库。tsdb中的数据必须按时间/日期顺序排列，不得重复。数据点的时间/日期顺序不符可能是由t采集器或系统主机上的过期系统时钟造成的。重复的数据通常是由人工通过API或TCP套接字传输造成的。你的例外情况显示第35号和第87号单元格一式两份。您是手动将此数据提交给TSDB，还是直接将其输入到HBase

要解决这个问题，您可以在尝试时使用“tsdb fsck”

“tsdb fsck修复”需要一个时间段、一个运算符和一个度量名称。如果修复程序没有找到错误，则说明您没有提供包含重复数据的时间段或度量名称

例如：

/usr/local/opentsdb/build/tsdb fsck fix 9d-ago sum http.hits config /usr/local/opentsdb/opentsdb.conf

从1.0版开始处理TSDB，在2014年夏天添加许多“fsck”功能之前，我想出了一个很酷的方法来破解“fsck”所有数据点。这个shell脚本快速列出所有指标，然后将其发送到tsdb，以fsck该指标的所有数据点：

#!/bin/bash
list=`/usr/local/opentsdb/build/tsdb uid grep ''  config /usr/local/opentsdb/opentsdb.conf | cut -d" " -f2 | cut -d ":" -f1`
for i in $list
do
    echo "Fixing metric $i" && /usr/local/opentsdb/build/tsdb fsck  fix 9d-ago sum $i  config /usr/local/opentsdb/opentsdb.conf &
done

在TSDB2.1中，执行fsck要容易得多。不幸的是，截至2014年8月24日，它尚未发布，只能通过“下一个”分支的代码控制签出来使用：

git clone https://github.com/OpenTSDB/opentsdb.git

cd opentsdb

git checkout next

bash ./build.sh

#Wait for it to compile

# To FSCK without altering the metrics

build/tsdb fsck full-scan threads=16

# To FSCK with resolving duplicate/to fix the metrics

build/tsdb fsck full-scan threads=16 fix resolve-duplicates compact

祝你好运

Answer 3

解决方案1：为了避免这种情况从一开始就发生，请在^{中将tsd.storage.fix_duplicates标志设置为true

---

解决方案2：如果您的Hbase（底层数据存储）中已经写入了重复的值，并且无法查询openTSDB，请使用fsck实用程序：在opentsdb/build/

特定查询：

 ./tsdb fsck  fix-all 1h-ago now sum <metric-name> tag1=val1

对于公制：

./tsdb fsck  threads=2  fix-all  resolve-duplicates 15d-ago sum <metric name>

完整表：Hbase的“tsdb”表中的所有数据（openTSDB存储数据的一个表）

./tsdb fsck  full-scan  threads=8  fix-all  resolve-duplicates  compact

有用的^{}标志：

• fix-all-设置所有修复标志，尝试一次修复所有问题。小心使用
• compact在修复期间压缩未压缩的行
• delete-bad-compacts删除看似已压缩但解析失败的列。如果一列解析正确，但值的最后一个字节未设置为0或1，则该列将被保留
• resolve-duplicates通过删除除最新或最旧数据点以外的所有数据点，启用重复数据点解析。还可以看到最后一次写入的胜利
• last-write-wins设置标志后，在解析重复项时删除除最近写入的数据点以外的所有数据点。如果配置值tsd.storage.fix_duplicates设置为true，则不管该值如何，都将保留最新的数据点。未设置最后写入将获胜
• full-scan扫描整个数据表。注意：这可能需要很长时间才能完成
• threads整数执行完全扫描时要使用的线程数。默认值是CPU核心数的两倍