IDEA2023.1.3破解,IDEA破解,IDEA 2023.1破解,最新IDEA激活码

九十三、HBase:WAL拆分

IDEA2023.1.3破解,IDEA破解,IDEA 2023.1破解,最新IDEA激活码

WAL拆分

RegionServer服务于许多区域。区域服务器中的所有区域共享相同活动的WAL文件。WAL文件中的每个编辑都包含有关它属于哪个区域的信息。当打开区域时,需要重播属于该区域的WAL文件中的编辑。因此,WAL文件中的编辑必须按区域分组,以便可以重播特定的集合以重新生成特定区域中的数据。按区域对WAL编辑进行分组的过程称为日志拆分。如果区域服务器出现故障,它是恢复数据的关键过程。

在群集启动时由HMaster完成日志拆分,或者在区域服务器关闭时由ServerShutdownHandler完成日志拆分。为保证一致性,受影响的区域在数据恢复之前不可用。所有WAL编辑都需要在给定区域再次可用之前恢复并重播。因此,受到日志拆分影响的区域在该过程完成之前不可用。

过程:日志分割,分步执行

新目录按以下模式命名:

1、 /hbase/WALs/,,目录被重新命名。重命名该目录非常重要,因为即使HMaster认为它已关闭,RegionServer仍可能启动并接受请求。如果RegionServer没有立即响应,也没有检测到它的ZooKeeper会话,HMaster可能会将其解释为RegionServer失败。重命名日志目录可确保现有的有效WAL文件仍然由活动但繁忙的RegionServer使用,而不会意外写入。新目录根据以下模式命名:

    /hbase/WALs/<host>,<port>,<startcode>-splitting       
这种重命名的目录的例子可能如下所示:
    /hbase/WALs/srv.example.com,60020,1254173957298-splitting

2、 每个日志文件都被拆分,每次一个。日志拆分器一次读取一个编辑项的日志文件,并将每个编辑条目放入对应于编辑区域的缓冲区中。同时,拆分器启动多个编写器线程。编写器线程选取相应的缓冲区,并将缓冲区中的编辑项写入临时恢复的编辑文件。临时编辑文件使用以下命名模式存储到磁盘:

    /hbase/<table_name>/<region_id>/recovered.edits/.temp
该文件用于存储此区域的WAL日志中的所有编辑。日志拆分完成后,.temp文件将被重命名为写入文件的第一个日志的序列ID。要确定是否所有编辑都已写入,将序列ID与写入HFile的上次编辑的序列进行比较。如果最后编辑的序列大于或等于文件名中包含的序列ID,则很明显,编辑文件中的所有写入操作都已完成。

3、 日志拆分完成后,每个受影响的区域将分配给RegionServer。打开该区域时,会检查recoverededed文件夹以找到恢复的编辑文件。如果存在任何这样的文件,则通过读取编辑并将其保存到MemStore来重播它们。在重放所有编辑文件后,MemStore的内容被写入磁盘(HFile),编辑文件被删除。

处理日志分割期间的错误

如果您将该hbase.hlog.split.skip.errors选项设置为true,则错误处理如下:

  • 拆分过程中遇到的任何错误都将被记录。
  • 有问题的WAL日志将被移到hbase rootdir下的.corrupt目录中,
  • WAL的处理将继续进行

如果该hbase.hlog.split.skip.errors选项设置为false默认值,则将传播该异常,并将该拆分记录为失败。

拆分崩溃的RegionServer的WAL时如何处理EOFException

如果在拆分日志时发生EOFException,即使hbase.hlog.split.skip.errors设置为false,拆分也会继续。在读取要拆分的文件集合中的最后一个日志时,可能会出现EOFException,因为RegionServer可能在崩溃时写入记录的过程中。

在日志分割期间的性能改进

WAL日志拆分和恢复可能需要大量资源并需要很长时间,具体取决于崩溃中涉及的RegionServer的数量和区域的大小。启用或禁用分布式日志分割是为了提高日志分割期间的性能。

启用或禁用分布式日志拆分

分布式日志处理自HBase 0.92开始默认启用。该设置由hbase.master.distributed.log.splitting属性控制,可以设置为true或false,但默认为true。

分布式日志拆分,分步执行

配置分布式日志拆分后,HMaster控制进程。HMaster在日志拆分过程中注册每个RegionServer,实际拆分日志的工作由RegionServers完成。分布式日志拆分中逐步描述的日志拆分的一般过程在这里仍然适用。

