Hbase 日常运维

1.1监控Hbase运行状况

1.1.1操作系统

1.1.1.1IO

a.群集网络IO,磁盘IO,HDFS IO

IO越大说明文件读写操作越多。当IO突然增加时,有可能:1.compact队列较大,集群正在进行大量压缩操作。

2.正在执行mapreduce作业

可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据:

b.Io wait

磁盘IO对集群的影响比较大,如果io wait时间过长需检查系统或磁盘是否有异常。通常IO增加时io wait也会增加,现在FMS的机器正常情况io wait在50ms以下

跟主机相关的指标可以在CDH前台左上角先点“主机”选项卡然后选要查看的主机:

1.1.1.2CPU

如果CPU占用过高有可能是异常情况引起集群资源消耗,可以通过其他指标和日志来查看集群正在做什么。

1.1.1.3内存

1.1.2 JAVA

GC 情况

regionserver长时间GC会影响集群性能并且有可能会造成假死的情况

1.1.3重要的hbase指标

1.1.3.1region情况

需要检查

1.region的数量(总数和每台regionserver上的region数)

2.region的大小

如果发现异常可以通过手动merge region和手动分配region来调整

从CDH前台和master前台以及regionServer的前台都可以看到region数量,如master前台:

在region server前台可以看到storeFile大小:

1.1.3.2缓存命中率

缓存命中率对hbase的读有很大的影响,可以观察这个指标来调整blockcache的大小。

从regionserver web页面可以看到block cache的情况:

1.1.3.3读写请求数

通过读写请求数可以大概看出每台regionServer的压力,如果压力分布不均匀,应该检查regionServer上的region以及其它指标

master web上可以看到所以regionServer的读写请求数

regionServer上可以看到每个region的读写请求数

1.1.3.4压缩队列

压缩队列存放的是正在压缩的storefile,compact操作对hbase的读写影响较大

通过cdh的hbase图表库可以看到集群总的压缩队列大小:

可以通过CDH的hbase主页查询compact日志:

点击“压缩”进入:

1.1.3.5刷新队列

单个region的memstore写满(128M)或regionServer上所有region的memstore大小总合达到门限时会进行flush操作,flush操作会产生新的storeFile

同样可以通过CDH的hbase前台查看flush日志:

1.1.3.6rpc调用队列

没有及时处理的rpc操作会放入rpc操作队列,从rpc队列可以看出服务器处理请求的情况

1.1.3.7文件块保存在本地的百分比

datanode和regionserver一般都部署在同一台机器上,所以region server管理的region会优先存储在本地,以节省网络开销。如果block locality较低有可能是刚做过balance或刚重启,经过compact之后region的数据都会写到当前机器的datanode,block locality也会慢慢达到接近100:

1.1.3.8内存使用情况

内存使用情况,主要可以看used Heap和memstore的大小,如果usedHeadp一直超过80-85%以上是比较危险的

memstore很小或很大也不正常

从region Server的前台可以看到:

1.1.3.9slowHLogAppendCount

写HLog过慢(>1s)的操作次数,这个指标可以作为HDFS状态好坏的判断

在region Server前台查看:

1.1.4CDH检查日志

CDH有强大的系统事件和日志搜索功能,每一个服务(如:hadoop,hbase)的主页都提供了事件和告警的查询,日常运维除了CDH主页的告警外,需要查看这些事件以发现潜在的问题:

选择“事件搜索”中的标签(“警报”、“严重”)可以进入相关的事件日志,如“严重”:

1.2检查数据一致性以及修复方法

数据一致性是指:

1.每个region都被正确的分配到一台regionserver上,并且region的位置信息及状态都是正确的。

2.每个table都是完整的,每一个可能的rowkey 都可以对应到唯一的一个region.

1.2.1检查

hbase hbck

注:有时集群正在启动或region正在做split操作,会造成数据不一致

hbase hbck -details

加上–details会列出更详细的检查信息,包括所以正在进行的split任务

hbase hbck Table1 Table2

如果只想检查指定的表,可以在命令后面加上表名,这样可以节省操作时间

CDH

通过CDH提供的检查报告也可以看到hbck的结果,日常只需要看CDH hbck的报告即可:

选择“最近的Hbck结果”:

1.2.2修复

1.2.2.1局部的修复

