Region Server宕机,对整个集群的影响有哪些

最新推荐文章于 2022-11-13 23:32:19 发布
最新推荐文章于 2022-11-13 23:32:19 发布
阅读量1.5k 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： HBase
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/hljlzc2007/article/details/11152095
当HBase的Region Server宕机时，集群会进行一系列处理，包括在ZK中移除宕机节点、split HLog、重新分配Region。测试显示，Region Server的宕机仅影响其上的特定Region，不影响其他Region Server的正常工作，确保了集群的稳定性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

本文章主要描述Region Server宕机后, 集群的处理过程,以及测试结果.


Region Server宕机后,做了一下几步,

1.ZK发现并确认RS宕机, 在RS列表中删除宕机的节点,

2.Split日志文件HLog,将每一个日志文件分配给对应的Region

3.将Region分配给其他活着的Region Server

4.Region Server根据日志文件,RS发现HLog可用,将log持久化到HFile中

在HBase0.92版本以后,为了提高RS的性能,RS接受到log文件后,会新启动一个线程,单独处理Hlog文件,而不影响RS上原有的Region正常工作.


在这里由一点疑问,一张表对应多个Region,每个Region运行在不同的RegionServer上,那么当其中一个Region所在的RS宕机后,是否影响其他Region工作呢,对整个集群是否由影响,在这里,做了如下的测试.

在Hbase上建立一个user表, create 'user','info',很简单的表,默认user只有一个Region,为它指定5个Region,分别运行在RS1,2,3,4,5上.

 STARTKEY => '',                          ENDKEY => '-2016043150'    rs1
 STARTKEY => '-2016043150', ENDKEY => '-303030913'       rs2
 STARTKEY => '-303030913',   ENDKEY => '-554557441'       rs3
 STARTKEY => '-554557441',   ENDKEY => '2101159052'      rs4
 STARTKEY => '2101159052',  ENDKEY => ''                             rs5

启动两个线程thread4,thread5, 向rs4和rs5上分别插入大量数据,当数据量足够大时,停掉rs4,这时可以在控制上看到,thread5可以正常插入数据,thread4不工作,大概10秒之后,thread4重新工作,这时查看.META.表,可以看到rowkey在STARTKEY => '-554557441',   ENDKEY => '2101159052'的region已经被分配到其他的RS上.

由此可以看出,当RS宕机后,只对该RS内的Region有影响,不会对整个集群造成影响.



