需要多次jstack看看replicationSource线程卡在哪里，可能就是卡在某个循环里出不来了
zheng wang <18031...@qq.com> 于2020年7月22日周三 下午12:20写道： > 2.0.x 都有这个问题，2.1.0不确定，但很可能也有。 > > > > > ------------------ 原始邮件 ------------------ > 发件人: > "user-zh" > < > palomino...@gmail.com>; > 发送时间: 2020年7月22日(星期三) 中午12:09 > 收件人: "user-zh"<user-zh@hbase.apache.org>; > > 主题: Re: hbase 主备集群同时开启replication后WALs目录越积越大 > > > > 对，你看看卡在哪了到底 > > sudo rm -rf /* <leo9...@qq.com> 于2020年7月22日周三 上午11:54写道： > > > 机器已经重启过了，现在replication是没有延时的，昨天的异常场景 > > 现在没办法重现，只是重启过机器后，replication已经没有延时了，WALs > 还在持续增长，现在WALs的量从昨晚到现在已经增至670G， > > 还在持续增长，我们RegionServer是5台，RS的堆内存设置的是32G，按理说数据持续flush > > ，replication又没有延时，WALS应该及时被清理才对。我们的MajorCompact是手动触发的，目前禁用了Major > > > > > > > > > > > > > > ------------------&nbsp;原始邮件&nbsp;------------------ > > 发件人: > > > "user-zh" > > > < > > binli...@gmail.com&gt;; > > 发送时间:&nbsp;2020年7月22日(星期三) 中午11:38 > > 收件人:&nbsp;"user-zh"<user-zh@hbase.apache.org&gt;; > > > > 主题:&nbsp;Re: hbase 主备集群同时开启replication后WALs目录越积越大 > > > > > > > > 你把延迟严重的regionserver的jstack发出来看看replication主要耗时在那个阶段 > > > > sudo rm -rf /* <leo9...@qq.com&gt; 于2020年7月22日周三 上午11:32写道： > > > > &gt; 主备集群两边是通的，重启之前某一个RegionServer的replication队列一直积压，是卡在了一个WAls > > &gt; log上，这个数据包就一直卡着，不发。&amp;nbsp; > > &gt; 重启之后，主备集群两边的replication延时都没有了，但是WALs 依旧持续增加&amp;nbsp; > > &gt; > > &gt; > > &gt; > > &gt; > > &gt; > ------------------&amp;nbsp;原始邮件&amp;nbsp;------------------ > > &gt; 发件人: > > > &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > > "user-zh" > > > &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > > < > > &gt; palomino...@gmail.com&amp;gt;; > > &gt; 发送时间:&amp;nbsp;2020年7月22日(星期三) 中午11:25 > > &gt; 收件人:&amp;nbsp;"user-zh"<user-zh@hbase.apache.org > &amp;gt;; > > &gt; > > &gt; 主题:&amp;nbsp;Re: hbase 主备集群同时开启replication后WALs目录越积越大 > > &gt; > > &gt; > > &gt; > > &gt; 你看看为啥有一个region server的replication延迟很大？ > > &gt; 是写入有热点？还是对面集群不收？ > > &gt; > > &gt; sudo rm -rf /* <leo9...@qq.com&amp;gt; 于2020年7月22日周三 > 上午10:59写道： > > &gt; > > &gt; &amp;gt; hi: > > &gt; &amp;gt; &amp;amp;nbsp; &amp;amp;nbsp; > 我们线上集群的版本是cdh6.3.2-hbase2.1.0, > > &gt; &amp;gt; > > 主备双集群，备集群作为容灾集群。两集群开启了replication，且互相replication。最近发现，主集群的WALs目录持续增加， > > &gt; &amp;gt; > > &gt; > > > 十几天膨胀到十几个T，排查后发现某一个RegionServer节点的replication延迟很大，复制队列中积累了大量的数据，延迟卡在了十几天前的WALs > > &gt; &amp;gt; log，我们通过重建peeer,重启集群，这部分积累的WALs才 > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; > > > 被移动到oldWALs目录中，然后被清除了。重启完集群，replication的延时没了，但现在依然发现，WALs持续在增加，但此时replication的状态是正常的。 > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; > > > 与之对应的是备集群的oldWALs目录持续膨胀，不会被清除，实在不知道这样的问题该如何去分析，我们开启replication的过程参考的是官网的步骤。replication的相关参数，用的是默认的。 > > &gt; &amp;gt; 还麻烦张老师帮忙看一下，该怎么去分析这个问题。 > > > > > > > > -- > > *Best Regards,* > > &nbsp;lijin bin
