You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@hbase.apache.org by mintao <mi...@163.com> on 2020/02/28 08:18:50 UTC

关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

大家好：
在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL to HFile的想法：
（1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
具体测试的环境和测试流程：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region， 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
测试结果：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region， 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
（2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（https://issues.apache.org/jira/browse/HBASE-23741），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制

回复： 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by mintao <mi...@163.com>.
（1）40s是从master真正开始split算起的，这个split时间是直接从完成所有wal的split时，master在日志里打印出的那条记录中得到的。另外我测试的时候直接kill -9 ，zk也很快就知道rs挂了，理论上来说需要达到session_timeout这么长的时间才能感知到吧？
（2）我测试的时候没有显式开启bounded功能，我后面再测试一下在没有配置split wal  to hfile时，开启bounded这个功能后的split时间。




在2020年3月2日 16:38，Guanghao Zhang<zg...@gmail.com> 写道：
这个慢也有可能是
hbase.split.writer.creation.bounded这个feature造成的，这个是为了解决HDFS同时写小文件过多可能导致卡住的问题，但是性能数据还需要确认下。Split
WAL to HFile这个功能，是默认开启了bounded这个feature的

张铎(Duo Zhang) <pa...@gmail.com> 于2020年3月2日周一 下午4:18写道：

我理解，kill -9之后zk是不会马上就知道rs挂了的吧，本来也需要等一段时间？所以那个40s，是从kill
-9开始算起，还是从master真正开始split开始算起？

mintao <mi...@163.com> 于2020年2月28日周五 下午5:06写道：

1.测试表只有1个cf；
2. hbase.split.writer.creation.bounded没有配置，但是我配置了
（1）hbase.regionserver.hlog.splitlog.writer.threads=20
（2）hbase.regionserver.wal.maxsplitters=10


| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制
在2020年2月28日 16:53，Guanghao Zhang<zg...@gmail.com> 写道：
表有几个CF呢? split log生成的文件个数等于 WAL个数 * region个数, 而split生成HFile的时候是WAL个数 *
region个数 * CF个数的, 在CF多的时候写出去的文件会比之前多.
另外还有一个问题是, hbase.split.writer.creation.bounded这个是否有开启?
split生成HFile是默认是用了bounded这个feature的

mintao <mi...@163.com> 于2020年2月28日周五 下午4:46写道：




我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制
在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
1. 可以贴下具体数据看看?
2. 目前还没有修复, 欢迎提PR

mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：

大家好：
在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
to HFile的想法：
（1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
具体测试的环境和测试流程：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
测试结果：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
（2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
https://issues.apache.org/jira/browse/HBASE-23741
），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制

Re: 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by Guanghao Zhang <zg...@gmail.com>.
这个慢也有可能是
hbase.split.writer.creation.bounded这个feature造成的，这个是为了解决HDFS同时写小文件过多可能导致卡住的问题，但是性能数据还需要确认下。Split
WAL to HFile这个功能，是默认开启了bounded这个feature的

张铎(Duo Zhang) <pa...@gmail.com> 于2020年3月2日周一 下午4:18写道：

> 我理解，kill -9之后zk是不会马上就知道rs挂了的吧，本来也需要等一段时间？所以那个40s，是从kill
> -9开始算起，还是从master真正开始split开始算起？
>
> mintao <mi...@163.com> 于2020年2月28日周五 下午5:06写道：
>
> > 1.测试表只有1个cf；
> > 2. hbase.split.writer.creation.bounded没有配置，但是我配置了
> > （1）hbase.regionserver.hlog.splitlog.writer.threads=20
> > （2）hbase.regionserver.wal.maxsplitters=10
> >
> >
> > | |
> > mintao
> > |
> > |
> > mintaoisjack@163.com
> > |
> > 签名由网易邮箱大师定制
> > 在2020年2月28日 16:53，Guanghao Zhang<zg...@gmail.com> 写道：
> > 表有几个CF呢? split log生成的文件个数等于 WAL个数 * region个数, 而split生成HFile的时候是WAL个数 *
> > region个数 * CF个数的, 在CF多的时候写出去的文件会比之前多.
> > 另外还有一个问题是, hbase.split.writer.creation.bounded这个是否有开启?
> > split生成HFile是默认是用了bounded这个feature的
> >
> > mintao <mi...@163.com> 于2020年2月28日周五 下午4:46写道：
> >
> >
> >
> >
> 我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。
> >
> >
> >
> >
> > | |
> > mintao
> > |
> > |
> > mintaoisjack@163.com
> > |
> > 签名由网易邮箱大师定制
> > 在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
> > 1. 可以贴下具体数据看看?
> > 2. 目前还没有修复, 欢迎提PR
> >
> > mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：
> >
> > 大家好：
> > 在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
> > to HFile的想法：
> > （1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
> > assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
> > 具体测试的环境和测试流程：
> > 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> > 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
> > 测试结果：
> > 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> > 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
> > 是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
> > （2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
> > https://issues.apache.org/jira/browse/HBASE-23741
> > ），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？
> >
> >
> >
> >
> > | |
> > mintao
> > |
> > |
> > mintaoisjack@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
>

Re: 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
我理解，kill -9之后zk是不会马上就知道rs挂了的吧，本来也需要等一段时间？所以那个40s，是从kill
-9开始算起，还是从master真正开始split开始算起？

mintao <mi...@163.com> 于2020年2月28日周五 下午5:06写道：