1、 如果启用分布式日志处理,则HMaster会在集群启动时创建拆分日志管理器实例。

 *  拆分日志管理器管理所有需要扫描和拆分的日志文件。
 *  拆分日志管理器将所有日志作为任务放入ZooKeeper splitWAL节点( hbase/splitWAL)中。
 *  您可以通过发出以下zkCli命令来查看splitWAL的内容。显示示例输出。
        ls /hbase/splitWAL
        [hdfs%3A%2F%2Fhost2.sample.com%3A56020%2Fhbase%2FWALs%2Fhost8.sample.com%2C57020%2C1340474893275-splitting%2Fhost8.sample.com%253A57020.1340474893900,
        hdfs%3A%2F%2Fhost2.sample.com%3A56020%2Fhbase%2FWALs%2Fhost3.sample.com%2C57020%2C1340474893299-splitting%2Fhost3.sample.com%253A57020.1340474893931, 
        hdfs%3A%2F%2Fhost2.sample.com%3A56020%2Fhbase%2FWALs%2Fhost4.sample.com%2C57020%2C1340474893287-splitting%2Fhost4.sample.com%253A57020.1340474893946]

    输出包含一些非ASCII字符。解码后,它看起来更简单:
        [hdfs://host2.sample.com:56020/hbase/WALs
        /host8.sample.com,57020,1340474893275-splitting
        /host8.sample.com%3A57020.1340474893900,
        hdfs://host2.sample.com:56020/hbase/WALs
        /host3.sample.com,57020,1340474893299-splitting
        /host3.sample.com%3A57020.1340474893931,
        hdfs://host2.sample.com:56020/hbase/WALs
        /host4.sample.com,57020,1340474893287-splitting 
        /host4.sample.com%3A57020.1340474893946]

    该列表表示要扫描和拆分的WAL文件名,这是日志拆分任务的列表。

2、 拆分日志管理器监视日志拆分任务和工作人员。拆分日志管理器负责以下正在进行的任务:

 *  一旦拆分日志管理器将所有任务发布到splitWAL znode,它就会监视这些任务节点并等待它们被处理。
 *  检查是否有任何排队等待的分组日志工人。如果发现没有响应的工作人员所要求的任务,它将重新提交这些任务。如果由于某些ZooKeeper异常而导致重新提交失败,则无法使用的工作者将再次排队等待重试。
 *  检查是否有未分配的任务。如果找到,它会创建一个短暂的重新扫描节点,以便通知每个拆分的日志工作者通过nodeChildrenChangedZooKeeper事件重新扫描未分配的任务。
 *  检查已分配但过期的任务。如果发现任何东西,它们会再次返回到TASK\_UNASSIGNED状态,以便它们可以重试。这些任务可能被分配给缓慢的工作人员,或者他们可能已经完成。这不是问题,因为日志拆分任务具有幂等性。换句话说,相同的日志拆分任务可以被处理多次而不会引起任何问题。
 *  拆分日志管理器不断监视HBase拆分日志节点。如果任何拆分日志任务节点数据发生更改,拆分日志管理器将检索节点数据。节点数据包含任务的当前状态。您可以使用该zkCli get命令来检索任务的当前状态。在下面的示例输出中,输出的第一行显示任务当前未分配。
        get /hbase/splitWAL/hdfs%3A%2F%2Fhost2.sample.com%3A56020%2Fhbase%2FWALs%2Fhost6.sample.com%2C57020%2C1340474893287-splitting%2Fhost6.sample.com%253A57020.1340474893945

        unassigned host2.sample.com:57000
        cZxid = 0×7115
        ctime = Sat Jun 23 11:13:40 PDT 2012 
        ...


    根据数据更改的任务的状态,拆分日志管理器将执行以下操作之一:

     *  如果任务未分配,请重新提交;
     *  如果任务被分配,则Heartbeat;
     *  如果任务失败,请重新提交或失败;
     *  如果任务完成时出现错误,请重新提交或失败;
     *  如果任务由于错误而无法完成,则请重新提交或失败;
     *  如果任务成功完成或失败,请将其删除。

> 任务失败的原因:该任务已被删除;该节点不再存在;日志状态管理器无法将任务的状态移至TASK\_UNASSIGNED;重新提交的次数超过了重新提交阈值。

