Hbase多master

时间 2019-11-13

标签 hbase master 栏目 Hadoop 繁體版

原文原文链接

单台master的配置html

hbase.master

master:60000

这是咱们一般配置的，这样就定义了master是的ip和端口。

可是当咱们须要配置多台master进行，咱们只须要提供端口，由于选择真正的master的事情会又zookeeper去处理。

多台master的配置

hbase.master.port

60000

将这个配置cp到其余备份master的服务器上。

假设如今架构

A：master、zookeeper、HRegionServer

B：backup-master、zookeeper、HRegionServer

在A上直接启动hbase-start.sh

在B上启动hbase-daemon.sh start master

这样咱们在A和B上都启动了master，不用担忧同时启动了2个，由于只有在A的master宕掉后，zookeeper才会切换B的master为主。

咱们看下端口

A为主

tcp 0 0 :::60000 master进程端口

tcp 0 0 :::60010 masterweb后台端口

B为从

tcp 0 0 :::60000 master进程端口

这里虽然B已经启动master，可是zookeeper已经判断网络中已经存在存活的master，因此分配B为从。

咱们如今宕掉A的master，来看看zookeeper是如何工做的。

zookeeper log：

2012-09-07 14:56:53,073 WARN org.apache.zookeeper.server.NIOServerCnxn: caught end of stream exception

EndOfStreamException: Unable to read additional data from client sessionid 0x1399f8281420000, likely client has closed socket

at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220)

at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:224)

at java.lang.Thread.run(Thread.java:662)

2012-09-07 14:56:53,074 INFO org.apache.zookeeper.server.NIOServerCnxn: Closed socket connection for client /192.168.1.149:56188 which had sessionid 0x1399f8281420000

2012-09-07 14:57:54,002 INFO org.apache.zookeeper.server.ZooKeeperServer: Expiring session 0x399f76c05b0003, timeout of 180000ms exceeded

2012-09-07 14:57:54,002 INFO org.apache.zookeeper.server.ZooKeeperServer: Expiring session 0x399f76c05b0005, timeout of 180000ms exceeded

2012-09-07 14:57:54,002 INFO org.apache.zookeeper.server.PrepRequestProcessor: Processed session termination for sessionid: 0x399f76c05b0003

2012-09-07 14:57:54,002 INFO org.apache.zookeeper.server.PrepRequestProcessor: Processed session termination for sessionid: 0x399f76c05b0005

2012-09-07 14:59:18,002 INFO org.apache.zookeeper.server.ZooKeeperServer: Expiring session 0x399f8287a20002, timeout of 180000ms exceeded

2012-09-07 14:59:18,002 INFO org.apache.zookeeper.server.PrepRequestProcessor: Processed session termination for sessionid: 0x399f8287a20002

2012-09-07 14:59:23,679 INFO org.apache.zookeeper.server.NIOServerCnxnFactory: Accepted socket connection from /192.168.1.253:34507

2012-09-07 14:59:23,680 INFO org.apache.zookeeper.server.ZooKeeperServer: Client attempting to establish new session at /192.168.1.253:34507

2012-09-07 14:59:23,690 INFO org.apache.zookeeper.server.ZooKeeperServer: Established session 0x1399f8281420004 with negotiated timeout 180000 for client /192.168.1.253:34507

2012-09-07 14:59:24,002 INFO org.apache.zookeeper.server.ZooKeeperServer: Expiring session 0x1399f8281420000, timeout of 180000ms exceeded

2012-09-07 14:59:24,002 INFO org.apache.zookeeper.server.PrepRequestProcessor: Processed session termination for sessionid: 0x1399f8281420000

当B切换成真master时，同时开启端口

tcp 0 0 :::60010

这时，B的master已经接管工做。

在上一篇关于HBase的文章中曾经讲述过HBase在分布式中的架构，这篇文章将会讲述HBase在分布式环境中是如何排除单点故障的(SPFO)，作一个小实验讲述HBase在分布式环境中的高可用性，亲眼看到一些现象，延伸一些思考的话题。java

先来回顾一下HBase主要部件：
   1.HBaseMaster
   2.HRegionServer
   3.HBase Client
   4.HBase Thrift Server
   5.HBase REST Serverweb

HBaseMaster
HMaster 负责给HRegionServer分配区域,而且负责对集群环境中的HReginServer进行负载均衡，HMaster还负责监控集群环境中的HReginServer的运行情况，若是某一台HReginServer down机，HBaseMaster将会把不可用的HReginServer来提供服务的HLog和表进行从新分配转交给其余HReginServer来提供，HBaseMaster还负责对数据和表进行管理，处理表结构和表中数据的变动，由于在 META 系统表中存储了全部的相关表信息。而且HMaster实现了ZooKeeper的Watcher接口能够和zookeeper集群交互。shell