> 1.测试表只有1个cf；
> 2. hbase.split.writer.creation.bounded没有配置，但是我配置了
> （1）hbase.regionserver.hlog.splitlog.writer.threads=20
> （2）hbase.regionserver.wal.maxsplitters=10
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制
> 在2020年2月28日 16:53，Guanghao Zhang<zg...@gmail.com> 写道：
> 表有几个CF呢? split log生成的文件个数等于 WAL个数 * region个数, 而split生成HFile的时候是WAL个数 *
> region个数 * CF个数的, 在CF多的时候写出去的文件会比之前多.
> 另外还有一个问题是, hbase.split.writer.creation.bounded这个是否有开启?
> split生成HFile是默认是用了bounded这个feature的
>
> mintao <mi...@163.com> 于2020年2月28日周五 下午4:46写道：
>
>
>
> 我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。
>
>
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制
> 在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
> 1. 可以贴下具体数据看看?
> 2. 目前还没有修复, 欢迎提PR
>
> mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：
>
> 大家好：
> 在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
> to HFile的想法：
> （1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
> assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
> 具体测试的环境和测试流程：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
> 测试结果：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
> 是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
> （2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
> https://issues.apache.org/jira/browse/HBASE-23741
> ），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？
>
>
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制
>
>

回复： 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by mintao <mi...@163.com>.
1.测试表只有1个cf；
2. hbase.split.writer.creation.bounded没有配置，但是我配置了
（1）hbase.regionserver.hlog.splitlog.writer.threads=20
（2）hbase.regionserver.wal.maxsplitters=10


| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制
在2020年2月28日 16:53，Guanghao Zhang<zg...@gmail.com> 写道：
表有几个CF呢? split log生成的文件个数等于 WAL个数 * region个数, 而split生成HFile的时候是WAL个数 *
region个数 * CF个数的, 在CF多的时候写出去的文件会比之前多.
另外还有一个问题是, hbase.split.writer.creation.bounded这个是否有开启?
split生成HFile是默认是用了bounded这个feature的

mintao <mi...@163.com> 于2020年2月28日周五 下午4:46写道：


我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制
在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
1. 可以贴下具体数据看看?
2. 目前还没有修复, 欢迎提PR

mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：

大家好：
在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
to HFile的想法：
（1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
具体测试的环境和测试流程：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
测试结果：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
（2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
https://issues.apache.org/jira/browse/HBASE-23741
），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制

Re: 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by Guanghao Zhang <zg...@gmail.com>.
表有几个CF呢? split log生成的文件个数等于 WAL个数 * region个数, 而split生成HFile的时候是WAL个数 *
region个数 * CF个数的, 在CF多的时候写出去的文件会比之前多.
另外还有一个问题是, hbase.split.writer.creation.bounded这个是否有开启?
split生成HFile是默认是用了bounded这个feature的

mintao <mi...@163.com> 于2020年2月28日周五 下午4:46写道：

>
> 我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。
>
>
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制
> 在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
> 1. 可以贴下具体数据看看?
> 2. 目前还没有修复, 欢迎提PR
>
> mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：
>
> 大家好：
> 在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
> to HFile的想法：
> （1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
> assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
> 具体测试的环境和测试流程：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
> 测试结果：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
> 是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
> （2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
> https://issues.apache.org/jira/browse/HBASE-23741
> ），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？
>
>
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制
>

回复： 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by mintao <mi...@163.com>.
我大概测试了十来次，在wal的数据量为12GB左右，100个wal文件情况下，没有开启writeToHFile时，split平均需要40s，assign平均需要30s，开启writeToHFile之后，split平均需要54s，assign需要4s。




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制
在2020年2月28日 16:23，Guanghao Zhang<zg...@gmail.com> 写道：
1. 可以贴下具体数据看看?
2. 目前还没有修复, 欢迎提PR

mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：

大家好：
在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
to HFile的想法：
（1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
具体测试的环境和测试流程：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
测试结果：
测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
（2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
https://issues.apache.org/jira/browse/HBASE-23741
），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？




| |
mintao
|
|
mintaoisjack@163.com
|
签名由网易邮箱大师定制

Re: 关于HBase-23286 Improve MTTR: Split WAL to HFile的一些想法

Posted by Guanghao Zhang <zg...@gmail.com>.
1. 可以贴下具体数据看看?
2. 目前还没有修复, 欢迎提PR

mintao <mi...@163.com> 于2020年2月28日周五 下午4:19写道：

> 大家好：
> 在HBase社区上看到HBase-23286这个jira，这里我有一些关于HBase-23286 Improve MTTR: Split WAL
> to HFile的想法：
> （1）我自己拉了代码测试了一下，发现开启writeToHFile之后整体恢复时间是有所缩短，特别是region
> assgin消耗的时间，但是split阶段花费的时间还是有所增加了。
> 具体测试的环境和测试流程：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间。
> 测试结果：
> 测试环境是两个节点，每个节点2个regionserver，集群内总共300个region，故障RS上有77个region，
> 100个wal，每个wal大概120MB，测试过程是通过kill -9 故障RS宕掉之后，通过观察master日志来确定恢复服务的时间；
> 是不是我测试的过程中遗漏了什么步骤？跟jira上的测试结果有一些差异。
> （2）这个功能在社区中反映是存在一些问题的，比如说存在数据丢失（
> https://issues.apache.org/jira/browse/HBASE-23741
> ），这个bug是否已经修复了，我这边已经定位到问题，应该是跟sequenceId有关，我这边本地已经复现并修复了，是否可以将该修复提交到社区？
>
>
>
>
> | |
> mintao
> |
> |
> mintaoisjack@163.com
> |
> 签名由网易邮箱大师定制