[
https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732750#comment-13732750
]
Jeffrey Zhong commented on HBASE-7709:
--------------------------------------
I think for 0.95 and onwards, we should store relay cluster ids along
replication path in HLogKey to solve the issue . Since the list of replay
cluster ids is added into each WALEdit, the storage & network traffic overhead
isn't trivial when we have a long replication path.
We can use an optimization(mentioned above as adaptive #2). We introduce a 4
byte path checksum field into HLogKey, a cluster only adds its cluster id into
the relay cluster id list when it finds there exist multiple paths from a
single cluster id. In most cases such as a simple replication loop or a acyclic
replication path, the relay cluster id list is empty. The overhead is just the
4 bytes path check sum.
For 0.94, we can either use Lars approach(configuration option
"hbase.enable.cyclic.replication") or introduce a new configuration option
"hbase.replication.reset.clusterid=<clusterId which a user specifies | *>".
Only cluster specified here reset clusterId to itself. When
hbase.replication.reset.clusterid=*, it is equivalent to Lars approach.
In addition, we can leverage existing field HLogKey.writeTime to detect loop in
0.94 if a WALEdit is stale too long for replication(like configurable 30mins).
We can pass the writeTime as an attribute like the way cluster Id is passed
during replication so that we can check the original writeTime to see if we
have a possible infinite loop situation.
Thanks.
> Infinite loop possible in Master/Master replication
> ---------------------------------------------------
>
> Key: HBASE-7709
> URL: https://issues.apache.org/jira/browse/HBASE-7709
> Project: HBase
> Issue Type: Bug
> Components: Replication
> Affects Versions: 0.94.6, 0.95.1
> Reporter: Lars Hofhansl
> Fix For: 0.98.0, 0.95.2, 0.94.12
>
>
> We just discovered the following scenario:
> # Cluster A and B are setup in master/master replication
> # By accident we had Cluster C replicate to Cluster A.
> Now all edit originating from C will be bouncing between A and B. Forever!
> The reason is that when the edit come in from C the cluster ID is already set
> and won't be reset.
> We have a couple of options here:
> # Optionally only support master/master (not cycles of more than two
> clusters). In that case we can always reset the cluster ID in the
> ReplicationSource. That means that now cycles > 2 will have the data cycle
> forever. This is the only option that requires no changes in the HLog format.
> # Instead of a single cluster id per edit maintain a (unordered) set of
> cluster id that have seen this edit. Then in ReplicationSource we drop any
> edit that the sink has seen already. The is the cleanest approach, but it
> might need a lot of data stored per edit if there are many clusters involved.
> # Maintain a configurable counter of the maximum cycle side we want to
> support. Could default to 10 (even maybe even just). Store a hop-count in the
> WAL and the ReplicationSource increases that hop-count on each hop. If we're
> over the max, just drop the edit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
