Author: jdcryans
Date: Wed Dec 15 23:32:13 2010
New Revision: 1049746
URL: http://svn.apache.org/viewvc?rev=1049746&view=rev
Log:
HBASE-3363 ReplicationSink should batch delete
doc fixes for replication
Modified:
hbase/branches/0.90/CHANGES.txt
hbase/branches/0.90/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
hbase/branches/0.90/src/site/xdoc/replication.xml
Modified: hbase/branches/0.90/CHANGES.txt
URL:
http://svn.apache.org/viewvc/hbase/branches/0.90/CHANGES.txt?rev=1049746&r1=1049745&r2=1049746&view=diff
==============================================================================
--- hbase/branches/0.90/CHANGES.txt (original)
+++ hbase/branches/0.90/CHANGES.txt Wed Dec 15 23:32:13 2010
@@ -750,6 +750,7 @@ Release 0.90.0 - Unreleased
HBASE-3358 Recovered replication queue wait on themselves when terminating
HBASE-3359 LogRoller not added as a WAL listener when replication is
enabled
HBASE-3360 ReplicationLogCleaner is enabled by default in 0.90 -- causes
NPE
+ HBASE-3363 ReplicationSink should batch delete
IMPROVEMENTS
Modified:
hbase/branches/0.90/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
URL:
http://svn.apache.org/viewvc/hbase/branches/0.90/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java?rev=1049746&r1=1049745&r2=1049746&view=diff
==============================================================================
---
hbase/branches/0.90/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
(original)
+++
hbase/branches/0.90/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
Wed Dec 15 23:32:13 2010
@@ -517,6 +517,7 @@ public class ReplicationZookeeper {
ZKUtil.createAndWatch(this.zookeeper, p,
Bytes.toBytes(rsServerNameZnode));
} catch (KeeperException e) {
LOG.info("Failed lock other rs", e);
+ return false;
}
return true;
}
Modified: hbase/branches/0.90/src/site/xdoc/replication.xml
URL:
http://svn.apache.org/viewvc/hbase/branches/0.90/src/site/xdoc/replication.xml?rev=1049746&r1=1049745&r2=1049746&view=diff
==============================================================================
--- hbase/branches/0.90/src/site/xdoc/replication.xml (original)
+++ hbase/branches/0.90/src/site/xdoc/replication.xml Wed Dec 15 23:32:13 2010
@@ -89,7 +89,7 @@
</p>
<p>
In a separate thread, the edit is read from the log (as part of a
batch)
- and only the KVs that are replicable are kept (that is, that are part
+ and only the KVs that are replicable are kept (that is, that they
are part
of a family scoped GLOBAL in the family's schema and non-catalog so
not
.META. or -ROOT-). When the buffer is filled, or the reader hits the
end of the file, the buffer is sent to a random region server on the
@@ -143,7 +143,7 @@
<p>
When a master cluster RS initiates a replication source to a slave
cluster,
it first connects to the slave's ZooKeeper ensemble using the
provided
- cluster key (taht key is composed of the value of
hbase.zookeeper.quorum,
+ cluster key (that key is composed of the value of
hbase.zookeeper.quorum,
zookeeper.znode.parent and hbase.zookeeper.property.clientPort). It
then scans the "rs" directory to discover all the available sinks
(region servers that are accepting incoming streams of edits to
replicate)
@@ -166,7 +166,7 @@
are created), and each of these contain a queue
of HLogs to process. Each of these queues will track the HLogs
created
by that RS, but they can differ in size. For example, if one slave
- cluster becomes unavailable for some time then the HLogs cannot be,
+ cluster becomes unavailable for some time then the HLogs should not
be deleted,
thus they need to stay in the queue (while the others are processed).
See the section named "Region server failover" for an example.
</p>
@@ -371,7 +371,7 @@
bulk copy data.
</p>
</section>
- <section name="Is it a mistake that WALEdit doesn't carry Put and Delete
objects, that we have to reinstantiate not only replicating but when replaying
edits?">
+ <section name="Is it a mistake that WALEdit doesn't carry Put and Delete
objects, that we have to reinstantiate not only when replicating but when
replaying edits also?">
<p>
Yes, this behavior would help a lot but it's not currently available
in HBase (BatchUpdate had that, but it was lost in the new API).
