hbase源码系列(六)HMaster启动过程

  这一章是server端开始的第一章,有兴趣的朋友先去看一下hbase的架构图,我专门从网上弄下来的。

  按照HMaster的run方法的注释,我们可以了解到它的启动过程会去做以下的动作。

 * <li>阻塞直到变成ActiveMaster
 * <li>结束初始化操作
 * <li>循环
 * <li>停止服务并执行清理操作* </ol>

  HMaster是没有单点问题是,因为它可以同时启动多个HMaster,然后通过zk的选举算法选出一个HMaster来。

  我们首先来看看这个阻塞直到变成ActiveMaster的过程吧。

  1、如果不是master的话,就一直睡,isActiveMaster的判断条件是,在zk当中没有master节点,如果没有就一直等待。master节点建立之后,就开始向Master冲刺了,先到先得。

  2、尝试着在master节点下面把自己的ServerName给加上去,如果加上去了,它就成为master了,成为master之后,就把自己从备份节点当中删除。

  3、如果没有成为master,把自己添加到备份节点,同时检查一下当前的master节点,如果是和自己一样,那就是出现异常了,明明是设置成功了,确说不成功,接下来它就会一直等待,等到master死掉。

  成为master之后的结束初始化操作,这才是重头戏啊,前面的都是小意思,实例化的代码我就补贴了,看着也没啥意思,就把这些属性贴出来吧,让大家认识认识。

 /** 专门负责master和hdfs交互的类  */
  private MasterFileSystem fileSystemManager;

  /** 专门用于管理Region Server的管理器  */
  ServerManager serverManager;

  /** 专门用于管理zk当中nodes的节点  */
  AssignmentManager assignmentManager;

  /** 负责负载均衡的类  */
  private LoadBalancer balancer;

  /** 负责读取在hdfs上面的表定义的类 */
  private TableDescriptors tableDescriptors;

  /** 表级别的分布式锁,专门负责监控模式的变化  */
  private TableLockManager tableLockManager;

   /** 负责监控表的备份 */
  private SnapshotManager snapshotManager;

  这些类都会被实例化,具体的顺序就不讲了,这个不是特别重要。开学啦,等到region server过来报道,还要记录一下在zk当中注册了的,但是没有在master这里报道的,不做处理。

    // 等待region server过来注册,至少要有一个启动了
    this.serverManager.waitForRegionServers(status);
    // 检查在zk当中注册了,但是没在master这里注册的server
    for (ServerName sn: this.regionServerTracker.getOnlineServers()) {
      if (!this.serverManager.isServerOnline(sn)
          && serverManager.checkAlreadySameHostPortAndRecordNewServer(
              sn, ServerLoad.EMPTY_SERVERLOAD)) {
        LOG.info("Registered server found up in zk but who has not yet "
          + "reported in: " + sn);
      }
    }

分配META表前的准备工作,Split Meta表的日志

  okay,下面是重头戏了,准备分配meta表了,先启动个计时器。

