这篇文章主要介绍“HBase中Replication的用法详解”,在日常操作中,相信很多人在HBase中Replication的用法详解问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”HBase中Replication的用法详解”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
Replication:复制,指的是持续的将同一份数据拷贝到多个地方进行存储,是各种存储系统中常见而又重要的一个概念,可以指数据库中主库和从库的复制,也可以指分布式集群中多个集群之间的复制,还可以指分布式系统中多个副本之间的复制。它的难点在于数据通常是不断变化的,需要持续的将变化也反映到多个数据拷贝上,并保证这些拷贝是完全一致的。
通常来说,数据复制到多个拷贝上有如下好处:
多个备份提高了数据的可靠性
通过主从数据库/主备集群之间的复制,来分离OLTP和OLAP请求
提高可用性,即使在单副本挂掉的情况下,依然可以有其他副本来提供读写服务
可扩展,通过增加副本来服务更多的读写请求
跨地域数据中心之间的复制,Client通过读写最近的数据中心来降低请求延迟
HBase中的Replication指的是主备集群间的复制,用于将主集群的写入记录复制到备集群。HBase目前共支持3种Replication,分别是异步Replication、串行Replication和同步Replication。
异步Replication
如果想把HBase的Replication搞清楚,首先需要了解下HBase的架构。
HBase集群是由一组进程组成的,进程按角色分为Master和RegionServer,其中Master负责DDL操作,比如建表、删表,而RegionServer负责DML操作,比如数据的读写操作等。从数据视图上讲,HBase中的Table会按Range切分为多个Region,然后由不同的RegionServer来负责对外提供服务。
RegionServer的内部则主要有BlockCache,MemStore和WAL等几部分组成,需要注意的是每个Region的每个Column Family有自己独享的MemStore,但是BlockCache和WAL则是多个Region共享的。WAL(Write-ahead logging)是数据库中的常用技术,所有的修改在写入数据库之前都需要持久化到WAL中,从而确保了在出现故障的时候,可以从WAL中回放出已经成功写入的数据。
HBase中的Replication也是基于WAL的,其在主集群的每个RegionServer进程内部起了一个叫做ReplicationSource的线程来负责Replication,同时在备集群的每个RegionServer内部起了一个ReplicationSink的线程来负责接收Replication数据。ReplicationSource记录需要同步的WAL队列,然后不断读取WAL中的内容,同时可以根据Replication的配置做一些过滤,比如是否要复制这个表的数据等,然后通过replicateWALEntry这个Rpc调用来发送给备集群的RegionServer,备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作,以batch的形式写入到备集群中。
因为是后台线程异步的读取WAL并复制到备集群,所以这种Replication方式叫做异步Replication,正常情况下备集群收到最新写入数据的延迟在秒级别。
串行Replication
串行Replication指的是:对于某个Region来说,严格按照主集群的写入顺序复制到备集群,其是一种特殊的Replication。同时默认的异步Replication不是串行的,主要原因是Region是可以移动的,比如HBase在进行负载均衡时移动Region。假设RegionA首先在RegionServer1上,然后其被移动到了RegionServer2上,由于异步Replication是存在延迟的,所以RegionA的最后一部分写入记录还没有完全复制到备集群上。在Region移动到RegionServer2之后,其开始接收新的写入请求,并由RegionServer2来复制到备集群,所以在这个时候RegionServer1和RegionServer2会同时向备集群进行复制,而且写入记录复制到备集群的顺序是不确定的。
如上图所示这种极端情况下,还会导致主备集群数据的不一致。比如RegionServer1上最后一个未同步的写入操作是Put,而RegionA被移动到RegionServer2上的第一个写入操作是Delete,在主集群上其写入顺序是先Put后Delete,如果RegionServer2上的Delete操作先被复制到了备集群,然后备集群做了一次Major compaction,其会删除掉这个Delete marker,然后Put操作才被同步到了备集群,因为Delete已经被Major compact掉了,这个Put将永远无法被删除,所以备集群的数据将会比主集群多。
解决这个问题的关键在于需要确保RegionServer2上的新写入操作必须在RegionServer1上的写入操作复制完成之后再进行复制。所以串行Replication引入了一个叫做Barrier的概念,每当Region open的时候,就会写入一个新的Barrier,其值是Region open时读到的最大SequenceId加1。SequenceId是HBase中的一个重要概念,每个Region都有一个SequenceId,其随着数据写入严格递增,同时SequenceId会随着每次写入操作一起写入到WAL中。所以当Region移动的时候,Region会在新的RegionServer重新打开,这时就会写入一个新的Barrier,Region被移动多次之后,就会写入多个Barrier,来将Region的写入操作划分成为多个区间。同时每个Region都维护了一个lastPushedSequenceId,其代表这个Region当前推送成功的最后一个写操作的SequenceId,这样就可以根据Barrier列表和lastPushedSequenceId来判断WAL中的一个写入操作是否能够复制到备集群了。
以上图为例,Pending的写入记录就需要等待lastPushedSequenceId推到Barrier2之后才能开始复制。由于每个区间之间只会有一个RegionServer来负责复制,所以只有和lastPushedSequenceId在同一个区间内的RegionServer才能进行复制,并在复制成功后不断更新lastPushedSequenceId,而在lastPushedSequenceId之后各个区间的RegionServer则需要等待lastPushedSequenceId被推到自己区间的起始Barrier,然后才能开始复制,从而确保了Region的写入操作可以严格按照主集群的写入顺序串行的复制到备集群。
同步Replication
同步Replication是和异步Replication对称的概念,其指的是主集群的写入操作必须被同步的写入到备集群中。异步Replication的最大问题在于复制是存在延迟的,所以在主集群整集群挂掉的情况下,备集群是没有已经写入的完整数据的,对于一致性要求较高的业务来说,是不能把读写完全切到备集群的,因为在这个时候可能存在部分最近写入的数据无法从备集群读到。所以同步Replication的核心思路就是在写入主集群WAL的同时,在备集群上写入一份RemoteWAL,只有同时在主集群的WAL和备集群的RemoteWAL写入成功了,才会返回给Client说写入成功。这样当主集群挂掉的时候,便可以在备集群上根据Remote WAL来回放出来主集群上所有写入记录,从而确保备集群和主集群数据的一致。
需要注意的是,同步Replication是在异步Replication的基础之上的,也就是说异步Replication的复制链路还会继续保留,同时增加了新的写Remote WAL的步骤。对于具体的实现细节来说,首先是增加了一个Sync replication state的概念,其总共有三个状态, 分别是Active,Downgrade Active和Standby。这几个状态的转换关系如下图所示,Standby在提主的时候需要首先提升为Downgrade Active,然后才能提升为Active。但是Active是可以直接降级为Standby的。目前这个状态是保存在ReplicationPeerConfig中的, 其表示一个集群在这个ReplicationPeer中处于哪个状态。
然后实现了一个DualAsyncFSWAL来同时写主集群的WAL和备份集群的Remote WAL。写WAL的操作是对于HDFS的rpc请求,其会有三种结果: 成功,失败或者超时。当超时的时候,对于HBase来说结果是不确定的,即数据有可能成功写入到WAL或Remote WAL里了,也有可能没有。只有同时写成功或者同时写失败的时候,主集群和备集群才会有一样的WAL,如果是主集群写WAL成功,写Remote WAL失败或者超时,这时候主集群WAL里的数据就有可能比备集群的Remote WAL多。相反如果写备集群Remote WAL成功了,而主集群的WAL写失败或者超时了,备集群的Remote WAL里的数据就有可能比主集群多。当两边都超时的时候, 就不确定那边多了。所以同步复制的关键就在于在上述情况下,如何确保主备集群数据的最终一致。即在切换主备集群的时候,Client应该始终从主备集群看到一致的数据。而且在主备没有达到一致的中间状态时,需要一些限制来确保Client没法读到这种中间不一致的结果。所以总结一下就是主备集群最终一致,但对于Client来说是强一致,即成功写入的数据无论主备集群都要一定能读到。具体的实现细节可以参考HBaseCon Asia 2018:HBase at Xiaomi[1]。
对比异步复制来看,同步复制主要是影响的写路径,从我们的测试结果上来看,大概会有14%的性能下降,后续计划在HBASE-20422[2]中进行优化。
自定义Replication Endpoint
除了上述3种Replication之外,HBase还支持插件式的Replication Endpoint,可以自定义Replication Endpoint来实现各种各样的功能。具体到小米来说,我们实现了可以在不同表之间的Replication Endpoint,比如可以将主集群的表A复制到备集群的表B,其应用场景有集群迁移,Namespace更换或者表名更换等。同时为了实现Point-in-time Recovery,我们做了可以同步数据到小米消息队列Talos的Replication Endpoint,当出现需要恢复某个时间点t1的场景时,可以首先找到冷备中距离t1最近的一个的Snapshot进行恢复,然后将消息队列中的数据来回放到t1时间点,从而做到Point-in-time Recovery。
到此,关于“HBase中Replication的用法详解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!