[
https://issues.apache.org/jira/browse/HBASE-9888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815111#comment-13815111
]
Dave Latham commented on HBASE-9888:
------------------------------------
{quote}
So in your case the replication was enabled at the master cluster and the table
cf was also replication enabled (scope>0) At a later point u added a peer to
the master and you can see the older edits also getting replicated. The
scenario is correct?
{quote}
Yes, that's correct.
{quote}
Did you consider writing a replication controller to be deployed on the sink
cluster ?
{quote}
Nope, didn't consider it because we weren't aware of the issue ahead of time.
We ended up resolving the infinite replication cycle by introducing a patch to
allow configuring specific cluster UUIDs whose edits should not be replication.
For the future, I'd prefer a built in improvement.
{quote}
In 0.94, HLogKey has a writeTime and we could seek in the current WAL until we
find an edit that's been written after the source was created. It's still fuzzy
since the time that each source actually gets created will differ for each RS,
but at least you wouldn't start replicating old edits.
{quote}
That sounds great. Is that 0.94 only or do the newer versions also have it?
Do you have an idea where the minimum timestamp would be generated? Would it
work to just do it in each RS when the ReplicationSource on that RS is created
(in the mode for add_peer)?
Alternatively, should each RS roll its HLog when creating a new peer?
> HBase replicates edits written before the replication peer is created
> ---------------------------------------------------------------------
>
> Key: HBASE-9888
> URL: https://issues.apache.org/jira/browse/HBASE-9888
> Project: HBase
> Issue Type: Bug
> Reporter: Dave Latham
>
> When creating a new replication peer the ReplicationSourceManager enqueues
> the currently open HLog to the ReplicationSource to ship to the destination
> cluster. The ReplicationSource starts at the beginning of the HLog and ships
> over any pre-existing writes.
> A workaround is to roll all the HLogs before enabling replication.
> A little background for how it affected us - we were migrating one cluster in
> a master-master pair. I.e. transitioning from A <\-> B to B <-> C. After
> shutting down writes from A -> B we enabled writes from C -> B. However,
> this replicated some earlier writes that were in C's HLogs that had
> originated in A. Since we were running a version of HBase before HBASE-7709
> those writes then got caught in a infinite replication cycle and bringing
> down region servers OOM because of HBASE-9865.
> However, in general, if one wants to manage what data gets replicated, one
> wouldn't expect that potentially very old writes would be included when
> setting up a new replication link.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
