HBase集群服务端replication CallQueue被打满
一 问题列表及解决方案
问题1 服务端replication CallQueue被打满
regionserver日常信息如上图所示,很明显服务端的replication CallQueue被打满是因为
业务侧hbase.ipc.server.max.callqueue.size使用默认值1G,建议业务修改配置 <property> <name>hbase.ipc.server.max.callqueue.size</name> <value>5368709120</value> </property>
查看服务端监控证实replication call queue确实被打满
建议业务修改以下配置项
<property> <name>hbase.regionserver.replication.handler.count</name> <value>60</value> </property>
增加目标集群的replication请求处理的线程数,业务使用的是默认值3。
梳理业务逻辑发现源集群针对每个table都建立了peer,这样存在的问题有:
1 单个HLog被多次消费
replication时源集群会在zk上创建/hbase/replication/peers/peers目录,rs启动时在对应的 rs 的 peer 子 znode 下会添加文件,
addSource 时,rs 启动时把相应 HLog 文件名添加上 preLogRoll 时,把新滚动的 HLog 添加上 FailOver 时,把挂了的 rs 的 HLog 文件名和 checkpoint 移动到相应 rs 的znode上
单RS上存在多个表,WAL都在一个HLog中,表粒度的peer会导致,单个HLog被多个znode hold,只有最后一个peer消费完成后,才会删除。 另外多次seek hlog会占用源集群的cpu和磁盘io。 建议业务将表粒度的peer修改为集群力度,具体修改如下:
add_peer '1','zk:2181:/hbase','table1;table2'
相关文章
- 行存储(关系型数据库)与列存储(hbase,es聚合的doc_value)[通俗易懂]
- HBase数据操作
- 使用Python3操作HBase的两种方法
- Hbase(五) hbase内部原理详解大数据
- HBase学习之路 (九)HBase phoenix的使用详解大数据
- HBase学习之路 (五)MapReduce操作Hbase详解大数据
- HBase学习之路 (四)HBase的API操作详解大数据
- HBase学习之路 (三)HBase集群Shell操作详解大数据
- HBase深入学习(1)详解大数据
- Hadoop、Hbase、Hive、Spark分布式系统架构详解大数据
- 高可用Hadoop平台-HBase集群搭建详解大数据
- 用Java访问带有Kerberos认证的HBase详解编程语言
- 深入浅出:从HBase导入至MySQL(hbase导入mysql)
- HBase vs. Oracle: A Comparison of Two Leading Database Management Systems(hbase和oracle)
- Redis与Hbase:探索高效缓存和分布式数据库的最佳实践(redis与hbase)
- 比较:MYSQL与HBASE 数据库管理系统的异同(mysql与hbase)
- 使用HBase与Redis加快数据处理效率(hbaseredis)
- Hbase与Oracle数据库深入比较(hbase与oracle)