如果出现数据不一致,修复时要最大限度的降低可能出现的风险,使用以下命令对region进行修复风险较低:

1.2.2.1.1hbase hbck -fixAssignments

修复region没有分配(unassigned),错误分配(incorrectly assigned)以及多次分配(multiply assigned)的问题

1.2.2.1.2hbase hbck -fixMeta

删除META表里有记录但HDFS里没有数据记录的region

添加HDFS里有数据但是META表里没有记录的region到META表

1.2.2.1.3hbase hbck -repairHoles

等价于:hbase hbck -fixAssignments -fixMeta -fixHdfsHoles

-fixHdfsHoles的作用:

如果rowkey出现空洞,即相邻的两个region的rowkey不连续,则使用这个参数会在HDFS里面创建一个新的region。创建新的region之后要使用-fixMeta和-fixAssignments参数来使用挂载这个region,所以一般和前两个参数一起使用

1.2.2.2Region重叠修复

进行以下操作非常危险,因为这些操作会修改文件系统,需要谨慎操作!

进行以下操作前先使用hbck –details查看详细问题,如果需要进行修复先停掉应用,如果执行以下命令时同时有数据操作可能会造成不可期的异常。

1.2.2.2.1hbase hbck -fixHdfsOrphans

将文件系统中的没有metadata文件(.regioninfo)的region目录加入到hbase中,即创建.regioninfo目录并将region分配到regionser

1.2.2.2.2hbase hbck -fixHdfsOverlaps

通过两种方式可以将rowkey有重叠的region合并:

1.merge:将重叠的region合并成一个大的region

2.sideline:将region重叠的部分去掉,并将重叠的数据先写入到临时文件,然后再导入进来。

如果重叠的数据很大,直接合并成一个大的region会产生大量的split和compact操作,可以通过以下参数控制region过大:

-maxMerge 合并重叠region的最大数量

-sidelineBigOverlaps 假如有大于maxMerge个数的 region重叠, 则采用sideline方式处理与其它region的重叠.

-maxOverlapsToSideline 如果用sideline方式处理重叠region,最多sideline n个region .

1.2.2.2.3hbase hbck -repair

以下命令的缩写:

hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile –sidelineBigOverlaps

可以指定表名:

hbase hbck -repair Table1 Table2

1.2.2.2.4hbase hbck -fixMetaOnly –fixAssignments

如果只有META表的region不一致,则可以使用这个命令修复

1.2.2.2.5hbase hbck –fixVersionFile

Hbase的数据文件启动时需要一个version file,如果这个文件丢失,可以用这个命令来新建一个,但是要保证hbck的版本和Hbase集群的版本是一样的

1.2.2.2.6hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

如果ROOT表和META表都出问题了Hbase无法启动,可以用这个命令来创建新的ROOT和META表。

这个命令的前提是Hbase已经关闭,执行时它会从hbase的home目录加载hbase的相关信息(.regioninfo),如果表的信息是完整的就会创建新的root和meta目录及数据

1.2.2.2.7hbase hbck –fixSplitParents

当region做split操作的时候,父region会被自动清除掉。但是有时候子region在父region被清除之前又做了split。造成有些延迟离线的父region存在于META表和HDFS中,但是没有部署,HBASE又不能清除他们。这种情况下可以使用此命令重置这些在META表中的region为在线状态并且没有split。然后就可以使用之前的修复命令把这个region修复

1.3手动merge region

进行操作前先将balancer关闭,操作完成后再打开balancer

经过一段时间的运行之后有可能会产生一些很小的region,需要定期检查这些region并将它们和相邻的region合并以减少系统的总region数,减少管理开销

合并方法:

1.找到需要合并的region的encoded name

2.进入hbase shell

3.执行merge_region ‘region1’,’region2’

1.4手动分配region

如果发现台regionServer资源占用特别高,可以检查这台regionserver上的region是否存在过多比较大的region,通过hbase shell将部分比较大的region分配给其他不是很忙的regions server:

move ‘regionId’,’serverName’

例:

move ‘54fca23d09a595bd3496cd0c9d6cae85’,’vmcnod05,60020,1390211132297’

1.5手动major_compact

进行操作前先将balancer关闭,操作完成后再打开balancer