// 启动超时检查器了哦
if (!masterRecovery) {
    this.assignmentManager.startTimeOutMonitor();
}

   上代码,从日志文件里面找出来挂了的server,然后对这些server做处理。

  // 从WALs目录下找出挂了的机器
    Set<ServerName> previouslyFailedServers = this.fileSystemManager
        .getFailedServersFromLogFolders();
    // 删除之前运行的时候正在恢复的region,在zk的recovering-regions下所有的region节点一个不留
    this.fileSystemManager.removeStaleRecoveringRegionsFromZK(previouslyFailedServers);

    // 获取就的meta表的位置,如果在已经挂了的机器上
    ServerName oldMetaServerLocation = this.catalogTracker.getMetaLocation();
    //如果meta表在之前挂了的server上面,就需要把meta表的日志从日志文件里面单独拿出来
    if (oldMetaServerLocation != null && previouslyFailedServers.contains(oldMetaServerLocation)) {
      splitMetaLogBeforeAssignment(oldMetaServerLocation);
    }

  F3进入getFailedServersFromLogFolders方法。

     //遍历WALs下面的文件
        FileStatus[] logFolders = FSUtils.listStatus(this.fs, logsDirPath, null);//获取在线的server的集合
        Set<ServerName> onlineServers = ((HMaster) master).getServerManager().getOnlineServers().keySet();
        for (FileStatus status : logFolders) {
          String sn = status.getPath().getName();
          //如果目录名里面包含-splitting,就是正在split的日志
          if (sn.endsWith(HLog.SPLITTING_EXT)) {
            sn = sn.substring(0, sn.length() - HLog.SPLITTING_EXT.length());
          }
          //把字符串的机器名转换成ServerName
          ServerName serverName = ServerName.parseServerName(sn);
          //如果在线的机器里面不包括这个ServerName就认为它是挂了
          if (!onlineServers.contains(serverName)) {
            serverNames.add(serverName);
          } else {
            LOG.info("Log folder " + status.getPath() + " belongs to an existing region server");
          }
        }

  从代码上面看得出来,从WALs日志的目录下面找,目录名称里面就包括ServerName,取出来和在线的Server对比一下,把不在线的加到集合里面,最后返回。看来这个目录下都是出了问题的Server才会在这里混。

  我们接着回到上面的逻辑,查出来失败的Server之后,从zk当中把之前的Meta表所在的位置取出来,如果Meta表在这些挂了的Server里面,就糟糕了。。得启动恢复措施了。。。先把META表的日志从日志堆里找出来。我们进入splitMetaLogBeforeAssignment这个方法里面看看吧。

 private void splitMetaLogBeforeAssignment(ServerName currentMetaServer) throws IOException {
    //该参数默认为false
    if (this.distributedLogReplay) {
      // In log replay mode, we mark hbase:meta region as recovering in ZK
      Set<HRegionInfo> regions = new HashSet<HRegionInfo>();
      regions.add(HRegionInfo.FIRST_META_REGIONINFO);
      this.fileSystemManager.prepareLogReplay(currentMetaServer, regions);
    } else {
      // In recovered.edits mode: create recovered edits file for hbase:meta server
      this.fileSystemManager.splitMetaLog(currentMetaServer);
    }
  }

  可以看出来这里面有两种模式,分布式文件恢复模式,通过zk来恢复,还有一种是recovered.edit模式,通过创建recovered.edits文件来恢复。文件恢复是通过hbase.master.distributed.log.replay参数来设置,默认是false,走的recovered.edit模式。看得出来,这个函数是为恢复做准备工作的,如果是分布式模式,就执行prepareLogReplay准备日志恢复,否则就开始创建recovered.edits恢复文件。

  (a)prepareLogReplay方法当中,把HRegionInfo.FIRST_META_REGIONINFO这个region添加到了recovering-regions下面,置为恢复中的状态。

  (b)下面看看splitMetaLog吧,它是通过调用这个方法来执行split日志的,通过filter来过滤META或者非META表的日志,META表的日志以.meta结尾。

public void splitLog(final Set<ServerName> serverNames, PathFilter filter) throws IOException {
    long splitTime = 0, splitLogSize = 0;
    //修改WALs日志目录的名称,在需要分裂的目录的名称后面加上.splitting,准备分裂
    List<Path> logDirs = getLogDirs(serverNames);
    //把这些挂了的server记录到splitLogManager的deadWorkers的列表
    splitLogManager.handleDeadWorkers(serverNames);
    splitTime = EnvironmentEdgeManager.currentTimeMillis();
    //split日志
    splitLogSize = splitLogManager.splitLogDistributed(serverNames, logDirs, filter);
    splitTime = EnvironmentEdgeManager.currentTimeMillis() - splitTime;
    //记录split结果到统计数据当中
    if (this.metricsMasterFilesystem != null) {
      if (filter == META_FILTER) {
        this.metricsMasterFilesystem.addMetaWALSplit(splitTime, splitLogSize);
      } else {
        this.metricsMasterFilesystem.addSplit(splitTime, splitLogSize);
      }
    }
  }

  上面也带了不少注释了,不废话了,进splitLogDistributed里面瞅瞅吧。

