大规模集群故障处理，能抗住这3个灵魂拷问算你赢

… ERROR: Region { meta => index_natip201712,#xA0,1512009553152.00d96f6b2de55b56453e7060328b7930., hdfs => hdfs://ns1/hbase_ipsource3/data/default/index_natip201712/00d96f6b2de55b56453e7060328b7930, deployed => } not deployed on any region server. ERROR: Region { meta => index_natip201711,Y`,1509436894266.00e2784a250af945c66fb70370344f2f., hdfs => hdfs://ns1/hbase_ipsource3/data/default/index_natip201711/00e2784a250af945c66fb70370344f2f, deployed => } not deployed on any region server. … ERROR: There is a hole in the region chain between x02 and x02@. You need to create a new .regioninfo and region dir in hdfs to plug the hole. ERROR: There is a hole in the region chain between x04 and x04@. You need to create a new .regioninfo and region dir in hdfs to plug the hole.

每张表可用(online)的 region 数都少于 1000，共存在 391 个 inconsistency，整个集群基本不可用。

因为每张表都不可用，所以通过新建表并将原表的 HFile 文件 BulkLoad 入新表的方案基本不可行。

第一、这种方案耗时太长;第二、做过一个基本测试，如果按照原表预 分区的方式新建表，在 BulkLoad 操作后，无法在新表上查询数据(get 及 scan 操作均 阻塞，原因未知，初步估计和预分区方式有关)。

基于以上分析，决定采用 hbck 直接修复原表的方案进行，不再采用 BulkLoad 方案。

运行命令 hbae hbck -repair -fixAssignments -fixMeta，报Repair 过程阻塞异常。

查 HMaster 后台日志，发现是某个 RegionServer(DSJ-signal-4T-147/10.162.0.175)的连接数超多造成连接超时。重启该 RegionServer 后再次运行 hbck -repair -fixAssignments -fixMeta 顺序结束，并成功修复了所有表的 region un-assignment、hole 及 HBase:meta 问题。

应用层测试整个集群入库正常，问题处理完成。

10、Kafka集群频频到达性能瓶颈，造成上下游数据传输积压。

Kafka集群节点数50+，集群使用普通SATA盘，存储能力2000TB，千亿级日流量，经常会出现个别磁盘IO打满，导致生产断传，消费延迟，继而引发消费offset越界，单个节点topic配置记录过期等问题。

1)降低topic副本：

建议如果能降低大部分topic的副本，这个方法是简单有效的。

降副本之后再把集群的拷贝副本所用的cpu核数降低，可以由num.replica.fetchers=6降低为num.replica.fetchers=3。磁盘IO使用的num.io.threads=14升为num.io.threads=16。num.network.threads=8升为num.network.threads=9。此参数只是暂时压榨机器性能，当数据量递增时仍会发生故障。

2)设定topic创建规则，针对磁盘性能瓶颈做分区指定磁盘迁移：

如果降低副本收效甚微，考虑到目前集群瓶颈主要在个别磁盘读写IO达到峰值，是因磁盘的topic分区分配不合理导致，建议首先做好针对topic分区级别IO速率的监控，然后形成规范合理的topic创建分区规则(数据量，流量大的topic先创建;分区数*副本数是磁盘总数的整数倍)，先做到磁盘存储的均衡，再挑出来个别读写IO到达瓶颈的磁盘，根据监控找出读写异常大分区。

找出分区后再次进行针对topic的分区扩容或者针对问题分区进行指定磁盘的迁移。这样集群的整体利用率和稳定性能得到一定的提升，能节省集群资源。

3)Kafka版本升级及cm纳管：

将手工集群迁移至cm纳管，并在线升级Kafka版本。

4)zk和broker节点分离：

进行zk和broker节点的分离工作，建议进行zk节点变化而不是broker节点变化，以此避免数据拷贝带来的集群负荷，建议创建测试topic，由客户端适当增加批大小和减少提交频率进行测试，使集群性能达到优良。

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!