设计永不宕机的 K8s 集群的策略方法
wjianwei666的专栏
03-11 70
关键性能指标：• 控制平面：API Server P99延迟 < 500ms• 数据平面：Pod启动时间 < 5s（冷启动）• 网络：跨AZ延迟 < 10ms。
HBase学习五：运维排障之宕机恢复
qwerty1372431588的博客
01-23 479
HBase系统中主要有两类服务进程：Master进程以及RegionServer进程。Master主要负责集群管理调度，在实际生产线上并没有非常大的压力，因此发生软件层面故障的概率非常低。RegionServer主要负责用户的读写服务，进程中包含很多缓存组件以及与HDFS交互的组件，实际生产线上往往会有非常大的压力，进而造成的软件层面故障会比较多。
HBase RegionServer挂掉导致集群不可用问题
寂寞的博客
07-03 6220
生产中HBase RegionServer挂掉一个，整个集群却不可用了，排查下问题原因
HBase–RegionServer宕机恢复原理
范斐斐
08-25 2269
Region Server宕机总述 HBase一个很大的特色是扩展性极其友好，可以通过简单地加机器实现集群规模的线性扩展，而且机器的配置并不需要太好，通过大量廉价机器代替价格昂贵的高性能机器。但也正因为廉价机器，由于网络硬盘等各方面的原因，机器宕机的概率就会相对比较大。RegionServer作为HBase集群中实际的执行节点，不可避免地也会出现宕机。 宕机并不十分可怕，因为不会丢数据
HBase原理 | HBase RegionServer宕机数据恢复
Focus on Lakehouse
08-12 987
HBase采用类LSM的架构体系，数据写入并没有直接写入数据文件，而是会先写入缓存（Memstore），在满足一定条件下缓存数据再会异步刷新到硬盘。为了防止数据写入缓存之后不会因为Regi...
hbase异常regionserver宕机
wfp458113181wfp的专栏
09-15 1万+
1、直接崩溃，yi
region server发生故障后的处理过程
weixin_39950222的博客
09-14 1414
每个region server 会有一个Hlog对象，每次用户的请求写入在写入memstore之前都会先写入Hlog对象，当Hlog写满会被flush到磁盘 当region server 发生故障时，zookeeper不能和region server保持通信，则会删除该region server节点， master通过watcher感知到后，首先会处理Hlog，将其中不同region的log拆...
HBase集群整体宕机报告(2016.7.13)
Oozie123的博客
07-13 2024
情景与操作记录 10点50分左右，接到运维人员通知，HBase集群B所有节点宕机，以下记录恢复集群的所有操作。 登录HBase UI：http://192.168.3.146:60010/，无法登录 登录hbase shell 查看：>status 'simple' 5 dead servers 所有regionserver确实都挂掉，迅速拉起所有的regionserverservice hb
HBase基础入门|原理
路漫漫，水迢迢
09-26 1437
HBase是一个面向海量数据场景，分布式的、多版本、面向列的开源KV数据库。运行在HDFS的基础上，支持PB级别、百万列的数据存储。
2021SC@SDUSC HBase(八)项目代码分析——Region机制（五）之Region负载均衡
weixin_45865669的博客
11-11 1084
目录一、概述二、负载均衡四、总结 一、概述 在分布式系统中，负载均衡是一个非常重要的功能，HBase中Region是表按行方向切分的一个个数据区域，由RegionServer负责管理，并向外提供数据读写服务。如果一个RegionServer上的Region过多，那么该RegionServer对应的就会承担过多的读写等服务请求，也就有可能在高并发访问的情况下，造成服务器性能下降甚至宕机。如此，RegionServer间Region的动态负载均衡，也就成了HBase实现高性能读写请求访问的一个需要解决的问题。
HBase RegionServer挂掉问题分析
热门推荐
暗焰之珩的博客
08-16 2万+
HBase在使用中会遇到非常多的问题，最为常见的就是HBase regionserver挂掉（此文中简称regionserver为RS）， 而RS挂掉的原因各不相同。在本文中对遇到过的HBase RS挂掉的情况做一个简单的整理。 HBase集群预留内存不足 现象：HBase RS在起来1-2min后马上挂掉 日志为如下日志段的重复： Mon Aug 6 10:23:54 CST 20...
哪些原因可能会导致 HBase 的 RegionServer 宕机？
Shockang的博客
08-21 1237
HBase 系统中主要有两类服务进程： Master 进程以及 RegionServer 进程。 Master 主要负责集群管理调度，在实际生产线上并没有非常大的压力，因此发生软件层面故障的概率非常低。 RegionServer 主要负责用户的读写服务，进程中包含很多缓存组件以及与 HDFS 交互的组件，实际生产线上往往会有非常大的压力，进而造成的软件层面故障会比较多。
HBase 常见问题总结（一）
Shockang的博客
11-13 1597
问题一：业务表出现大量空Region 问题二：业务 HBase 客户端 RPC 连接异常关闭 问题三：单台 RegionServer 的 I/O 使用率一直为100%，HBase 集群请求量为0
解决hbase RegionServer频繁宕机的一些办法
十色花的博客
11-21 4575
HBase在使用中会遇到非常多的问题，最为常见的就是HBase regionserver挂掉（此文中简称regionserver为RS）， 而RS挂掉的原因各不相同。在本文中对遇到过的HBase RS挂掉的情况做一个简单的整理。 HBase集群预留内存不足 现象：HBase RS在起来1-2min后马上挂掉 日志为如下日志段的重复： Mon Aug  6 10:23:54 CST 2018...
避免regionServer宕机
修鹏的专栏
01-05 4801
因为regionserver 的管理信息主要记录在zookeeper，regionserver的宕机判断依据是session expired。ok 那么regionserver 和Zookeeper的session expired原因有哪些尼？ 1. 网络不好。 2. Java full GC， 这会block所有的线程。如果时间比较长，也会导致session expired
HMaster自动退出源于regionServer宕机
loloha007的专栏
12-18 5326
一大早起来关注我的小集群，发现HBase不好使了，弄得毫无头绪——只好重新查看守护进程jps 后 返现传说中的HMaster居然。。。不见了！ ————查看日志！果然： 2012-12-17 22:51:13,317 INFO org.apache.zookeeper.ClientCnxn: Unable to reconnect to ZooKeeper service, session 0
Hbase Region server经常挂掉
weixin_42751450的博客
11-27 605
Habse Region server经常挂掉 最近Hbase写入数据时，有2台Region server经常挂掉 可视化界面报错：该节点未连接至集群 没有ERROR报错，只有WARN，显示如下： WARN HeapMemoryManager heapOccupancyPercent 0.9565603 is above heap occupancy alarm watermark (0.95) 重启后，再次写入一会还是会挂掉，报错一样，不知道该如何解决 ...
Hbase region 某个regionserver挂掉后的处理
weixin_34341229的博客
11-27 314
ALTER TABLESPACE TB_USER_4K EXTEND(FILE '/data/vd5/TB_USER_4K.tbs' 10240)tail -f /var/cloud/logs/hbase/hbase-？？？-regionserver-d164.logtail -f  /var/cloud/logs/hbase/hbase-？？？？-regionserver-d198.log/...
根据以上回答中的内容，eureka.client.defaultZone中配置了本节点和对端节点会有什么影响
最新发布
07-03
<think>我们正在讨论Eureka客户端的配置，特别是`eureka.client.service-url.defaultZone`属性。这个属性用于指定Eureka客户端（可能是服务提供者或消费者）应该连接到的Eureka Server的地址。在多个Eureka Server节点的高可用部署中，这个属性尤为重要。根据用户的问题，他想了解在Eureka客户端配置中设置本节点和对端节点的影响。注意，这里用户可能有些混淆，因为`defaultZone`在客户端配置中通常是指向EurekaServer集群的地址列表，而不是客户端自身的地址（客户端自身的地址由`eureka.instance.*`配置控制）。###关键点解析1.**`defaultZone`的作用**：该属性用于指定Eureka客户端注册和获取服务发现的EurekaServer地址。客户端会向这些地址注册自己，并定期从这些地址获取服务注册表。 2. **配置多个节点**：在`defaultZone`中可以配置多个EurekaServer的地址（用逗号分隔），这样客户端可以同时向多个注册中心注册，并且当一个注册中心不可用时，可以尝试其他注册中心，从而实现高可用。3.**配置本节点**：在EurekaServer集群中，每个Server节点同时也是客户端（为了相互注册），所以在Server的配置中，`defaultZone`需要指向其他Server节点（而不是自己）。但是，对于普通的服务（非Eureka Server），则不需要配置自己的地址，只需要配置Eureka Server的地址。 ###具体影响-**对客户端（服务实例）**：-当配置了多个Eureka Server地址时，客户端会向所有配置的Server节点注册自己，并从这些节点获取服务注册表。-如果其中一个Server节点宕机，客户端会自动切换到其他可用的Server节点，从而保证服务的注册和发现不受影响。 -**对EurekaServer节点**：-每个EurekaServer节点在集群中需要配置其他节点的地址（不包括自己），这样它们可以相互注册，形成集群。当一个节点接收到注册信息时，它会将信息同步给集群中的其他节点。-如果在一个Server节点的`defaultZone`中配置了自己，那么它可能会尝试向自己注册，这通常是不必要的，并且可能导致一些不可预料的行为（如注册失败日志），但不影响集群的整体功能（因为其他节点会同步数据）。不过，官方建议在集群中不要将自己包含在`defaultZone`中。 ###配置示例在Eureka客户端（普通服务）的配置文件中：```properties#指向两个EurekaServer节点eureka.client.service-url.defaultZone=http://server1:8761/eureka/,http://server2:8762/eureka/``` 在EurekaServer节点的配置文件中（以节点1为例）： ```properties#节点1的配置eureka.client.service-url.defaultZone=http://server2:8762/eureka/#指向节点2，而不是自己``` ###注意事项1. **客户端重试机制**：当配置了多个EurekaServer地址时，客户端会按照配置的顺序尝试连接。如果第一个不可用，则尝试下一个。2.**注册表缓存**：客户端会缓存从EurekaServer获取的服务注册表，即使所有Server节点都暂时不可用，客户端仍然可以使用缓存的服务注册表（但新的服务实例注册和下线将无法及时更新）。3.**Server节点间的同步**：Server节点之间通过相互注册来实现数据同步。因此，每个Server节点必须配置其他节点的地址（且不能配置自己），这样才能形成集群。###引用支持根据用户提供的引用： -引用[1]展示了在配置文件中设置`eureka.client.service-url.defaultZone`的示例[^1]。-引用[2]和[3]说明了如何添加Eureka客户端和服务端的依赖[^2][^3]。-引用[4]和[5]提供了一些Eureka配置的细节，如缓存过期时间和应用名称的默认值[^4][^5]。 ###总结-对于普通服务（Eureka客户端），`defaultZone`应配置为所有可用的Eureka Server地址（多个地址用逗号分隔），以实现高可用。 -对于EurekaServer节点，`defaultZone`应配置为其他EurekaServer节点的地址（不包括自己），以实现集群同步。 这样配置后，整个系统将具有更高的可用性和容错能力。###相关问题1.如何配置Eureka客户端在多个注册中心之间的故障转移策略？ 2. Eureka Server节点间数据同步的机制和延迟问题如何解决？ 3.在Eureka客户端配置中，如何设置健康检查以更精确地控制服务实例的状态？[^1]:修改application-dev.properties中的eureka.client.service-url.default-zone[^2]:在pom.xml中添加Eureka客户端的依赖[^3]:创建一个普通的springboot项目，导入eureka依赖[^4]:springCloud注册中心之Eureka配置详解[^5]:Spring CloudEureka之常用配置解析</think>### Eureka客户端`defaultZone`配置详解 在Eureka客户端配置中，`eureka.client.service-url.defaultZone`参数控制客户端与Eureka Server集群的交互行为。配置本节点和对端节点的影响如下： #### 1. **配置本节点的影响** - **作用**：当客户端配置中包含本节点地址时，表示该节点既作为服务提供者也作为服务消费者 - **影响**： - 客户端会向本节点注册自身服务信息 - 客户端会从本节点拉取服务注册表 - 可能导致**循环依赖风险**（当本节点也是Eureka Server时） - **典型配置**： ```properties # 本节点既是Server也是Client的特殊场景 eureka.client.service-url.defaultZone=http://localhost:8761/eureka/ ``` #### 2. **配置对端节点的影响** - **作用**：建立客户端与集群其他节点的直接通信通道 - **影响**： - 实现**服务注册冗余**：客户端会向所有配置节点并行注册[^1] - 实现**注册表获取多源化**：从多个节点同时拉取服务列表 - 增强**故障容忍度**：当某个节点故障时自动切换到其他节点 - **推荐配置**： ```properties # 配置多个集群节点（逗号分隔） eureka.client.service-url.defaultZone=http://node1:8761/eureka/,http://node2:8762/eureka/ ``` #### 3. **混合配置的影响（本节点+对端节点）** | 配置场景 | 注册行为 | 服务发现行为 | 风险点 | |------------------------|----------------------------|--------------------------|------------------------| | 仅本节点 | 单点注册 | 单点获取注册表 | 单点故障导致服务不可用 | | 本节点+对端节点 | 多点注册 | 多点聚合注册表 | 可能产生注册冲突 | | 仅对端节点（推荐） | 向集群注册 | 从集群获取注册表 | 需确保网络连通性 | #### 4. **最佳实践建议** 1. **客户端配置原则**： ```properties # 只配置Eureka Server集群节点（不包含自身） eureka.client.service-url.defaultZone=http://eureka-node1:8761/eureka/,http://eureka-node2:8762/eureka/ ``` 2. **服务端特殊配置**： - Eureka Server节点自身作为客户端时，应配置其他节点地址： ```properties # 节点1配置指向节点2 eureka.client.service-url.defaultZone=http://node2:8762/eureka/ # 节点2配置指向节点1 eureka.client.service-url.defaultZone=http://node1:8761/eureka/ ``` 3. **高可用保障**： - 配置至少2个不同的Eureka节点地址 - 配合`eureka.client.availability-zones`实现区域感知[^5] - 设置重试机制： ```yaml eureka: client: region: us-east availability-zones: us-east: zone1,zone2 service-url: zone1: http://node1-zone1:8761/eureka/ zone2: http://node2-zone2:8762/eureka/ ``` #### 5. **关键参数关联** | 关联参数 | 作用说明 | 推荐值 | |------------------------------|-----------------------------------------|--------------------| | `eureka.instance.prefer-ip-address` | 优先使用IP注册替代主机名[^5] | true | | `eureka.client.registry-fetch-interval` | 注册表获取间隔 | 30s | | `eureka.client.service-url.availability-zones` | 多可用区配置支持 | 按实际区域划分 | | `eureka.server.enable-self-preservation` | 自我保护模式（服务端配置） | true（生产环境） | > **重要结论**：普通服务客户端**不应配置自身地址**，只需配置Eureka Server集群地址。Eureka Server节点作为客户端时，需配置其他Server节点地址实现交叉注册[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值