选择一个系统比较空闲的时间手工major_compact,如果hbase更新不是太频繁,可以一个星期对所有表做一次 major_compact,这个可以在做完一次major_compact后,观看所有的storefile数量,如果storefile数量增加到 major_compact后的storefile的近二倍时,可以对所有表做一次major_compact,时间比较长,操作尽量避免高锋期

注:fms现在生产上开启了自动major_compact,不需要做手动major compact

1.6balance_switch

balance_switch true 打开balancer

balance_switch flase 关闭balancer

配置master是否执行平衡各个regionserver的region数量,当我们需要维护或者重启一个regionserver时,会关闭balancer,这样就使得region在regionserver上的分布不均,这个时候需要手工的开启balance。

1.7regionserver重启

graceful_stop.sh –restart –reload –debug nodename

进行操作前先将balancer关闭,操作完成后再打开balancer

这个操作是平滑的重启regionserver进程,对服务不会有影响,他会先将需要重启的regionserver上面的所有 region迁移到其它的服务器,然后重启,最后又会将之前的region迁移回来,但我们修改一个配置时,可以用这种方式重启每一台机子,对于hbase regionserver重启,不要直接kill进程,这样会造成在zookeeper.session.timeout这个时间长的中断,也不要通过 bin/hbase-daemon.sh stop regionserver去重启,如果运气不太好,-ROOT-或者.META.表在上面的话,所有的请求会全部失败

1.8regionserver关闭下线

bin/graceful_stop.sh nodename

进行操作前先将balancer关闭,操作完成后再打开balancer

和上面一样,系统会在关闭之前迁移所有region,然后stop进程。

1.9flush表

所有memstore刷新到hdfs,通常如果发现regionserver的内存使用过大,造成该机的 regionserver很多线程block,可以执行一下flush操作,这个操作会造成hbase的storefile数量剧增,应尽量避免这个操 作,还有一种情况,在hbase进行迁移的时候,如果选择拷贝文件方式,可以先停写入,然后flush所有表,拷贝文件

1.10Hbase迁移

1.10.1copytable方式

bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable –peer.adr=zookeeper1,zookeeper2,zookeeper3:/hbase ‘testtable’

这个操作需要添加hbase目录里的conf/mapred-site.xml,可以复制hadoop的过来。

1.10.2Export/Import

bin/hbase org.apache.hadoop.hbase.mapreduce.Export testtable /user/testtable [versions] [starttime] [stoptime]

bin/hbase org.apache.hadoop.hbase.mapreduce.Import testtable /user/testtable

1.10.3直接拷贝hdfs对应的文件

首先拷贝hdfs文件,如bin/hadoop distcp hdfs://srcnamenode:9000/hbase/testtable/ hdfs://distnamenode:9000/hbase/testtable/

然后在目的hbase上执行bin/hbase org.jruby.Main bin/add_table.rb /hbase/testtable

生成meta信息后,重启hbase

2Hadoop日常运维

2.1监控Hadoop运行状况

1.nameNode、ResourseManager内存(namenode要有足够内存)

2.DataNode和NodeManager运行状态

3.磁盘使用情况

4.服务器负载状态

2.2检查HDFS文件健康状况

命令:hadoop fsck

2.3开启垃圾箱(trash)功能

trash功能它默认是关闭的,开启后,被你删除的数据将会mv到操作用户目录的”.Trash”文件夹,可以配置超过多长时间,系统自动删除过期数据。这样一来,当操作失误的时候,可以把数据mv回来

3本项目场景下的hbase参数调整

时间: 2024-10-27 11:10:21

Hbase 日常运维的相关文章

hbase日常运维管用命令,region管理

1         Hbase日常运维 1.1       监控Hbase运行状况 1.1.1        操作系统 1.1.1.1 IO 群集网络IO,磁盘IO,HDFS IO IO越大说明文件读写操作越多.当IO突然增加时,有可能:1.compact队列较大,集群正在进行大量压缩操作. 2.正在执行mapreduce作业 可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据: Io wait 磁盘IO对集群的影响比较大,如果io wait时间过长需检查系统或磁盘是

hadoop日常运维与升级总结

日常运维 升级 问题处理方法 日常运维 进程管理 由于配置文件的更改,需要重启生效, 或者是进程自己因某种致命原因终止, 或者发现进程工作出现异常等情况下,需要进行手动进程的关闭或启动, 或者是增删节点过程中的需要, 进程的关闭与启动,使用 hadoop-daemon.sh start|stop datanode/namenode/journalnode/zkfc yarn-daemon.sh start|stop nodemanager/resourcemanager 检查进程是否完成关闭:

