hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9465) HLog entries are not pushed to peer clusters serially when region-move or RS failure in master cluster
Date Sun, 05 Jun 2016 07:27:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315781#comment-15315781

Phil Yang commented on HBASE-9465:

Can we use hbase:replication instead of hbase:meta for bookkeeping ?
If I am not wrong, HBASE-15583 and HBASE-15867 are using system table to replace ZK implementation,
hbase:replication is used for tracking tasks and queues whose rowkey is not region name. But
in this issue we need a table/cf to save some region level information, and it is convenient
to use hbase:meta to do this because we can merge the updating request and updating region
status to one atomic operation in one table and one row when we open/merge/split a region,
with no extra executing time. 

And this issue can also works well in ZK implementation and can be ported to 1.x branches
even 0.98 (Our production branch is based on 0.98), if we rely on hbase:replication's implementatio,
this patch can only works on the version fixed by HBASE-15583 

> HLog entries are not pushed to peer clusters serially when region-move or RS failure
in master cluster
> ------------------------------------------------------------------------------------------------------
>                 Key: HBASE-9465
>                 URL: https://issues.apache.org/jira/browse/HBASE-9465
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver, Replication
>            Reporter: Honghua Feng
>            Assignee: Phil Yang
> When region-move or RS failure occurs in master cluster, the hlog entries that are not
pushed before region-move or RS-failure will be pushed by original RS(for region move) or
another RS which takes over the remained hlog of dead RS(for RS failure), and the new entries
for the same region(s) will be pushed by the RS which now serves the region(s), but they push
the hlog entries of a same region concurrently without coordination.
> This treatment can possibly lead to data inconsistency between master and peer clusters:
> 1. there are put and then delete written to master cluster
> 2. due to region-move / RS-failure, they are pushed by different replication-source threads
to peer cluster
> 3. if delete is pushed to peer cluster before put, and flush and major-compact occurs
in peer cluster before put is pushed to peer cluster, the delete is collected and the put
remains in peer cluster
> In this scenario, the put remains in peer cluster, but in master cluster the put is masked
by the delete, hence data inconsistency between master and peer clusters

This message was sent by Atlassian JIRA

View raw message