[
https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15785936#comment-15785936
]
stack commented on HBASE-9465:
------------------------------
bq. For compatibility I didn't want to change this column so I create a new
one. And a independent family(rep_barrier) can prevent read too much data when
we only want to read info family.
Ok. Can we get rid of info:seqnumDuringOpen then? Or we can't because the
facility added here is optional, not always enabled?
bq. We save position for each WAL files in ZK(of course we have HBASE-15867
now). For serial replication we save position for each region in meta. Two
different positions.
Oh. I didn't get that. Maybe bring it out in code if you have not done so
already. This is important distinction. Thanks.
bq. If I am not wrong, openSeq is the max sequence +1 , and the first log's
sequence after opening is openSeq+1, so in fact we will not have a log in WAL
whose seq is openSeq.
Sounds right. My concern is depending on this 'math' is tenuous. It could
change. Would be good if this feature 'broke' a unit test or something if the
math ever changed to underline the interdependency between your feature and
this cryptic addition around region open (sorry if stating obvious).
Ditto for depending on splits bringing up daughters on same node.
bq. These days I am working on this to enable this feature in our production
cluster, maybe there will be something need to improved. Hope I can say this
feature is stable when 1.4 release
Good stuff.
Thanks [~yangzhe1991]
> Push entries to peer clusters serially
> --------------------------------------
>
> Key: HBASE-9465
> URL: https://issues.apache.org/jira/browse/HBASE-9465
> Project: HBase
> Issue Type: New Feature
> Components: regionserver, Replication
> Affects Versions: 2.0.0, 1.4.0
> Reporter: Honghua Feng
> Assignee: Phil Yang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-9465-branch-1-v1.patch,
> HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch,
> HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch,
> HBASE-9465-branch-1-v4.patch, HBASE-9465-v1.patch, HBASE-9465-v2.patch,
> HBASE-9465-v2.patch, HBASE-9465-v3.patch, HBASE-9465-v4.patch,
> HBASE-9465-v5.patch, HBASE-9465-v6.patch, HBASE-9465-v6.patch,
> HBASE-9465-v7.patch, HBASE-9465-v7.patch, HBASE-9465.pdf
>
>
> 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
(v6.3.4#6332)
