[
https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732869#comment-13732869
]
Lars Hofhansl commented on HBASE-7709:
--------------------------------------
Reading back through the comments here. How about we follow Ted's approach.
Instead of writing a boolean we write the number of hops into the HLogKey. 0
will still be interpreted as false in the old code, >0 as true. Thus we can
store the number hops and still not break the existing code (although the code
would not be able to stop the bouncing).
In our Salesforce scenario we would limit the hop count to 3 and would be able
to support our setup that way.
Yet another option is to make this configurable. At this point we're still able
to fully bounce our clusters. So we can do the hop count and optionally (per a
config option) store the full path, this might even be applicable to trunk as
the user now has the choice between limiting loops to some limit with little
extra storage or be precise at the expense of more storage.
> 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
