:59:58,099 INFO org.apache.hadoop.hbase.ipc.HBaseRpcMetrics: Initializing RPC Metrics with hostName=HMaster master java.lang.RuntimeException: Failed construction of Master: class org.apache.hadoop.hbase.master.HMaster at org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:1065) at org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster (HMaster.java:1079) Caused by: java.lang.ClassNotFoundException: org.apache.commons.configuration.Configuration <init>(HMaster.java:202) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
1、情况描述如题所示，hbase启动以后，HMaster进程启动了，几秒钟以后自动关闭，但是HRegionServer进程正常运行； 原因是，hdfs的默认端口号是8020，而我core-site.xml
2核2G云服务器首年95元，GPU云服务器低至9.93元/天，还有更多云产品低至0.1折…
之后通过CM重新启动后HBase服务，服务重启后发生如下两个错误，导致HBase集群无法正常恢复：（1）HMaster节点自动Active失败；（2）大量Region出现offline和RIT。 ? 1.2现象描述 HA HMaster节点启动了，过一段时间Active HBase Master节点自动失败（大概3~5分钟）。 默认值30 hbase.master.namespace.init.timeout：默认值300000ms hbase.master.wait.on.regionservers.mintostart：向HMaster
由于 hadoop 此时是 standby 状态，所以不能从 hadoop 上去读取 hbase.rootdir 中的文件，导致异常的发生。 解决问题：
按照HMaster的run方法的注释，我们可以了解到它的启动过程会去做以下的动作。 * 阻塞直到变成ActiveMaster * 结束初始化操作 * 循环 * 停止服务并执行清理操作* HMaster是没有单点问题是，因为它可以同时启动多个 HMaster，然后通过zk的选举算法选出一个HMaster来。 经过分配过的region，hmaster在启动的时候默认会沿用上一次的结果，就不再变动了，这个是由一个参数来维护的hbase.master.startup.retainassign，默认是true。 至此HMaster的启动过程做的工作基本结束了。
我在 hadoop001、hadoop002 和 hadoop003 节点上安装了 HBase 集群，其中 hadoop001 和 hadoop002 为 HMaster，hadoop002 和 hadoop003 为 HRegionServer，启动 HBase 后，发现 hadoop002 的 HMaster 和 HRegionServer 进程正常启动，hadoop003 上的 HRegionServer 正常启动，但 hadoop001 上的 HMaster 进程却没有启动，查看 hadoop001 节点上的 HBASE_HOME/logs/hbase-hadoop-master-hadoop001.log 日志文件发现如下报错： 2018-05-28 18:19:14,394 FATAL [hadoop001:16000.activeMasterManager] master.HMaster: Failed
HBase主要用ZooKeeper来实现HMaster选举与主备切换、系统容错、RootRegion管理、Region状态管理和分布式SplitWAL任务管理等。 HMaster选举与主备切换 HMaster选举与主备切换的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。 与此同时，HMaster 则会接收到 ZooKeeper 的 NodeDelete 通知，从而感知到某个节点断开，并立即开始容错工作。 HBase为什么不直接让HMaster来负责RegionServer的监控呢？ 如果HMaster直接通过心跳机制等来管理RegionServer的状态，随着集群越来越大，HMaster的管理负担会越来越重，另外它自身也有挂掉的可能，因此数据还需要持久化。
HMaster 仅仅维护 table 和 HRegion 的元数据信息，而 table 的元数据信息保存在 zookeeper 上，因此，HMaster 的负载很低。 HRegion Server 维护 HMaster 分配给他的 HRegion，并处理对这些 HRegion 的 IO 请求（client 访问 HBase 上的数据并不需要 HMaster 参与）。 Zookeeper 保证任何时候，集群中只有一个 HMaster，避免 HMaster 的单点故障。 存储所有 HRegion 的寻址入口。 注册，使 HMaster 可以随时感知到各个 HRegionServer 的健康状态。 HBase Client 使用 RPC 机制与 HMaster 和 HRegion Server 进行通信，但如何寻址呢？
HBase包含3个重要组件：Zookeeper、HMaster和HRegionServer。 2）实现HMaster主从节点的failover。 ZooKeeper为HBase集群提供协调服务，它管理着HMaster和HRegionServer的状态(available/alive等)，并且会在它们宕机时通知给HMaster，从而HMaster可以实现 （2）HMaster 主要用于监控和操作集群中的所有HRegionServer。 HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的MasterElection机制保证总有一个Master在运行 主要负责Table和Region的管理工作
1.2 HMaster Region 的分配，DDL（创建，删除表）操作均由 HMaster 负责处理。 Active HMaster 将心跳发送到 Zookeeper，非 Active HMaster 则侦听 Active HMaster 的故障通知。 非 Active HMaster 侦听 Active HMaster 是否出现故障，如果 Active HMaster 发生故障，那么一个非 Active HMaster 会变为 Active 状态。 然后，HMaster 将被告知 RegionServer 发生故障。 当 HMaster 检测到 RegionServer 崩溃时，HMaster 将发生崩溃的 RegionServer 中的 Region 重新分配给 Active RegionServer。
HBase基本进程 HMaster HMaster节点有如下功能： 1、为HRegionServer分配HRegion 2、负责HRegionServer的负载均衡 3、发现失效的HRegionServer ，HMaster与HRegionServer 启动时会向ZooKeeper注册，存储所有HRegion的寻址入口，实时监控HRegionserver的上线和下线信息。 并实时通知给HMaster，存储HBase的schema和table元数据，默认情况下，HBase 管理ZooKeeper 实例，Zookeeper的引入使得HMaster不再是单点故障。 一般情况下会启动两个HMaster，非Active的HMaster会定期的和Active HMaster通信以获取其最新状态，从而保证它是实时更新的，因而如果启动了多个HMaster反而增加了Active HMaster的负担。
HMaster、RegionServer容错 当HBase集群启动成功后，会在ZK注册如下znode： /hbase/master，其中包含当前活动（即赢得选举）的HMaster信息； /hbase/backup-masters 所有znode都是临时（ephemeral）节点，HMaster和RegionServer通过心跳维护这些znode。 活动HMaster对/hbase/rs路径下的znode注册监听，当有RegionServer失败时，心跳信号消失，超时过后其对应的znode被删除，HMaster即可感知到RegionServer下线 同理，所有热备HMaster都对/hbase/master节点注册监听，当前HMaster挂掉后，该znode被删除，即可触发重新选举HMaster。如下图所示。 HMaster会在ZK上注册/hbase/splitlog临时节点，其中存放有存活RegionServer与其应该处理的Region HLog的映射关系。
查看logs目录下的Master日志，发现有以下信息： 2012-02-01 14:41:52,867 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled <init>(MasterFileSystem.java:81) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java :342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:279) 2012-02-01 14:41:52,870 INFO org.apache.hadoop.hbase.master.HMaster: Aborting 2012-02-01 14:41:52,870 DEBUG org.apache.hadoop.hbase.master.HMaster
查看logs目录下的Master日志，发现有以下信息： 2012-02-01 14:41:52,867 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled <init>(MasterFileSystem.java:81) at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java :342) at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:279) 2012-02-01 14:41:52,870 INFO org.apache.hadoop.hbase.master.HMaster : Aborting 2012-02-01 14:41:52,870 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping service threads
(HMaster.java:1057) at org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java :844) at org.apache.hadoop.hbase.master.HMaster.access$500(HMaster.java:194) at org.apache.hadoop.hbase.master.HMaster $1.run(HMaster.java:1834) at java.lang.Thread.run(Thread.java:748) FATAL org.apache.hadoop.hbase.master.HMaster (HMaster.java:1057) at org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java :844) at org.apache.hadoop.hbase.master.HMaster.access$500(HMaster.java:194) at org.apache.hadoop.hbase.master.HMaster
---- 简单说明 相对应hadoop的高可用，HBase配置简单很多 HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。 配置HBase高可用，只需要启动两个HMaster，让Zookeeper自己去选择一个Master Acitve即可。 ---- 测试 启动hadoop，Zookeeper集群，HBase后 我们可以在对应HMaster的60010端口的网页查看状态 启动备用，实现高可用 hbase-daemon.sh start master 我们到备用HMaster的60010端口的网页查看状态 可以发现是standby的 同样，我们kill掉原来active的HMaster，可以发现standby的变为active。 再次启动kill掉的HMaster，可以发现变为standby ---- 扯淡 感觉HBase才是真正存储海量数据比较理想的工具，hdfs感觉只是个容器罢了。
由于HMaster订阅了server目录上的变更消息，当server目录下的文件出现新增或删除操作时，HMaster可以得到来自zookeeper的实时通知。 因此一旦HRegion Server上线，HMaster能马上得到消息。 HMaster工作机制 master上线 master启动进行以下步骤: 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它HMaster成为master。 因此HMaster下线短时间内对整个HBase集群没有影响。 从上线过程可以看到，HMaster保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来） 因此，一般HBase集群中总是有一个HMaster在提供服务，还有一个以上的‘HMaster’在等待时机抢占它的位置
HMaster监控这些节点以发现可用的region servers，并监控这些节点的服务器故障。 HMaster监控这些节点以发现可用的区域服务器，并监控这些节点的服务器故障。 活动HMaster将心跳发送到Zookeeper，非活动HMaster将监听活动HMaster故障的通知。 Inactive HMaster监听active HMaster故障，并且如果active HMaster故障时，inactive HMaster编程active状态。 HMaster将会被通知Region Server失败。HMaster将会被通知Region Server失败。 当HMaster确定RegionServer宕机时，HMaster重新分配宕机服务器的Region到活动的服务器。
组成部件说明 Client： 使用HBase RPC机制与HMaster和HRegionServer进行通信 Client与HMaster进行通信进行管理类操作 Client 与HRegionServer进行数据读写类操作 Zookeeper： Zookeeper Quorum存储-ROOT-表地址、HMaster地址 HRegionServer 把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况 Zookeeper避免HMaster单点问题 HMaster ： HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master在运行 主要负责Table和Region 当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的
HBase HMaster负责Region的分配及数据库的创建和删除等操作。 HBase的HMaster HMaster负责region的分配，数据库的创建和删除操作。 HMaster之间通过互相竞争创建ephemeral node进行Master选举。ZooKeeper会选出区中第一个创建成功的作为唯一一个活跃的HMaster。 不活跃的HMaster则监听活跃HMaster的状态，并在活跃HMaster发生故障下线之后重新选举，从而实现了HBase的高可用性。 不活跃的HMaster监听活跃HMaster的信息，并在起下线后重新选出活跃的HMaster进行服务。 HBase的第一次读写 HBase中有一个特殊的起目录作用的表格，称为META table。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
即时通信 IM
网站备案
对象存储
实时音视频