3、 每个RegionServer的拆分日志工作器执行日志拆分任务。
每个RegionServer运行一个称为拆分日志工作器的守护进程线程,它负责拆分日志。守护程序线程在RegionServer启动时启动,并注册自己以观察HBase znode。如果任何splitWAL znode子项发生更改,它会通知睡眠工作器线程唤醒并获取更多任务。如果工作人员当前任务的节点数据发生更改,则工作人员将检查该任务是否已由其他工作人员执行。如果是这样,工作线程会停止当前任务的工作。工作人员不断监视splitWAL znode。出现新任务时,拆分日志工作人员将检索任务路径并检查每个任务路径,直到找到未声明的任务,并尝试声明该任务。如果声明成功,它将尝试执行该任务并state根据拆分结果更新任务的属性。此时,拆分日志工作者会扫描另一个无人认领的任务。拆分日志工作者如何接近任务

 *  它查询任务状态,只在任务处于TASK\_UNASSIGNED状态时采取行动。
 *  如果任务处于TASK\_UNASSIGNED状态,则工作人员尝试TASK\_OWNED自行设置状态。如果它没有设置状态,另一名工人将尝试抓住它。如果任务保持未分配,拆分日志管理器还会要求所有工作人员稍后重新扫描。
 *  如果工作人员成功地完成任务,它会尝试再次获取任务状态,以确保它真正异步获取它。同时,它启动一个拆分任务执行器来完成实际工作:

     *  获取HBase根文件夹,在根目录下创建一个临时文件夹,并将日志文件拆分为临时文件夹。
     *  如果拆分成功,任务执行程序将任务设置为状态TASK\_DONE。
     *  如果工作人员捕获到意外的IOException,则该任务将设置为状态TASK\_ERR。
     *  如果工作人员正在关闭,请将任务设置为状态TASK\_RESIGNED。
     *  如果任务是由另一名工作人员完成的,则只需登录即可。

4、 拆分日志管理器监视未完成的任务。拆分日志管理器在所有任务成功完成时返回。如果所有任务都完成并出现一些故障,则拆分日志管理器将引发异常,以便日志拆分可以重试。由于异步实现,在极少数情况下,拆分日志管理器会丢失一些已完成任务的跟踪。因此,它定期检查其任务图或ZooKeeper中剩余的未完成任务。如果没有找到,它会抛出一个异常,以便日志拆分可以马上重试,而不是挂在那里等待不会发生的事情。

文章永久链接:https://tech.souyunku.com/?p=12524

干货推荐


Warning: A non-numeric value encountered in /data/wangzhan/tech.souyunku.com.wp/wp-content/themes/dux/functions-theme.php on line 1154
赞(97) 打赏



未经允许不得转载:搜云库技术团队 » 九十三、HBase:WAL拆分

IDEA2023.1.3破解,IDEA破解,IDEA 2023.1破解,最新IDEA激活码
IDEA2023.1.3破解,IDEA破解,IDEA 2023.1破解,最新IDEA激活码

评论 抢沙发

大前端WP主题 更专业 更方便

联系我们联系我们

觉得文章有用就打赏一下文章作者

微信扫一扫打赏

微信扫一扫打赏


Fatal error: Uncaught Exception: Cache directory not writable. Comet Cache needs this directory please: `/data/wangzhan/tech.souyunku.com.wp/wp-content/cache/comet-cache/cache/https/tech-souyunku-com/index.q`. Set permissions to `755` or higher; `777` might be needed in some cases. in /data/wangzhan/tech.souyunku.com.wp/wp-content/plugins/comet-cache/src/includes/traits/Ac/ObUtils.php:367 Stack trace: #0 [internal function]: WebSharks\CometCache\Classes\AdvancedCache->outputBufferCallbackHandler() #1 /data/wangzhan/tech.souyunku.com.wp/wp-includes/functions.php(5109): ob_end_flush() #2 /data/wangzhan/tech.souyunku.com.wp/wp-includes/class-wp-hook.php(303): wp_ob_end_flush_all() #3 /data/wangzhan/tech.souyunku.com.wp/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters() #4 /data/wangzhan/tech.souyunku.com.wp/wp-includes/plugin.php(470): WP_Hook->do_action() #5 /data/wangzhan/tech.souyunku.com.wp/wp-includes/load.php(1097): do_action() #6 [internal function]: shutdown_action_hook() #7 {main} thrown in /data/wangzhan/tech.souyunku.com.wp/wp-content/plugins/comet-cache/src/includes/traits/Ac/ObUtils.php on line 367