public long splitLogDistributed(final Set<ServerName> serverNames, final List<Path> logDirs,
      PathFilter filter) throws IOException {//读取文件
    FileStatus[] logfiles = getFileList(logDirs, filter);long totalSize = 0;
    //任务跟踪器,一个batch包括N个任务,最后统计batch当中的总数
    TaskBatch batch = new TaskBatch();
    Boolean isMetaRecovery = (filter == null) ? null : false;
    for (FileStatus lf : logfiles) {
      totalSize += lf.getLen();
      //获得root后面的相对路径
      String pathToLog = FSUtils.removeRootPath(lf.getPath(), conf);
      //把任务插入到Split任务列表当中
      if (!enqueueSplitTask(pathToLog, batch)) {
        throw new IOException("duplicate log split scheduled for " + lf.getPath());
      }
    }
    //等待任务结束
    waitForSplittingCompletion(batch, status);
    if (filter == MasterFileSystem.META_FILTER)
      isMetaRecovery = true;
    }
    //清理recovering的状态,否则region server不让访问正在恢复当中的region
    this.removeRecoveringRegionsFromZK(serverNames, isMetaRecovery);

    if (batch.done != batch.installed) {
      //启动的任务和完成的任务不相等
      batch.isDead = true;
      String msg = "error or interrupted while splitting logs in "
        + logDirs + " Task = " + batch;
      throw new IOException(msg);
    }
    //最后清理日志
    for(Path logDir: logDirs){try {
        if (fs.exists(logDir) && !fs.delete(logDir, false)) {
        }
      } catch (IOException ioe) {
      }
    }
    status.markComplete(msg);
    return totalSize;
  }

  它的所有的文件的split文件都插入到一个split队列里面去,然后等待结束,这里面有点儿绕了,它是到zk的splitWALs节点下面为这个文件创建一个节点,不是原来的相对路径名,是URLEncoder.encode(s, "UTF-8")加密过的。

  呵呵,看到这里是不是要晕了呢,它是在zk里面创建一个节点,然后不干活,当然不是啦,在每个Region Server里面读会启动一个SplitLogWorker去负责处理这下面的日志。split处理过程在HLogSplitter.splitLogFile方法里面,具体不讲了,它会把恢复文件在region下面生成一个recovered.edits目录里面。

分配META表

  下面就开始指派Meta表的region啦。

void assignMeta(MonitoredTask status)
      throws InterruptedException, IOException, KeeperException {
    // Work on meta region
    int assigned = 0;
    ServerName logReplayFailedMetaServer = null;
    //在RegionStates里面状态状态,表名该region正在变化当中
    assignmentManager.getRegionStates().createRegionState(HRegionInfo.FIRST_META_REGIONINFO);
    //处理meta表第一个region,重新指派
    boolean rit = this.assignmentManager.processRegionInTransitionAndBlockUntilAssigned(HRegionInfo.FIRST_META_REGIONINFO);
    //这个应该是meta表,hbase:meta,等待它在zk当中可以被访问
    boolean metaRegionLocation = this.catalogTracker.verifyMetaRegionLocation(timeout);
    if (!metaRegionLocation) {
      assigned++;
      if (!rit) {
        // 没分配成功,又得回头再做一遍准备工作
        ServerName currentMetaServer = this.catalogTracker.getMetaLocation();
        if (currentMetaServer != null) {
          if (expireIfOnline(currentMetaServer)) {
            splitMetaLogBeforeAssignment(currentMetaServer);
            if (this.distributedLogReplay) {
              logReplayFailedMetaServer = currentMetaServer;
            }
          }
        }
        //删掉zk当中的meta表的位置,再分配
        assignmentManager.assignMeta();
      }
    } else {
      //指派了,就更新一下它的状态为online
      this.assignmentManager.regionOnline(HRegionInfo.FIRST_META_REGIONINFO,this.catalogTracker.getMetaLocation());
    }
    //在zk当中启用meta表
    enableMeta(TableName.META_TABLE_NAME);

    // 启动关机处理线程
    enableServerShutdownHandler(assigned != 0);

    if (logReplayFailedMetaServer != null) {
      // 这里不是再来一次,注意了啊,这个是分布式模式状态下要进行的一次meta表的日志split,
      //回头看一下这个变量啥时候赋值就知道了
      this.fileSystemManager.splitMetaLog(logReplayFailedMetaServer);
    }
  }

  历经千辛万苦跟踪到了这个方法里面,通过RPC,向随机抽出来的Region Server发送请求,让它打开region。

