HBase架构(下)

jieforest

4.2.4 日志清理

如果replication没有开启，master的logs清理线程将会使用用户配置的TTL进行旧logs的删除。当使用replication时，这样是无法工作的，因为被归档的log虽然超过了它们自己的TTL但是仍可能在队列中。因此，需要修改默认行为，在日志超出它的TTL时，清理线程还要查看每个队列看能否找到该log，如果找不到就可以将该log删除。查找过程中它会缓存它找到的那些log，在下次log查找时，它会首先查看缓存。

4.2.5 Region Server故障恢复

只要region servers没有出错，ZooKeeper中的日志记录就不需要添加任何值。不幸的是，它们通常都会出错，这样我们就可以借助ZooKeeper的高可用性和它的语义来帮助我们管理队列的传输。

master集群的所有region servers相互之间都有一个观察者，当其中一个死掉时，其他的都能得到通知。如果某个死掉后，它们就会通过在死掉的region server的znode(该znode也包含它的队列)内创建一个称为lock的znode来进行竞争性选举。最终成功创建了该znode的region server会将所有的队列传输到它自己的znode下(逐个传输因为ZooKeeper并不支持rename操作)当传输完成后就会删掉老的那些。恢复后的队列的znodes将会在死掉的服务器的名称后加上slave集群的id来进行命名。

jieforest

完成之后，master集群的region server会对每个拷贝出的队列创建一个新的source线程。它们中的每一个都会遵守read/filter/ship模式。主要的区别是这些队列不会再有新数据因为它们不再属于它们的新region server，同时意味着当读取者到达最后一个日志的末尾时，队列对应的znode就可以被删除了，同时master集群的region server将会关闭那个replication source。

比如，考虑一个具有3个region servers的master集群，该集群会向一个id为2的单个slave集群进行复制。下面的层次结构代表了znodes在某个时间点上的分布。我们可以看到该region servers的znodes都包含一个具有一个队列的peers znode。这些队列的znodes的在HDFS上的实际文件名称具有如下形式” address,port.timestamp”。

1. /hbase/replication/rs/
   
2. 1.1.1.1,60020,123456780/
   
3.   peers/
   
4.         2/
   
5.           1.1.1.1,60020.1234  (Contains a position)
   
6.           1.1.1.1,60020.1265
   
7. 1.1.1.2,60020,123456790/
   
8.   peers/
   
9.         2/
   
10.           1.1.1.2,60020.1214  (Contains a position)
    
11.           1.1.1.2,60020.1248
    
12.           1.1.1.2,60020.1312
    
13. 1.1.1.3,60020,    123456630/
    
14.   peers/
    
15.         2/
    
16.           1.1.1.3,60020.1280  (Contains a position)
    

复制代码

jieforest

现在我们假设1.1.1.2丢失了它的ZK会话，幸存者将会竞争以创建一个lock，最后1.1.1.3获得了该锁。然后它开始将所有队列传输到它本地的peers znode，同时在原有的名称上填上死掉的服务器的名称。在1.1.1.3清理老的znodes之前，节点分布如下：

1. /hbase/replication/rs/
   
2. 1.1.1.1,60020,123456780/
   
3.   peers/
   
4.         2/
   
5.           1.1.1.1,60020.1234  (Contains a position)
   
6.           1.1.1.1,60020.1265
   
7. 1.1.1.2,60020,123456790/
   
8.   lock
   
9.   peers/
   
10.         2/
    
11.           1.1.1.2,60020.1214  (Contains a position)
    
12.           1.1.1.2,60020.1248
    
13.           1.1.1.2,60020.1312
    
14. 1.1.1.3,60020,123456630/
    
15.   peers/
    
16.         2/
    
17.           1.1.1.3,60020.1280  (Contains a position)
    
18. 
    
19.         2-1.1.1.2,60020,123456790/
    
20.           1.1.1.2,60020.1214  (Contains a position)
    
21.           1.1.1.2,60020.1248
    
22.           1.1.1.2,60020.1312
    

复制代码

jieforest

一段时间后，但在1.1.1.3结束来自1.1.1.2的最后一个HLog的复制之前，我们假设它也死掉了(而且某些之前创建的新logs还在正常队列中)。最后一个region server会尝试锁住1.1.1.3的znode然后开始传输所有的队列。新的节点分布如下：

1. /hbase/replication/rs/
   
2. 1.1.1.1,60020,123456780/
   
3.   peers/
   
4.         2/
   
5.           1.1.1.1,60020.1378  (Contains a position)
   
6. 
   
7.         2-1.1.1.3,60020,123456630/
   
8.           1.1.1.3,60020.1325  (Contains a position)
   
9.           1.1.1.3,60020.1401
   
10. 
    
11.         2-1.1.1.2,60020,123456790-1.1.1.3,60020,123456630/
    
12.           1.1.1.2,60020.1312  (Contains a position)
    
13. 1.1.1.3,60020,123456630/
    
14.   lock
    
15.   peers/
    
16.         2/
    
17.           1.1.1.3,60020.1325  (Contains a position)
    
18.           1.1.1.3,60020.1401
    
19. 
    
20.         2-1.1.1.2,60020,123456790/
    
21.           1.1.1.2,60020.1312  (Contains a position)
    

复制代码

jieforest

Replication 目前还是一个处于实验阶段的feature。在将它应用到你的使用场景中时需要进行仔细地评估。

[83] See "B+ trees" on Wikipedia
[84] See LSM-Tree, O'Neil et al., 1996
[85] From "Open Source Search" by Doug Cutting, Dec. 05, 2005.
[86] See the JIRA issue HADOOP-3315 for details.
[87] For the term itself please read Write-Ahead Logging on Wikipedia.
[88] Subsequently they are referred to interchangeably as root table and meta table respectively, since for example
"-ROOT-"
is how the table is actually named in HBase and calling it root table is stating its purpose.
[89] See the online manual for details.

jieforest

over.