Hypertable集群中某些Range Server发生故障（Range Server进程故障退出）时，需要重新启动该Range Server并恢复服务，这依赖于Range Server记录的操作日志（CommitLog和SplitLog等）。BigTable系统（Hypertable/HBase）最重要的功能之一是自动恢复，自动恢复依赖操作日志（Commit Log）能够真正写入HDFS（Sync），故障发生后，系统通过重放日志构建故障前的一致性状态。

    在我们早期使用Hypertable和Hadoop系统时，Hadoop 0.18版本尚不支持Append Sync功能。即使当前版本的Hadoop支持了Append Sync功能，频繁使用Sync也会影响系统的写吞吐能力。另外，Hadoop的稳定性在当时还不能得到保证，存在写入失败的情况。如果Hadoop出现问题，那么Hypertable刚写入的数据可能丢失。如果是日志，那么重启时无法恢复系统状态。

    解决：一般情况下，Hypertable系统的存储基于Hadoop文件系统，数据和日志都写入HDFS.而在改进后的Hypertable系统中我们采用了不同的存储方式：数据写HDFS,日志写Local FS.

    较之本地文件系统Ext2等，HDFS的稳定性还是略逊一些，在Hypertable的实际运维过程中，我们也遇到过Hypertable向Hadoop写入数据失败的情况。鉴于日志的重要性，我们选择将日志写入可靠性更高的本地文件系统，这样即使Hadoop写文件时出现问题，也可以通过重放本地日志来恢复Hypertable系统状态。

    改进后的Hypertable集群发生故障时，有以下几种处理场景。

    写日志故障：Range Server在写日志时（CommitLog等）发生错误，可能是本地磁盘故障。此时日志的完整性不能得到保证，需要在Range Server写日志的相关操作上附加额外的例外处理。日志写例外将触发Range Server执行一次OFFLINE操作，即在日志完整性不能保证的前提下，尽快保证数据的完整性和一致性，之后再人工参与后续的恢复处理。

    写数据故障：Range Server故障非日志操作引起的，可能由系统Bug导致，也可能是Hadoop写数据文件失败。此时日志的完整性有保障，可以直接执行SHUTDOWN操作，关闭各个Range Server.待Bug解决或Hadoop恢复后，重启Hypertable重放日志即可恢复集群状态和数据。

    以上提到半自动容错机制的两条路线分别保证了“日志- | 数据+”和“日志+ | 数据-”两种故障情况下集群数据的完整性和一致性。那么有没有“日志- | 数据-”的情况，极端情况下可能出现Hadoop写数据文件失败和某Data Node（Range Server）硬盘故障同时发生，此时系统将不可避免地丢失数据，我们只能通过上层应用回滚重放的方式来恢复系统数据。

 

优化Hypertable系统随机性能 图

Hypertable内存优化 图

Hypertable的安全停机策略

Hypertable的分裂日志策略

Hypertable高可用改进架构 图

Hypertable与HBase业务应用比对 图
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。