1. 问题初探当HBase Shell告诉你“Master正在初始化”如果你正在操作HBase尤其是在集群刚启动、重启或者进行某些维护操作后满怀信心地在Shell里敲下list或create命令却迎面撞上这么一行刺眼的错误ERROR: org.apache.hadoop.hbase.PleaseHoldException: Master is initializing那一刻的感觉就像你急着开车出门拧了钥匙却发现引擎只是“吭哧吭哧”响就是点不着火。这个错误是HBase在明确告诉你“别急老大Master自己还没准备好呢现在没法处理你的请求。”这个PleaseHoldException字面意思就是“请稍候”。它不是一个致命的、表示配置错误的异常而是一个临时性的状态异常。它表明HBase Master进程正在执行启动或恢复的关键流程尚未达到对外提供服务的“就绪”状态。理解这一点至关重要因为它决定了我们的排查方向不是去盲目修改配置文件而是去诊断“为什么Master的初始化过程被卡住了”或者“如何确认它已经完成初始化”。在实际生产运维和开发测试中这个问题相当常见。可能你刚用start-hbase.sh启动了集群就立刻连接Shell操作可能RegionServer异常退出导致Master需要重新分配负载也可能仅仅是磁盘慢、网络波动导致Master读取元数据hbase:meta表的时间比预期长。无论原因如何解决它的核心思路是耐心等待并观察Master日志如果等待无果则深入日志定位阻塞点。2. 核心原理HBase Master启动时到底在忙什么要解决问题不能只知其然更要知其所以然。我们得先弄明白HBase Master在启动时这个“initializing”阶段具体在做什么。这就像医生治病得先知道身体的正常运作机制。HBase Master是集群的“大脑”负责管理所有元数据、协调RegionServer、处理DDL操作建表、删表等。它的启动不是一个瞬间动作而是一个包含多个步骤的序列任何一步受阻都会导致初始化超时或失败从而抛出PleaseHoldException。2.1 Master初始化的关键步骤加载文件系统状态Master首先会连接到它所依赖的底层文件系统通常是HDFS确认其可用性并检查HBase的根目录由hbase.rootdir配置是否存在且可访问。恢复或创建元数据表这是最关键的一步。Master需要找到或创建hbase:meta系统表。这个表记录了所有用户表User Table的Region分布信息如Region名、起始/结束RowKey、所在的RegionServer地址等。如果hbase:meta表损坏或丢失Master会尝试从HDFS上的存档日志WAL中进行恢复这个过程可能非常耗时。分配RegionServer负载Master从hbase:meta中读取当前的Region分配状态。如果集群是首次启动它会开始分配初始的Region。如果是重启它会检查是否有RegionServer宕机并将其上托管的Region重新分配到其他活跃的RegionServer上。这个过程称为“Region分配”。等待RegionServer注册Master启动后会等待配置中的所有RegionServer主动向它注册。直到有足够数量或全部的RegionServer成功注册Master才会认为集群基本就绪。进入活跃状态完成以上所有步骤后Master将自己的状态从“初始化中”切换为“活跃”此时才能开始处理客户端的RPC请求。2.2 为什么Shell命令会触发这个异常HBase Shell本质上是一个用JRuby编写的客户端工具。当你执行list命令时Shell会通过RPC调用Master的listTableNames方法。如果Master还处于上述初始化步骤中的任何一步它就会拒绝这个RPC请求并抛出PleaseHoldException。客户端Shell接收到这个异常后将其转换为人类可读的错误信息打印出来。注意这里有一个常见的误解区。有时用户看到这个错误会去反复重启Master这通常不是最佳首选方案。正确的做法是查看Master的日志因为日志会详细记录它卡在了哪个初始化步骤以及可能的原因。3. 标准排查流程从“等待”到“干预”遇到“Master is initializing”不要慌遵循一个从简到繁的排查流程可以高效地解决问题。3.1 第一步保持耐心给予足够的等待时间对于刚启动的集群首先给Master 1到3分钟的初始化时间。特别是当集群数据量很大、HDFS负载较高或使用机械硬盘时Master恢复元数据的过程可能较慢。操作什么也不做等待几分钟。观察在此期间你可以通过HBase Web UI默认端口16010来观察Master状态。在浏览器访问http://master-hostname:16010如果能看到Master的Web界面并且Overview页面显示集群信息如Live RegionServers数量则说明Master已就绪。验证等待后再次在Shell中执行status simple命令。这个命令负载较轻是检查Master状态的好方法。如果返回包含1 live server等信息说明Master已活跃。3.2 第二步查看Master日志定位阻塞根源如果等待超过5分钟甚至更久问题依然存在那么就必须查看日志了。日志是定位问题的“金钥匙”。HBase的日志通常位于$HBASE_HOME/logs/目录下Master的日志文件命名类似hbase-username-master-hostname.log。关键日志分析点寻找初始化开始的标记在日志中搜索 “Master startup proceeding” 或 “Initializing master” 类似的语句找到启动起点。追踪初始化步骤随后日志会按顺序打印各个步骤如Loading HFile info...Initializing ZK system trackers...Recovering regions from crash...Assigning regions...Waiting for RegionServers to report in...识别错误或警告仔细查看在某个步骤之后是否有连续的警告WARN或错误ERROR信息。常见的阻塞点包括ZK连接问题大量关于ZooKeeper连接超时、Session expired的日志。检查ZooKeeper集群是否健康网络是否通畅hbase.zookeeper.quorum配置是否正确。HDFS连接/权限问题无法访问hbase.rootdir路径报IOException或AccessControlException。检查HDFS服务状态以及运行HBase进程的用户如hbase是否有该路径的读写权限。hbase:meta表损坏日志中可能出现无法读取meta表、或尝试恢复但失败的记录。这是比较严重的情况。RegionServer无法注册Master一直在等待某个或某些RegionServer注册但对方没有响应。需要去检查对应RegionServer的日志和状态。内存不足在加载大量Region元数据时如果Master分配的JVM堆内存不足可能会引发长时间的GC暂停甚至OOM导致初始化进程卡顿或中断。3.3 第三步针对日志提示进行专项解决根据日志中发现的线索采取相应措施案例ZK连接问题WARN [master/host:16000] zookeeper.RecoverableZooKeeper: Possibly transient ZooKeeper exception org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode ConnectionLoss解决确保ZooKeeper服务已启动且所有节点健康。使用zkCli.sh连接测试。检查HBase配置hbase.zookeeper.property.clientPort和hbase.zookeeper.quorum。案例HDFS权限问题ERROR [master/host:16000] master.HMaster: Failed to become active master java.io.IOException: Call to HDFS_HOST:8020 failed on local exception...解决以HBase进程用户身份执行hadoop fs -ls /hbase假设根目录是/hbase测试权限。必要时在HDFS上使用hadoop fs -chown和hadoop fs -chmod修正目录属主和权限。案例等待RegionServer超时Master日志显示已分配Region但一直在等待某些RegionServer。需要去检查那些未注册的RegionServer的日志常见原因可能是RegionServer启动失败、无法连接ZK或Master、或者自身配置错误。4. 高级诊断与修复操作如果上述标准流程无法解决或者日志指向一些更深层次的问题就需要一些更高级的操作。4.1 检查关键配置项错误的配置是万恶之源。请核对hbase-site.xml中的以下几个核心配置!-- 必须正确且HBase进程用户有读写权限 -- property namehbase.rootdir/name valuehdfs://your-nn-host:8020/hbase/value /property !-- 必须正确且ZK集群健康 -- property namehbase.zookeeper.quorum/name valuezk-host1,zk-host2,zk-host3/value /property !-- Master绑定的主机名必须能正确解析且其他节点能访问 -- property namehbase.master.hostname/name valueyour-master-hostname/value /property !-- RPC端口确保未被占用 -- property namehbase.master.port/name value16000/value /property实操心得hbase.master.hostname这个配置容易被忽略。如果Master节点有多个网卡或主机名解析有问题可能导致其他节点包括Shell客户端无法连接到它。一个简单的测试方法是在Shell客户端机器上ping一下这个主机名看是否能解析到正确的IP。4.2 处理元数据表hbase:meta问题如果怀疑hbase:meta表损坏可以尝试以下步骤。警告操作元数据风险极高务必先备份HBase根目录停止HBase集群在所有节点执行stop-hbase.sh。检查HDFS上的meta表使用HDFS命令查看/hbase/data/hbase/meta路径根据你的hbase.rootdir变化目录下是否存在文件。如果该目录完全为空或明显异常可能是元数据丢失。尝试修复工具谨慎HBase提供了一个离线元数据修复工具hbck2HBase 2.x版本。你可以使用它来检查并尝试修复不一致性。例如hbase hbck -j hbase-hbck2-*.jar setTableState hbase:meta ENABLED但这需要深入理解hbck2的使用场景误用可能导致数据丢失。强烈建议在执行前查阅对应版本HBase的官方文档。4.3 重启策略与顺序有时一个干净的重启可以解决因临时状态不一致导致的问题。正确的重启顺序是停止HBase集群stop-hbase.sh停止ZooKeeper集群如果独立部署。等待约30秒确保进程完全退出。启动ZooKeeper集群。确认ZooKeeper健康后启动HBase集群start-hbase.sh先观察Master日志待其显示“Master has completed initialization”或类似信息后再操作Shell。5. 常见问题场景与速查表下面将一些典型场景、现象和解决方案浓缩成一张速查表方便你快速对照问题场景可能的现象/日志关键词解决思路与操作集群首次启动或新增节点无特定错误只是初始化慢。耐心等待。观察Master日志初始化进度特别是分配Region和等待RegionServer注册的阶段。ZooKeeper连接不稳定日志中出现大量ConnectionLoss,SessionExpired警告。Master反复尝试连接ZK。1. 检查ZK服务状态 (zkServer.sh status)。2. 检查网络和防火墙。3. 核对hbase.zookeeper.quorum配置。HDFS不可用或权限不足日志报IOException访问hbase.rootdir失败或AccessControlException。1. 检查HDFS服务是否正常 (hdfs dfsadmin -report)。2. 检查HBase根目录是否存在及权限 (hadoop fs -ls /)。3. 修正HDFS目录权限。RegionServer未能启动或注册Master日志显示一直在“Waiting for RegionServers”但某个RS始终未出现。1. 去对应的RegionServer节点查看其日志。2. 检查RegionServer的配置特别是ZK和Master地址。3. 检查RegionServer节点资源内存、磁盘。Master主机名解析问题其他节点或客户端无法ping通Master配置的主机名。Shell连接超时。1. 检查/etc/hosts文件或DNS确保主机名能解析到正确IP。2. 考虑在配置中使用IP地址替代主机名。JVM内存不足Master日志在加载大量Region信息时GC频繁甚至出现OutOfMemoryError。增加Master的JVM堆内存。编辑hbase-env.sh调整HBASE_MASTER_OPTS中的-Xmx参数例如-Xmx4g。端口冲突Master启动失败日志显示端口16000, 16010被占用。使用netstat -tunlp | grep 端口号查找占用进程并终止或为HBase配置其他端口。文件描述符或进程数限制日志中可能出现Too many open files错误。提高运行HBase用户的系统限制。编辑/etc/security/limits.conf增加nofile和nproc限制。6. 预防措施与最佳实践解决问题固然重要但防患于未然更能提升运维效率。监控与告警将HBase Master的进程状态、初始化时间、以及日志中的ERROR/WARN信息纳入监控系统如PrometheusGrafana或ELK。一旦Master初始化超过阈值如5分钟立即触发告警。资源保障为Master节点分配充足的CPU、内存特别是JVM堆内存和稳定的网络。避免将其部署在磁盘IO或网络带宽紧张的节点上。配置规范化使用主机名时确保集群内所有节点的/etc/hosts文件保持一致或使用稳定可靠的内部DNS。明确设置hbase.master.hostname。启动后健康检查编写一个简单的脚本在集群启动后自动轮询Master的Web UI或执行hbase shell -n ‘status “simple”‘命令直到返回成功状态再进行后续业务操作。定期维护对于长期运行的集群定期检查HDFS上HBase目录的权限和状态。在重大操作如扩容、升级前对元数据表进行备份。我个人在处理这类问题的经验是“Master is initializing” 十之八九是环境或依赖服务的问题而非HBase自身的代码缺陷。养成第一时间查看Master日志的习惯能帮你节省大量盲目尝试的时间。日志中的错误信息往往非常直接顺着它去检查ZK、HDFS、网络、权限这些“基础设施”问题通常就能迎刃而解。把HBase集群想象成一个精密的机器Master是控制台而ZK和HDFS是电源和地基地基不稳控制台自然无法正常工作。
HBase Master初始化异常排查：从原理到实战解决PleaseHoldException
1. 问题初探当HBase Shell告诉你“Master正在初始化”如果你正在操作HBase尤其是在集群刚启动、重启或者进行某些维护操作后满怀信心地在Shell里敲下list或create命令却迎面撞上这么一行刺眼的错误ERROR: org.apache.hadoop.hbase.PleaseHoldException: Master is initializing那一刻的感觉就像你急着开车出门拧了钥匙却发现引擎只是“吭哧吭哧”响就是点不着火。这个错误是HBase在明确告诉你“别急老大Master自己还没准备好呢现在没法处理你的请求。”这个PleaseHoldException字面意思就是“请稍候”。它不是一个致命的、表示配置错误的异常而是一个临时性的状态异常。它表明HBase Master进程正在执行启动或恢复的关键流程尚未达到对外提供服务的“就绪”状态。理解这一点至关重要因为它决定了我们的排查方向不是去盲目修改配置文件而是去诊断“为什么Master的初始化过程被卡住了”或者“如何确认它已经完成初始化”。在实际生产运维和开发测试中这个问题相当常见。可能你刚用start-hbase.sh启动了集群就立刻连接Shell操作可能RegionServer异常退出导致Master需要重新分配负载也可能仅仅是磁盘慢、网络波动导致Master读取元数据hbase:meta表的时间比预期长。无论原因如何解决它的核心思路是耐心等待并观察Master日志如果等待无果则深入日志定位阻塞点。2. 核心原理HBase Master启动时到底在忙什么要解决问题不能只知其然更要知其所以然。我们得先弄明白HBase Master在启动时这个“initializing”阶段具体在做什么。这就像医生治病得先知道身体的正常运作机制。HBase Master是集群的“大脑”负责管理所有元数据、协调RegionServer、处理DDL操作建表、删表等。它的启动不是一个瞬间动作而是一个包含多个步骤的序列任何一步受阻都会导致初始化超时或失败从而抛出PleaseHoldException。2.1 Master初始化的关键步骤加载文件系统状态Master首先会连接到它所依赖的底层文件系统通常是HDFS确认其可用性并检查HBase的根目录由hbase.rootdir配置是否存在且可访问。恢复或创建元数据表这是最关键的一步。Master需要找到或创建hbase:meta系统表。这个表记录了所有用户表User Table的Region分布信息如Region名、起始/结束RowKey、所在的RegionServer地址等。如果hbase:meta表损坏或丢失Master会尝试从HDFS上的存档日志WAL中进行恢复这个过程可能非常耗时。分配RegionServer负载Master从hbase:meta中读取当前的Region分配状态。如果集群是首次启动它会开始分配初始的Region。如果是重启它会检查是否有RegionServer宕机并将其上托管的Region重新分配到其他活跃的RegionServer上。这个过程称为“Region分配”。等待RegionServer注册Master启动后会等待配置中的所有RegionServer主动向它注册。直到有足够数量或全部的RegionServer成功注册Master才会认为集群基本就绪。进入活跃状态完成以上所有步骤后Master将自己的状态从“初始化中”切换为“活跃”此时才能开始处理客户端的RPC请求。2.2 为什么Shell命令会触发这个异常HBase Shell本质上是一个用JRuby编写的客户端工具。当你执行list命令时Shell会通过RPC调用Master的listTableNames方法。如果Master还处于上述初始化步骤中的任何一步它就会拒绝这个RPC请求并抛出PleaseHoldException。客户端Shell接收到这个异常后将其转换为人类可读的错误信息打印出来。注意这里有一个常见的误解区。有时用户看到这个错误会去反复重启Master这通常不是最佳首选方案。正确的做法是查看Master的日志因为日志会详细记录它卡在了哪个初始化步骤以及可能的原因。3. 标准排查流程从“等待”到“干预”遇到“Master is initializing”不要慌遵循一个从简到繁的排查流程可以高效地解决问题。3.1 第一步保持耐心给予足够的等待时间对于刚启动的集群首先给Master 1到3分钟的初始化时间。特别是当集群数据量很大、HDFS负载较高或使用机械硬盘时Master恢复元数据的过程可能较慢。操作什么也不做等待几分钟。观察在此期间你可以通过HBase Web UI默认端口16010来观察Master状态。在浏览器访问http://master-hostname:16010如果能看到Master的Web界面并且Overview页面显示集群信息如Live RegionServers数量则说明Master已就绪。验证等待后再次在Shell中执行status simple命令。这个命令负载较轻是检查Master状态的好方法。如果返回包含1 live server等信息说明Master已活跃。3.2 第二步查看Master日志定位阻塞根源如果等待超过5分钟甚至更久问题依然存在那么就必须查看日志了。日志是定位问题的“金钥匙”。HBase的日志通常位于$HBASE_HOME/logs/目录下Master的日志文件命名类似hbase-username-master-hostname.log。关键日志分析点寻找初始化开始的标记在日志中搜索 “Master startup proceeding” 或 “Initializing master” 类似的语句找到启动起点。追踪初始化步骤随后日志会按顺序打印各个步骤如Loading HFile info...Initializing ZK system trackers...Recovering regions from crash...Assigning regions...Waiting for RegionServers to report in...识别错误或警告仔细查看在某个步骤之后是否有连续的警告WARN或错误ERROR信息。常见的阻塞点包括ZK连接问题大量关于ZooKeeper连接超时、Session expired的日志。检查ZooKeeper集群是否健康网络是否通畅hbase.zookeeper.quorum配置是否正确。HDFS连接/权限问题无法访问hbase.rootdir路径报IOException或AccessControlException。检查HDFS服务状态以及运行HBase进程的用户如hbase是否有该路径的读写权限。hbase:meta表损坏日志中可能出现无法读取meta表、或尝试恢复但失败的记录。这是比较严重的情况。RegionServer无法注册Master一直在等待某个或某些RegionServer注册但对方没有响应。需要去检查对应RegionServer的日志和状态。内存不足在加载大量Region元数据时如果Master分配的JVM堆内存不足可能会引发长时间的GC暂停甚至OOM导致初始化进程卡顿或中断。3.3 第三步针对日志提示进行专项解决根据日志中发现的线索采取相应措施案例ZK连接问题WARN [master/host:16000] zookeeper.RecoverableZooKeeper: Possibly transient ZooKeeper exception org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode ConnectionLoss解决确保ZooKeeper服务已启动且所有节点健康。使用zkCli.sh连接测试。检查HBase配置hbase.zookeeper.property.clientPort和hbase.zookeeper.quorum。案例HDFS权限问题ERROR [master/host:16000] master.HMaster: Failed to become active master java.io.IOException: Call to HDFS_HOST:8020 failed on local exception...解决以HBase进程用户身份执行hadoop fs -ls /hbase假设根目录是/hbase测试权限。必要时在HDFS上使用hadoop fs -chown和hadoop fs -chmod修正目录属主和权限。案例等待RegionServer超时Master日志显示已分配Region但一直在等待某些RegionServer。需要去检查那些未注册的RegionServer的日志常见原因可能是RegionServer启动失败、无法连接ZK或Master、或者自身配置错误。4. 高级诊断与修复操作如果上述标准流程无法解决或者日志指向一些更深层次的问题就需要一些更高级的操作。4.1 检查关键配置项错误的配置是万恶之源。请核对hbase-site.xml中的以下几个核心配置!-- 必须正确且HBase进程用户有读写权限 -- property namehbase.rootdir/name valuehdfs://your-nn-host:8020/hbase/value /property !-- 必须正确且ZK集群健康 -- property namehbase.zookeeper.quorum/name valuezk-host1,zk-host2,zk-host3/value /property !-- Master绑定的主机名必须能正确解析且其他节点能访问 -- property namehbase.master.hostname/name valueyour-master-hostname/value /property !-- RPC端口确保未被占用 -- property namehbase.master.port/name value16000/value /property实操心得hbase.master.hostname这个配置容易被忽略。如果Master节点有多个网卡或主机名解析有问题可能导致其他节点包括Shell客户端无法连接到它。一个简单的测试方法是在Shell客户端机器上ping一下这个主机名看是否能解析到正确的IP。4.2 处理元数据表hbase:meta问题如果怀疑hbase:meta表损坏可以尝试以下步骤。警告操作元数据风险极高务必先备份HBase根目录停止HBase集群在所有节点执行stop-hbase.sh。检查HDFS上的meta表使用HDFS命令查看/hbase/data/hbase/meta路径根据你的hbase.rootdir变化目录下是否存在文件。如果该目录完全为空或明显异常可能是元数据丢失。尝试修复工具谨慎HBase提供了一个离线元数据修复工具hbck2HBase 2.x版本。你可以使用它来检查并尝试修复不一致性。例如hbase hbck -j hbase-hbck2-*.jar setTableState hbase:meta ENABLED但这需要深入理解hbck2的使用场景误用可能导致数据丢失。强烈建议在执行前查阅对应版本HBase的官方文档。4.3 重启策略与顺序有时一个干净的重启可以解决因临时状态不一致导致的问题。正确的重启顺序是停止HBase集群stop-hbase.sh停止ZooKeeper集群如果独立部署。等待约30秒确保进程完全退出。启动ZooKeeper集群。确认ZooKeeper健康后启动HBase集群start-hbase.sh先观察Master日志待其显示“Master has completed initialization”或类似信息后再操作Shell。5. 常见问题场景与速查表下面将一些典型场景、现象和解决方案浓缩成一张速查表方便你快速对照问题场景可能的现象/日志关键词解决思路与操作集群首次启动或新增节点无特定错误只是初始化慢。耐心等待。观察Master日志初始化进度特别是分配Region和等待RegionServer注册的阶段。ZooKeeper连接不稳定日志中出现大量ConnectionLoss,SessionExpired警告。Master反复尝试连接ZK。1. 检查ZK服务状态 (zkServer.sh status)。2. 检查网络和防火墙。3. 核对hbase.zookeeper.quorum配置。HDFS不可用或权限不足日志报IOException访问hbase.rootdir失败或AccessControlException。1. 检查HDFS服务是否正常 (hdfs dfsadmin -report)。2. 检查HBase根目录是否存在及权限 (hadoop fs -ls /)。3. 修正HDFS目录权限。RegionServer未能启动或注册Master日志显示一直在“Waiting for RegionServers”但某个RS始终未出现。1. 去对应的RegionServer节点查看其日志。2. 检查RegionServer的配置特别是ZK和Master地址。3. 检查RegionServer节点资源内存、磁盘。Master主机名解析问题其他节点或客户端无法ping通Master配置的主机名。Shell连接超时。1. 检查/etc/hosts文件或DNS确保主机名能解析到正确IP。2. 考虑在配置中使用IP地址替代主机名。JVM内存不足Master日志在加载大量Region信息时GC频繁甚至出现OutOfMemoryError。增加Master的JVM堆内存。编辑hbase-env.sh调整HBASE_MASTER_OPTS中的-Xmx参数例如-Xmx4g。端口冲突Master启动失败日志显示端口16000, 16010被占用。使用netstat -tunlp | grep 端口号查找占用进程并终止或为HBase配置其他端口。文件描述符或进程数限制日志中可能出现Too many open files错误。提高运行HBase用户的系统限制。编辑/etc/security/limits.conf增加nofile和nproc限制。6. 预防措施与最佳实践解决问题固然重要但防患于未然更能提升运维效率。监控与告警将HBase Master的进程状态、初始化时间、以及日志中的ERROR/WARN信息纳入监控系统如PrometheusGrafana或ELK。一旦Master初始化超过阈值如5分钟立即触发告警。资源保障为Master节点分配充足的CPU、内存特别是JVM堆内存和稳定的网络。避免将其部署在磁盘IO或网络带宽紧张的节点上。配置规范化使用主机名时确保集群内所有节点的/etc/hosts文件保持一致或使用稳定可靠的内部DNS。明确设置hbase.master.hostname。启动后健康检查编写一个简单的脚本在集群启动后自动轮询Master的Web UI或执行hbase shell -n ‘status “simple”‘命令直到返回成功状态再进行后续业务操作。定期维护对于长期运行的集群定期检查HDFS上HBase目录的权限和状态。在重大操作如扩容、升级前对元数据表进行备份。我个人在处理这类问题的经验是“Master is initializing” 十之八九是环境或依赖服务的问题而非HBase自身的代码缺陷。养成第一时间查看Master日志的习惯能帮你节省大量盲目尝试的时间。日志中的错误信息往往非常直接顺着它去检查ZK、HDFS、网络、权限这些“基础设施”问题通常就能迎刃而解。把HBase集群想象成一个精密的机器Master是控制台而ZK和HDFS是电源和地基地基不稳控制台自然无法正常工作。
