hbase - Hbase 需要多长时间才能恢复一台崩溃的 RegionServer

Question

似乎 Hbase RegionServer 是单个节点，不像 Cassandra 那样有复制节点。我知道当一个 RegionServer 宕机时，HMaster 会将崩溃的 RS 上的区域分配给其他 RS。

但是新的 RegionServer 准备为崩溃的区域服务多久，如果时间太长，客户端不能等待太久，客户端甚至会抛出异常甚至丢失数据，对吧？

Answer 1

您要找的是 HBase 平均恢复时间 .
有一些文章在谈论它。基于此回答您的问题 article :
Hbase 从故障中恢复需要多长时间
这取决于您的设置、您的 hbase 版本、您的硬件...
此过程有 3 个步骤:

确定区域服务器已关闭。这是由 Zookeeper 执行的称为 heartbeat 的进程完成的。如果 region server 在 Timeout 之前没有响应心跳，master 会认为 regionServer 已经死了。

恢复正在进行的写入:在写入区域服务器之前，写入会保留在日志中。因为数据被复制了，比方说 3 次，如果一个节点崩溃，你仍然有两个具有正确值的日志。因此，当 master 知道某个区域服务器已死时，它将尝试恢复他读取日志的最后状态。

重新分配区域:取决于你的 HBase 版本

在此期间数据是否丢失？
是的，在恢复完成之前，客户端会被阻止。这就是为什么有办法通过使用 hbase 和 zookeeper 的设置来最大限度地减少停机时间。见 this blog post为操纵。
编辑
正如 FengWang 所说，我可能暗示 HBase 需要很长时间才能从故障中恢复。与 Cassandra 相比，恢复节点确实需要更多资源。这可以通过 来解释CAP 定理 : Hbase 的 master/regionServer 架构是 一致 和 分区容错但是 不可用 .然而，Cassandra 及其对等架构是 可用 和 分区容错但是 不一致 .
这只是一般性，因为实际上，您可以调整 HBase 以使其在正确的配置和方案下可用(就像 FengWang 那样)，但您会失去其他东西。拥有 100 个节点，而您可以拥有 10 个存储容量更大的节点，这是一个很大的价格差异。此外，必须查询更多节点进行扫描并不具有成本效益，但通过微调您可以克服这个问题(使用良好的数据方案可以避免扫描过多节点)。在 Cassandra 情况下，您可以设置查询的一致性级别。级别越高，查询越慢。
在分布式系统中，你只能用一种东西换另一种东西。一个问题没有通用的解决方案。