HRegionServer
HReginServer负责处理用户的读和写的操做。HReginServer经过与HBaseMaster通讯获取本身须要服务的数据表，并向HMaster反馈本身的运行情况。当一个写的请求到来的时候，它首先会写到一个叫作HLog的write-ahead log中。HLog被缓存在内存中，称为Memcache，每个HStore只能有一个Memcache。当Memcache到达配置的大小之后，将会建立一个MapFile，将其写到磁盘中去。这将减小HReginServer的内存压力。当一块儿读取的请求到来的时候，HReginServer会先在Memcache中寻找该数据，当找不到的时候，才会去在MapFiles 中寻找。apache

HBase Client
HBase Client负责寻找提供需求数据的HReginServer。在这个过程当中，HBase Client将首先与HMaster通讯，找到ROOT区域。这个操做是Client和Master之间仅有的通讯操做。一旦ROOT区域被找到之后，Client就能够经过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。当定位到提供数据的HReginServer之后，Client就能够经过这个HReginServer找到须要的数据了。这些信息将会被Client缓存起来，当下次请求的时候，就不须要走上面的这个流程了。api

HBase服务接口
HBase Thrift Server和HBase REST Server是经过非Java程序对HBase进行访问的一种途径。
缓存

进入正题
服务器

先来看一个HBase集群的模拟环境，此环境中一共有4台机器，分别包含 zookeeper、HBaseMaster、HReginServer、HDSF 4个服务，为了展现失效转发的效果HBaseMaster、HReginServer各有2台，只是在一台机器上即运行了HBaseMaster，也运行了HReginServer。
注意，HBase的集群环境中HBaseMaster只有失效转发没有压力分载的功能，而HReginServer即提供失效转发也提供压力分载。网络

服务器清单以下：
    一、zookeeper               192.168.20.214
    二、HBaseMaster         192.168.20.213/192.168.20.215
    三、HReginServer       192.168.20.213/192.168.20.215
    四、HDSF             192.168.20.212session

整个模拟环境的架构如图所示：

注意，这里只是作了一个模拟环境，由于这个环境的重点是HBase，因此zookeeper和HDFS服务都是单台。

虽说在整个HBase的集群环境中只能有一个HMaster，但是在集群环境中HMaster能够启动多个，但真正使用到的HMaster Server只有一个，他不down掉的时候，其余启动的HMaster Server并不会工做，直到与ZooKeeper服务器判断与当前运行的HMaster通信超时，认为这个正在运行的HMaster服务器down掉了，Zookeeper才会去链接下一台HMaster Server。

简单来讲,若是运行中HMaster服务器down掉了，那么zookeeper会从列表中选择下一个HMaster 服务器进行访问，让他接管down掉的HMaster任务，换而言之，用Java客户端对HBase进行操做是经过ZooKeeper的，也就是说若是zookeeper集群中的节点全挂了那么HBase的集群也挂了。自己HBase并不存储中的任何数据真正的数据是保存在HDFS上，因此HBase的数据是一致的，可是HDFS文件系统挂了，HBase的集群也挂。

在一台HMaster失败后，客户端对HBase集群环境访问时，客户端先会经过zookeeper识别到HMaster运行异常，直到确认屡次后，才链接到下一个HMaster，此时，备份的HMaster服务才生效，在IDE环境中的效果，如图所示：

上图中能看见抛出的一些异常和name:javahttp://www.javabloger.com和name:javahttp://www.javabloger.com1的结果集，由于我在serv215机器上用killall java命令把 HMaster和HReginServer都关掉，而且马上用Java客户端对HBase的集群环境进行访问有异常抛出，可是retry到必定次数后查询出结果，前面已经说了访问HBase是经过zookeeper再和真正的数据打交道，也就是说zookeeper接管了一个standby 的 HMaster，让原先Standby的HMaster接替了失效的HMaster任务，而被接管的HBaseMaster再对HReginServer的任务进行分配，当 HReginServer失败后zookeeper会通知 HMaster对HReginServer的任务进行分配。这样充分的说明了HBase作到了实效转发的功能。
如图所示：

口水：
一、HBase的失效转发的效率比较慢了，不期望能在1-2秒切换和恢复完毕，也许是我暂时没有发现有什么参数能够提升失效转发和恢复过程的速度，未来会继续关注这个问题。
二、在官方网站上看见HBase0.89.20100924的版本有篇讲述关于数据同步的文章，我尝试了一下在一台机器上能够运行所谓的HBase虚拟集群环境，可是切换到多台机器的分布式环境中，单点失效转发的速度很慢比HBase0.20.6还要慢，我又检查了是否存在网络的问题，目前还没有找到正确的答案，对与HBase0.89.20100924 新版中的数据同步的原理，如图所示：(更多信息)

能够留言或者发邮件与我交流，个人联系方式是:njthnet # gmail.com