public RegionOpeningState sendRegionOpen(final ServerName server,
      HRegionInfo region, int versionOfOfflineNode, List<ServerName> favoredNodes)
              throws IOException {
    AdminService.BlockingInterface admin = getRsAdmin(server);
    if (admin == null) {return RegionOpeningState.FAILED_OPENING;
    }
    //构建openRegion请求,
    OpenRegionRequest request =
      RequestConverter.buildOpenRegionRequest(region, versionOfOfflineNode, favoredNodes);
    try {
      //调用指定的Region Server的openRegion方法
      OpenRegionResponse response = admin.openRegion(null, request);
      return ResponseConverter.getRegionOpeningState(response);
    } catch (ServiceException se) {
      throw ProtobufUtil.getRemoteException(se);
    }
  }

  这个工作完成, 如果是分布式文件恢复模式,还需要进行这个工作,recovered.edit模式之前已经干过了

//获取正在恢复的meta region server
Set<ServerName> previouslyFailedMetaRSs = getPreviouselyFailedMetaServersFromZK();
if (this.distributedLogReplay && (!previouslyFailedMetaRSs.isEmpty())) {
      previouslyFailedMetaRSs.addAll(previouslyFailedServers);
      this.fileSystemManager.splitMetaLog(previouslyFailedMetaRSs);
}

分配用户Region

  之后就是一些清理工作了,处理掉失败的server,修改一些不正确的region的状态,分配所有用户的region。

    // 已经恢复了meta表,我们现在要处理掉其它失败的server
    for (ServerName tmpServer : previouslyFailedServers) {
      this.serverManager.processDeadServer(tmpServer, true);
    }

    // 如果是failover的情况,就修复assignmentManager当中有问题的region状态,如果是新启动的,就分配所有的用户region
    this.assignmentManager.joinCluster();

  分配region的工作都是由assignmentManager来完成的,在joinCluster方法中的调用的processDeadServersAndRegionsInTransition的最后一句调用的assignAllUserRegions方法,隐藏得很深。。经过分配过的region,hmaster在启动的时候默认会沿用上一次的结果,就不再变动了,这个是由一个参数来维护的hbase.master.startup.retainassign,默认是true。分配用户region的方法和分配meta表的过程基本是一致的。

  至此HMaster的启动过程做的工作基本结束了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java帮帮-微信公众号-技术文章全总结

Activiti学习详解【面试+工作】

一:Activiti第一天 1:工作流的概念 ? 说明: 1) 假设:这两张图就是XX兄弟的请假流程图 2) 图的组成部分: A. 人物:范XX 冯X刚 王X军...

6065
来自专栏Java帮帮-微信公众号-技术文章全总结

Web-第三十天 Activiti工作流【悟空教程】

工作流(Workflow),就是“业务过程的部分或整体在计算机应用环境下的自动化”,它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的...

6713
来自专栏信安之路

HCTF2017的三个WriteUp

解决方法就是先 undefine 掉函数,再右键选择 Code,最后 Create function 就可以正常反编译了。

1070
来自专栏有趣的django

37.Django1.11.6文档

第一步 入门 检查版本 python -m django --version 创建第一个项目 django-admin startproject mysite ...

4538
来自专栏圣杰的专栏

ASP.NET Core 中断请求了解一下(翻译)

假设有一个耗时的Action,在浏览器发出请求返回响应之前,如果刷新了页面,对于浏览器(客户端)来说前一个请求就会被终止。而对于服务端来说,又是怎样呢?前一个请...

1193
来自专栏代码世界

AJAX

先了解JSON 什么是JSON? JSON 指的是JavaScript对象表示法(JavaScript Object Notation) JSON 是轻量级的文...

3947
来自专栏熊二哥

快速入门系列--MVC--05行为

    Action执行包含内容比较多,主要有同步/异步Action的概念和执行过程,Authorationfilter, ActionFiltor, Resu...

1977
来自专栏Ryan Miao

Spring cache简单使用guava cache

Spring cache简单使用 前言 spring有一套和各种缓存的集成方式。类似于sl4j,你可以选择log框架实现,也一样可以实现缓存实现,比如ehcac...

6287
来自专栏恰同学骚年

.NET单元测试的艺术-1.入门

开篇:最近在看Roy Osherove的《单元测试的艺术》一书,颇有收获。因此,将其记录下来,并分为四个部分分享成文,与各位Share。本篇作为入门,介绍了单元...

982
来自专栏熊二哥

快速入门系列--WebAPI--04在老版本MVC4下的调整

WebAPI是建立在MVC和WCF的基础上的,原来微软老是喜欢封装的很多,这次终于愿意将http编程模型的相关细节暴露给我们了。在之前的介绍中,基本上都基于.N...

2376

扫码关注云+社区