Re: Re: Re: hbase集群单个region flush时间过长问题求助

2023-04-02 Thread Duo Zhang 
2.1 上的代码我记的不太清楚了，不过 region assign 相关 procedure 在 2.2 重新写了一遍，之前确实有 bug
很难搞定，常见的就是 region 不下线，或者一个 region 被 assign 到两台 RS 上，只能重启搞定。另外后来又在 2.3 上把存储
procedure 的部分重新实现了一遍，才算比较稳定。

所以 2.1 在大集群特别是有些过载的情况下跑 merge 确实有可能出 bug，hbck 的处理没啥问题，也只能这样搞。。。

邢*  于2023年3月31日周五 15:15写道：

>
> 感谢张老师的回复，我们后续对这张大表按照您的建议操作一下，再观察观察是否还有此类问题。然后我们之前也是由于region数量太多，手动操作过合并hbase集群的region，但是遇到了hole问题，想再麻烦您帮忙看一下。
>
>
>
> 1、问题描述:
> 手动合并两个region后出现hole，在用hbck2修复过程中出现region多分配问题。当时情况表现为hbase集群读写均无问题，但是在另外一个rs上出现了一个多余的region。此region在meta中无数据，hdfs上有目录但regioninfo缺失，且多余region对应的表compact和snapshot会失败，当时是把多余的region的rs上region迁移走，然后对rs进行了重启，重启完成后多余region消失了。
>
>
>
>
>
> 2、操作过程
>
> 合并region命令：
>
> merge_region
> 'sdhz_phone_info_realtime,363:2H9S49dd1UNDbnX+3vVj7g==,1627405790553.ba670bd86dc51211e50bf05995f9b8c5.','sdhz_phone_info_realtime,371:1xxhPgZ9BuzE29InP4QrWA==,1627405790553.3f8854e2e437b0469ef735b08e3abd05.'
>
>
>
> hole问题处理过程：
>
> 使用hbck2修复
>
> - 查询不一致原因：hbase hbck sdhz_phone_info_realtime
>
> - 修复元数据：hbase hbck -j hbase-hbck2-1.0.0-SNAPSHOT.jar
> addFsRegionsMissingInMeta default:sdhz_phone_info_realtime
>
> - 重启master
>
> - 重新分配region:hbase hbck -j hbase-hbck2-1.0.0-SNAPSHOT.jar assigns
> 23341c80a5bff8834bf1c6cdcc06
>
>
>
> 多余region问题修复过程：
>
> 1. 关闭线上balance
>
> 2. 依次move rs-13上的 region
>
> 3. 测试迁移后的region是否可用
>
> 4. 存在多余region的rs-13重启，重启完成后多余region消失
>
> 5. rs-13解除授权，机器下线
>
>
>
> 3、想得到解答的问题：
>
> 为什么手动合并region会出问题？
>
> hole问题使用hbck2修复的方式是否有误？
>
>
>
>
>
>
>
>
>

Re: Re: hbase集群单个region flush时间过长问题求助

2023-03-30 Thread Duo Zhang 
感觉还是 region 数量太多了，只有 14 台机器，4800 个 region 肯定集群状态就不太正常了。
这个表是有实时写入的数据吗？是否可以暂时停掉？比如找个晚上，新建一张表，1024 分片，读老表，把数据写到新的表里，然后把老表 disable 再
drop，把新表 rename 成老表。如果对 HBase 比较熟悉的话，可以尝试把老表 disable 掉，直接写 MR 任务读
snapshot，写 HFile 出来，然后往新表里 bulkload，速度能快不少
新表建议至少用 ConstantSizeRegionSplitPolicy(大概是这个名字，记不太清楚了)，甚至直接把 split disable
都行，就 14 台机器，1024 分表也足够了，再多意义也不太大。。。

邢*  于2023年3月30日周四 17:59写道：

