[
https://issues.apache.org/jira/browse/HBASE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096956#comment-13096956
]
stack commented on HBASE-2195:
------------------------------
bq. Can I just how change HLogKey is read or written? It seems that this was
done before (when byte cluster id was added), but I don't see how that would
just work - it only guards again EOFException in readFields.
Yes. You can. While you are at it, can you make it versioned? Have it
subclass this,
http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/io/VersionedWritable.html,
instead of just Writable.
This change will be included in 0.92, right? Our next major version. We need
to state this in stone somewhere but just as (currently), rpc versioning makes
it so old versions of hbase can not talk across a major version upgrade,
similar, we can say that new major version cannot read old version WAL logs.
If you have HLogKey subclass VersionedWritable, going forward, we'll have some
of evolving the HLogKey in a manner in which new HLogKey versions will be able
to identify and deserialize old objects into new.
bq. I assume it would be worth going through the trouble of not storing those
16 bytes of UUID when replication is not enabled
Yeah, if you can.
So, the patch will not include being able to map from single byte cluserid to
uuid clusterid? That'd be done elsewhere?
> 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.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
