[
https://issues.apache.org/jira/browse/HBASE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099030#comment-13099030
]
[email protected] commented on HBASE-2195:
------------------------------------------------------
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/Put.java,
line 666
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38150#file38150line666>
bq. >
bq. > Hmm.. there is an fb patch that gives Get/Delete, etc. a common
heritage. Let me dig it up and commit so you can put this common code there.
I was thinking about this. Then I thought the code duplication is not
significant enough. But now I realize Put and Delete already have a *lot* in
common that could be factored out in addition to this.
A common superclass maybe "Mutation" would be nice.
I can make that change too, depending on how good the FB code is. Maybe in a
separate jira?
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java,
line 1400
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38152#file38152line1400>
bq. >
bq. > What is happening here Lars? Are we passing the clusterid from the
HRegionServer down to the WAL by writing it into the Delete or Put? Do we have
to do that? Can we not pass the clusterid to the WAL directly when
HRegionServer creates one?
bq. >
bq. > On above, nvm, I think I figure out why you do it this way later.
Yes :)
In a ring the Cluster Id needs to be passed on to the next link link.
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java,
line 1001
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38153#file38153line1001>
bq. >
bq. > Yeah, can't we pass the cluserid in on the HLog constructor rather
than per append or do we need to allow for different clusterids coming in via
append?
Ok.. I'll add a new constructor, then we won't need to call the setter.
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogKey.java,
line 232
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38154#file38154line232>
bq. >
bq. > We could have read garbage that happened to be <0? But yeah, this
is going to go out with new major version and we'll just pronounce that it will
not be able to read old WALs (this we've said in the past)
bq. >
bq. > Why not VersionedWritable since it does this version stuff for you?
This was a good idea from Ted.
The first entry in HLogKey is the encodedRegionName which is written by
Bytes.writeByteArray.
The first byte (or two bytes) encode the length of the array.
So we read that first. If the length is < 0 we know it couldn't have been a
valid HLogKey, and hence it must be a new one and this is the now the version.
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogKey.java,
line 235
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38154#file38154line235>
bq. >
bq. > Why double read of vint? Is this how you do vints?
This one is now the length encodedRegionName
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/HConstants.java,
line 374
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38148#file38148line374>
bq. >
bq. > This is good.
bq. >
bq. > One thought is if these new constants -- the key name and the
default cluster id -- belong in the general HConstants. Are they used across
packages? If so, then this is the place for them. Otherwise, I'd say put them
in replication and then they'll have the replication class prefix when referred
too which will give them some added context. No biggie. I'm just reacting
against this fat HConstants.
I think DEFAULT_CLUSTER_ID belongs here.
CLUSTER_ID_ATTR should go somewhere else I agree. Best would be that common
superclass to Get and Put you mention below.
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java,
line 84
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38151#file38151line84>
bq. >
bq. > Is this needed?
Nope that was used outside of the constructor :)
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogKey.java,
line 182
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38154#file38154line182>
bq. >
bq. > Yeah, if the clusterids are different, i'd think the edits are
different? That looks like oversight in original code.
I was not sure here, what does it means for two log keys to be different. I
just noticed that he cluster id was missing.
We seems to use this specifically for sorting, maybe HLogKey even with
different cluster id need to order the same?
bq. On 2011-09-07 06:01:09, Michael Stack wrote:
bq. >
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java,
line 709
bq. > <https://reviews.apache.org/r/1730/diff/2/?file=38155#file38155line709>
bq. >
bq. > How is this going to be done now? Where do we get cluserid?
What ZooKeeper stores is now no longer considered a cluster id, but just a
local numbering scheme for the ZNodes.
The actual cluster UUID of the sink is read from sink's zookeeper in the main
loop in ReplicationSource
- Lars
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1730/#review1780
-----------------------------------------------------------
On 2011-09-06 23:16:48, Lars Hofhansl wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1730/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-09-06 23:16:48)
bq.
bq.
bq. Review request for hbase, Ted Yu, Michael Stack, and Jean-Daniel Cryans.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. For Master <-> Master replication (as well as cycles > 2) a replication
sink needs to keep track who is was the originator of a change and
bq. (1) do not replicate this data back to the originator and
bq. (2) pass that information on to the next link in a cycle > 2
bq.
bq. In order to do that, HlogKeys read from the WAL are tagged with the
Cluster UUID at the ReplicationSource before the logs are shipped to the Sink.
The sink writes the Cluster UUID into the WAL log (in HlogKey, so only once per
edit). If the sink is also source for yet another sink the ClusterUUID is
retained in the HLogKeys read from the local WAL and passed on to the sink.
bq.
bq.
bq. This addresses bug HBASE-2195.
bq. https://issues.apache.org/jira/browse/HBASE-2195
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/HConstants.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/Delete.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/Put.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogKey.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
1165864
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/replication/TestMasterReplication.java
PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1730/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. All tests pass.
bq. New test: TestMasterReplication (which tests Master <-> Master, but no
cycles > 2, yet), also passes.
bq. Manually tested a cycle between 3 clusters.
bq.
bq.
bq. Thanks,
bq.
bq. Lars
bq.
bq.
> 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
> Assignee: Lars Hofhansl
> Attachments: 2195-v5.txt, 2195-v6.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