>
> 感谢张老师的回复，由于我们这个大表快照的时间是近期才明显增长的，所以还是感觉hbase集群存在问题。我这边儿重新整理了下这个问题发生的全过程，辛苦张老师再帮忙看一下，再次感谢。
>
>
> 1、hbase集群信息：
> 3台虚拟机器：
> 作为hbase master，hdfs namenode，journal node，failovercontroller
> 14台物理机器：配置96c，376G，SSD盘
> 作为hbase region server，hdfs datanode
>
>
> hbase版本：2.1.9
> hadoop版本：hadoop-3.0.0-cdh-6.2.0
> 表：sdhz_user_info_realtime
> 大小：9.5TB
> 1个family
>
>
> 2、最近的操作：
> 2023年1月：sdhz_user_info_realtime表，region数量1024
> 2023年2月：因为sdhz_user_info_realtime表有很多脏数据，所以采用scan
> region的形式，一个一个region删除无用的列
> 2023年2月底：发现sdhz_user_info_realtime表的region数量暴增到4000多个，然后手动merge过region，造成hbase
> meta 空洞的问题，之后就放弃了merge，目前已经达到4800个region了
> 2023年3月16日夜间：sdhz_user_info_realtime表做snapshot超时，超时时间5分钟
> 2023年3月17日：将snapshot超时时间改为15分钟
> 2023年3月19日：snapshot再次超时
> 2023年3月20日：将snapshot超时时间改为60分钟，目前观察每次snapshot时间，大约半小时左右
>
>
> 3、想得到解答的问题：
> 为什么snapshot需要这么久？
> region的数量如何降下去？
>
>
>
>
> 4、在此期间对问题进行了跟踪排查，整理的信息如下：
>
>
>
>
> 在snapshot的过程中，时间花费在region的flush上，snapshot的校验上
> 在出现“Done waiting - online snapshot
> for”日志之前，一直在做flush操作，所有region大约花费总共20多分钟，每个region的flush的时间大约是10~20s，每次flush了几MB到几十MB的memstore，每个region
> server上大约340个region
> 在出现“Done waiting - online snapshot for”日志之后，开始对snapshot进行校验，移动等操作，花费了10分钟
>
>
> regionserver中发现了DFSClient的日志
> 2023-03-29 16:24:55,395 INFO org.apache.hadoop.hdfs.DFSClient: Could not
> complete
> /hbase/.hbase-snapshot/.tmp/sdhz_user_info_realtime_1680076952828/region-manifest.603b4d8028af279648af4bfaa3889fd0
> retrying...
>
>
>
>
> datanode中发现了日志：
>
> 增量块上报过程中，同一个块，要上报好几次，例如下面的日志，blk_1109695462_35954673这个块，怀疑dn向nn发送IBR的过程中，有失败然后进入pendingIBR重试的，想通过arthas检测IBR上报过程中putMissing的方法
>
>
> 2023-03-29 16:16:51,367 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-059fc182-f7cc-43bd-a0c3-2e1447f6650f,DISK,NORMAL][blk_1109695462_35954673,
> status: RECEIVING_BLOCK, delHint: null, blk_1109695456_35954667, status:
> RECEIVED_BLOCK, delHint: null],
> DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695459_35954670,
> status: RECEIVING_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,367 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-059fc182-f7cc-43bd-a0c3-2e1447f6650f,DISK,NORMAL][blk_1109695462_35954673,
> status: RECEIVING_BLOCK, delHint: null, blk_1109695456_35954667, status:
> RECEIVED_BLOCK, delHint: null],
> DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695459_35954670,
> status: RECEIVING_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,370 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695452_35954663,
> status: RECEIVED_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,372 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695459_35954670,
> status: RECEIVED_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,380 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-059fc182-f7cc-43bd-a0c3-2e1447f6650f,DISK,NORMAL][blk_1109695462_35954673,
> status: RECEIVED_BLOCK, delHint: null],
> DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695468_35954679,
> status: RECEIVING_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,552 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-059fc182-f7cc-43bd-a0c3-2e1447f6650f,DISK,NORMAL][blk_1109695391_35954602,
> status: RECEIVED_BLOCK, delHint: null]]
> 2023-03-29 16:16:51,574 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-059fc182-f7cc-43bd-a0c3-2e1447f6650f,DISK,NORMAL][blk_1109695455_35954666,
> status: RECEIVED_BLOCK, delHint: null]]
> 2023-03-29 16:16:52,094 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695468_35954679,
> status: RECEIVED_BLOCK, delHint: null]]
> 2023-03-29 16:16:53,164 DEBUG
> org.apache.hadoop.hdfs.server.datanode.IncrementalBlockReportManager: call
> blockReceivedAndDeleted:
> [DatanodeStorage[DS-b7afb119-fef7-429d-bf95-c7df181b7785,DISK,NORMAL][blk_1109695447_35954658,
> status: RECEIVED_BLOCK, delHint: