排除和处理数据库热点问题
1.现象:10.22.33.41机器频繁出现告警,每20分钟一次,可以复现
现后台登录10.22.33.41机器,使用top c 命令定位到cpu高的进程,发现该进程就hbase相关的
登录HD集群的WebUI界面,选hbase集群
Hbase->实例 ->找到cup告警的实例 ->进入该实例
RegionServer CPU统计 -> 每隔段时间都会有cpu过高的情况
2.排查
HMaster WebUI(主) ->Region Servers -> 看Num. Regions数量是否均衡
Regions -> Request metris -> Read Request Count
这步先把下图数据拷贝到一份Excel,等cpu高峰之后再拷贝一份,做对比,定位高峰比平峰哪些表读写请求增长快
以上步骤定位到HBASE_TPI该表导致的10.22.33.41 cup过高
通过表名再定位HBASE_TPI表对应的Region
Home -》搜索表名HBASE_TPI -> 复制Region名称出来备用
HBASE_TPI,200a2857cd2e162b8af5298a21e5994e,1710731327389.045aa82b47f469698792160419d6aaab.
HBASE_TPI,1710731327389.f206ab4614748c717b24c05b845f85e6.
先把region先移动到其他实例,观察10.22.33.41 cup是否降下来, 并观察10.22.9.4,10.22.9.6节点cpu是否明显上升, 确认该表HBASE_TPI导致cup过高
Hbase shell执行移动region命令:
move ‘045aa82b47f469698792160419d6aaab’,‘tpi04,21302,1701846496478’
move ‘f206ab4614748c717b24c05b845f85e6’,‘tpi06,21302,1692893131315’
3.方案
临时方案:切分热点region
Hbase shell执行切分region命令,会把原先1个region切分为2个region,切分完成后再执行合并的动作, 可以暂时缓解region热点问题
split ‘045aa82b47f469698792160419d6aaab’
split ‘f206ab4614748c717b24c05b845f85e6’
split ‘0d783993a76bdd826a374e11a4d3248a’
major_compact ‘HBASE_TPI’
再查看HBASE_TPI region是否均衡
最终方案:删除该表HBASE_TPI,重建表并指定预分区为当前分区的3倍
4.重启regionserver(看某个regionserver是否读写明显超其他regionserve,如有该情况可重启单个regionserver节点)
Hbase -> 实例 -> 分别进入每个 RegionServer -> 单个RegionServer读写请求次数
重启regionserver节点过程
勾选节点 ->更多 ->重启
推荐阅读
-
解释 MySQL 执行原理、逻辑分层和更改数据库处理引擎
-
基于 NFC 的无线电池管理 BMS - ● 主动读取内部传感器:利用 NFC 技术,BMS 能够主动读取内部传感器的数据 [... 考虑车辆外使用案例中的空闲状态场景:NFC 技术可用于处理闲置状态下的电池组读取,例如在第二次生命转移期间进行存储。 主动诊断读取:在邻近系统中部署了 BMS 的情况下,使用 NFC 技术进行主动诊断读取。 (ii) 系统结构 系统架构如图所示,在建立安全通道之前,需要对设备进行身份验证。数据链路通信层由 NDEF 记录处理,而数据存储可以是离线的,也可以是数据库中的在线存储。活动和空闲状态的诊断读数取决于设备和数据方向,需要与外部 NFC 阅读器进行通信。软件架构分为三层,包括硬件抽象层(HAL)、中间层(中间件)和应用层。HAL 处理硬件驱动组件,中间件执行设备验证,而应用层则由开发人员根据安全漏洞和格式扩展*定义。 为确保安全,系统采用了一个安全模型,为 BMS 和主动诊断读取情况格式化应用数据。安全考虑因素包括设备相互验证、使用安全通道(加密和防篡改)以及确保电池组内读数的安全。 考虑到不同的 BMS 拓扑,包括集中式、调制式、分布式和分散式,系统需要满足设备相互验证和使用安全通道的要求。对于每种拓扑结构,都必须考虑将性能开销降至最低。电池是封闭的,对其进行物理攻击不可行或成本太高。外部攻击可能也很困难。基于对称或非对称加密技术的自动验证可用于保护电池组读数。安全协议在验证阶段和会话密钥确认阶段采用双密钥加密,以抵御攻击。中间件在数据格式验证、确认和处理中发挥关键作用,确保数据传输安全。 (iii) 唤醒模型设计
-
排除和处理数据库热点问题
-
阿里味 "的《Redis核心实践全彩手册》给你,还学不会转行--Redis基本是必考点。在 "阿里味 "的《Redis核心实战全彩手册》里,你还是学不会转行--Redis基本是必考点: - Redis 常见的性能问题有哪些?Redis 最常见的性能问题有哪些,如何解决?--性能相关 - Redis 缓存的雪崩、击落和穿透到底意味着什么?如何处理?--缓存相关 - Redis 主从集群有哪些常见问题?如何解决?--可用性 - 现有的 Redis 实例有 6GB 的存储空间,预计将来会扩展到 32GB,你能提供解决方案并分析其优势和潜在问题吗?--可扩展性相关 毕竟,10 家公司中至少有 8 家的架构系统中都有 Redis,基本上可以说是 IT 基础架构的必备系统。 因此,Redis 的开发和运维是很多大厂的重要工作,也是我们必须掌握的技术栈。 不过,Redis 毕竟是一个复杂的键值数据库,在实际使用中,有非常多的技术点需要注意,比如:各种数据结构、数据持久化机制、分片集群、主从集群等等。 一不小心,性能就会每况愈下,失去 "快 "的最大特点!