[
https://issues.apache.org/jira/browse/HBASE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097253#comment-13097253
]
Lars Hofhansl commented on HBASE-2195:
--------------------------------------
@Ted
re HLogKey: Correct, it does not extend VersionWritable. This way I can make
sure that 0.92 can read all log files that 0.90.x could read (currently 0.90.x
might fail on earlier log files, but that damage is already done)
If we're not concerned about this, I agree using VersionedWritable is better.
re byte cluster id to UUID: What I am saying is that *we do not need a
mapping*. A replication source used some random numbering scheme (that we can
change at any given time). When the log is replicated it is tagged the correct
UUID. And as an *optimization* a source also retrieves the sink's cluster UUID
via ZK to avoid shipping logs if not needed.
With some restructuring (that I don't think should go into 0.92), the byte
cluster id can just go away. That involves backwards compatibility needs in how
to read existing ZNode entries and rethinking how a replication source would
maintain its sink(s).
re readByteArray: I think I am missing something. As the old logs can have any
byte combination at the beginning, we'll always potentially run into problems.
So either we break compatibility
once to start using VersionedWritable now, or use the former cluster id byte
going forward and that would provide backwards compatibility in 0.92.
> Support cyclic replication
> --------------------------
>
> Key: HBASE-2195
> URL: https://issues.apache.org/jira/browse/HBASE-2195
> Project: HBase
> Issue Type: Sub-task
> Components: replication
> Reporter: Jean-Daniel Cryans
> Attachments: 2195-v5.txt, 2195.txt
>
>
> We need to support cyclic replication by using the cluster id of each HlogKey
> and stop replicating when it goes back to the original cluster.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
