磁盘块部分损坏造成hbase读取数据时checksum不通过引起读阻塞

现象:线上hbase集群,客户端写入时速度突然下降极为明显,并有抖动,同时上游kafka积压严重。
 
初步分析:
rs/datanode所在节点磁盘快部分损坏,磁盘损坏程度还未达到本地文件系统将改磁盘标记为不可用的程度(节点上使用fck为检测到异常,hdfs fsck /也为检测到异常),但是该节点的hbase rs读取数据时,基于本地读机制读取到了坏块上的数据,checksum校验不通过,报如下错误:
hbase: Compaction failed xxxxxx java.io.IOException: Could not seek StoreFileScanner xxxxx Caused by: java.io.IOException: Invalid HFile block magic: \x00\x00\x00\x00\x00\x00\x00\x00
 
仔细查看日志,发现hbase checksum不通过,回退使用了hdfs的checksum机制:
hbase: HBase checksum verification failed for file xxxx 。。。Retrying read with HDFS checksums turned on...
 
使用hdfs的checksum机制时,有些hbase checksum不通过的通过了,也有些没有通过:
hdfs: DFSClient Found Checksum error 
Unable to read checksum from meta file
 
初步结论:
hbase写入数据时导致compaction压缩,压缩时需要读取hfile,hfile读取时checksum不通过,引起了如上现象。
 
疑问:
hbase设置了本地读(dfs.client.read.shortcircuit = true), 且优先使用自身的checksum机制(hbase.regionserver.checksum.verify = true),自身不通过时使用hdfs的checksum。此时虽然本地磁盘块有部分损坏,造成有些文件block的checksum都不通过,但是hdfs有三副本机制,照道理说本地的副本的checksum都不通过时,可以读取到其它副本啊,为何会造成极为严重的写入性能下降?是客户端代码问题?还是hdfs本身机制是一个副本的checksum不通过时不会读取另外的副本?
 
相关参数:
hbase.regionserver.checksum.verify:
If set to true (the default), HBase verifies the checksums for hfile blocks. HBase writes checksums inline with the data when it writes out hfiles. HDFS (as of this writing) writes checksums to a separate file than the data file necessitating extra seeks. Setting this flag saves some on i/o. Checksum verification by HDFS will be internally disabled on hfile streams when this flag is set. If the hbase-checksum verification fails, we will switch back to using HDFS checksums (so do not disable HDFS checksums! And besides this feature applies to hfiles only, not to WALs). If this parameter is set to false, then hbase will not verify any checksums, instead it will depend on checksum verification being done in the HDFS client.

 
 
 
 
 
已邀请:

michaelli

赞同来自:

忘了更新了,问题已解决。
 
背后机制:
hbase读数据时,自身有一套机制检查数据的一致性,当hbase自身的数据一致性检查不通过时,会回退使用hdfs的数据一致性检查机制,hdfs本身有3副本,某个副本损坏造成一致性检查不通过时会读取其他副本并作一致性检查,只有3个副本都损坏时才会一致性检查失败,才会报错,客户端才会感知到。
 
此次事件中,我们这里只是入库速度慢了,不是不能入库,在磁盘有坏块时这是正常现象,客户端的程序日志没有报任何错误也验证了这个结论。只是刚才赶在了入库高峰期,加上入库的并行度不高,批量入库时才会积压严重。

要回复问题请先登录注册


中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群