日常运维工作中如何确保你的linux操作系统安全

在现在这个世道中,Linux操作系统的安全是十分重要的.但是,你得知道怎么干.一个简单反恶意程序软件是远远不够的,你需要采取其它措施来协同工作.下面是日常运维工作中常用的几种Linux安全的策略方法. 1. 使用SELinux SELinux是用来对Linux进行安全加固的,有了它,用户和管理员们就可以对访问控制进行更多控制.SELinux为访问控制添加了更细的颗粒度控制.与仅可以指定谁可以读.写或执行一个文件的权限不同的是,SELinux可以让你指定谁可以删除链接.只能追加.移动一个文件之类的

zookeeper 用法和日常运维

本文以ZooKeeper3.4.3版本的官方指南为基础:http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html,补充一些作者运维实践中的要点,围绕ZK的部署和运维两个方面讲一些管理员需要知道的东西.本文并非一个ZK搭建的快速入门,关于这方面,可以查看<ZooKeeper快速搭建>. 1.部署 本章节主要讲述如何部署ZooKeeper,包括以下三部分的内容: 系统环境 集群模式的配置 单机模式的配置 系统环境和集群模式配置这两节内容大

mysql日常运维与参数调优

日常运维 DBA运维工作 日常 导数据,数据修改,表结构变更 加权限,问题处理 其它 数据库选型部署,设计,监控,备份,优化等 日常运维工作: 导数据及注意事项 数据修改及注意事项 表结构变更及注意事项 加权限及注意事项 问题处理,如数据库响应慢 导数据及注意事项 数据最终形式(csv,sql文本,还是直接导入某库中) 导数据方法(mysqldump,select into outfile,) 注意事项 导出为csv格式需要file权限,并且只能数据库本地导 避免锁库锁表(mysqldump使用

MySQL 日常运维业务账号权限的控制

在MySQL数据库日常运维中,对业务子账号的权限的统一控制十分必要. 业务上基本分为读账号和写账号两种账号,所以可以整理为固定的存储过程,让数据库自动生成对应的库的账号,随机密码.以及统一的读权限,写权限.(这里没有对 host进行过多的限制.只赋给通用的192.168.% .有兴趣的同学可以在存储过程加个参数,对host 控制) delimiter // set session sql_log_bin=OFF; drop PROCEDURE IF EXISTS `usercrt` // CRE

Openstack云计算项目实施其二(安装后日常运维)

5 安装后日常运维   运维基本的操作都在控制节点上的,较为方便的方式就是在openstack 的 dashboard(仪表盘)中进行,进入 dashboard 的方式就是直接在浏览器中输入控制节点的 IP 地址.(需要注意的是浏览器选择方面最好选择火狐浏览器或则谷歌浏览器,因为相对于 IE 浏览器而言,前面两个浏览器对于 openstack 的支持性要好,使用 IE 会在打开实例控制台时无法进入,出现"No vnc...."的错误信息) 用户名和密码放在控制节点/root 下,存放在

kafka知识体系-日常运维命令

本文主要讲解kafka日常运维的命令,包括topic管理.性能测试脚本. kafka版本0.10.0,安装步骤见大数据平台搭建-kafka集群的搭建 常用脚本 如下所有的命令均基于KAFKA_HOME=/wls/oracle/kafka ,服务器列表如下: 10.20.112.59 10.20.112.64 10.20.112.65 10.20.116.129 10.20.116.175 创建topic /wls/oracle/kafka/bin/kafka-topics.sh --zookee

Linux小课堂开课了(9)-Centos7日常运维管理

Centos7日常运维管理 1,查看系统配置,进程,I/O,网卡流量使用w可以查看系统的状态,当前时间,系统启动时间,登录用户,从哪个IP登录的,系统的负载值.使用uptime查看系统的负载值使用iptop,可以具体查看哪个进行使用的I/O较多,需要安装一下[[email protected] ~]# yum -y install iotop[[email protected] ~]# iotop使用cat /proc/cpuinfo查看系统配置使用vmstat可以查看CPU,内存,虚拟磁盘,交