Hbase 恢复一个崩溃的 RegionServer 需要多长时间
How long Hbase need to take for recovering one crashed RegionServer
Hbase RegionServer好像是单节点的，不像Cassandra有复制节点。我知道当一个 RegionServer 宕机时，HMaster 会将崩溃的 RS 上的区域分配给其他 RS。
但是新的 RegionServer 需要多长时间才能为崩溃的区域提供服务，如果时间太长，客户端不能等待太久，客户端会抛出异常甚至丢失数据，对吗？
您正在寻找的是 HBase 平均恢复时间。
有一些文章在谈论它。根据这个回答你的问题 article:
Hbase从故障中恢复需要多长时间
这取决于您的设置、您的 hbase 版本、您的硬件...
此过程有 3 个步骤：
- 确定区域服务器已关闭。这是由 Zookeeper 执行的称为心跳的进程完成的。如果regionserver在Timeout之前没有响应心跳，master会认为regionServer挂掉了。
- 恢复正在进行的写入：在写入区域服务器之前，写入会保存在日志中。因为数据被复制了，比方说三次，如果一个节点崩溃，你仍然有两个具有正确值的日志。所以当 master 知道一个 region server 死了，它会尝试通过读取日志来恢复他最后的状态。
- 重新分配区域：取决于你的HBase版本
期间数据丢失了吗？
是的，在恢复完成之前，客户端一直处于阻塞状态。这就是为什么有一些方法可以通过调整 hbase 和 zookeeper 的设置来最大程度地减少停机时间。有关操作，请参阅 this blog post。
编辑
正如FengWang所说，我可能暗示HBase需要很长时间才能从故障中恢复。与 Cassandra 相比，它确实需要更多的资源来恢复节点。这可以用 CAP 定理 来解释：具有 master/regionServer 架构的 Hbase 是 一致的 和 分区容错的 但 不可用 。但是，具有点对点架构的 Cassandra 可用 和 分区容错 但 不一致 .
这只是一般性的，因为实际上，您可以通过正确的配置和方案调整 HBase 以使其可用（就像 FengWang 那样），但是您会丢失其他东西。拥有 100 个节点，而您可以拥有 10 个具有更大存储容量的节点，这是一个很大的价格差异。此外，必须查询更多节点进行扫描并不符合成本效益，但通过微调您可以克服这个问题（使用良好的数据方案可以避免扫描太多节点）。在 Cassandra 案例中，您可以设置查询的一致性级别。等级越高查询越慢
在分布式系统中，你只能用一种东西交换另一种东西。没有通用的问题解决方案。
我在 100 个节点的 Hbase 集群上做了一些测试。当一个 RegionServer 宕机时，Hbase 通常需要 3-5 秒才能从 HDFS 重新加载丢失的区域和 Hlog。即客户端仅被阻止不到 5 秒。不像上面post说的要1分钟。如果真的需要 1 分钟，我敢打赌没有人愿意使用 Hbase。
而对于Cassandra，如果一个节点宕机，重新加载丢失的数据通常需要不到1秒的时间。
Hbase RegionServer好像是单节点的，不像Cassandra有复制节点。我知道当一个 RegionServer 宕机时，HMaster 会将崩溃的 RS 上的区域分配给其他 RS。
但是新的 RegionServer 需要多长时间才能为崩溃的区域提供服务，如果时间太长，客户端不能等待太久，客户端会抛出异常甚至丢失数据，对吗？
您正在寻找的是 HBase 平均恢复时间。
有一些文章在谈论它。根据这个回答你的问题 article:
Hbase从故障中恢复需要多长时间
这取决于您的设置、您的 hbase 版本、您的硬件...
此过程有 3 个步骤：
- 确定区域服务器已关闭。这是由 Zookeeper 执行的称为心跳的进程完成的。如果regionserver在Timeout之前没有响应心跳，master会认为regionServer挂掉了。
- 恢复正在进行的写入：在写入区域服务器之前，写入会保存在日志中。因为数据被复制了，比方说三次，如果一个节点崩溃，你仍然有两个具有正确值的日志。所以当 master 知道一个 region server 死了，它会尝试通过读取日志来恢复他最后的状态。
- 重新分配区域：取决于你的HBase版本
期间数据丢失了吗？
是的，在恢复完成之前，客户端一直处于阻塞状态。这就是为什么有一些方法可以通过调整 hbase 和 zookeeper 的设置来最大程度地减少停机时间。有关操作，请参阅 this blog post。
编辑
正如FengWang所说，我可能暗示HBase需要很长时间才能从故障中恢复。与 Cassandra 相比，它确实需要更多的资源来恢复节点。这可以用 CAP 定理 来解释：具有 master/regionServer 架构的 Hbase 是 一致的 和 分区容错的 但 不可用 。但是，具有点对点架构的 Cassandra 可用 和 分区容错 但 不一致 .
这只是一般性的，因为实际上，您可以通过正确的配置和方案调整 HBase 以使其可用（就像 FengWang 那样），但是您会丢失其他东西。拥有 100 个节点，而您可以拥有 10 个具有更大存储容量的节点，这是一个很大的价格差异。此外，必须查询更多节点进行扫描并不符合成本效益，但通过微调您可以克服这个问题（使用良好的数据方案可以避免扫描太多节点）。在 Cassandra 案例中，您可以设置查询的一致性级别。等级越高查询越慢
在分布式系统中，你只能用一种东西交换另一种东西。没有通用的问题解决方案。
我在 100 个节点的 Hbase 集群上做了一些测试。当一个 RegionServer 宕机时，Hbase 通常需要 3-5 秒才能从 HDFS 重新加载丢失的区域和 Hlog。即客户端仅被阻止不到 5 秒。不像上面post说的要1分钟。如果真的需要 1 分钟，我敢打赌没有人愿意使用 Hbase。
而对于Cassandra，如果一个节点宕机，重新加载丢失的数据通常需要不到1秒的时间。