diff --git a/src/site/xdoc/replication.xml b/src/site/xdoc/replication.xml index 8233520eb70..b42e252003b 100644 --- a/src/site/xdoc/replication.xml +++ b/src/site/xdoc/replication.xml @@ -163,6 +163,157 @@ This section describes in depth how each of replication's internal features operate.

+
+

+ HBase replication maintains all of its state in Zookeeper. By default, this state is + contained in the base znode: +

+ 
+                /hbase/replication
+
+

+ There are three major child znodes in the base replication znode: +

+

+
+

+ The state znode indicates whether or not replication is enabled on the cluster + corresponding to this zookeeper quorum. It does not have any child znodes and simply + contains a boolean value. This value is initialized on startup based on the + hbase.replication config parameter in the hbase-site.xml file. The status + value is read/maintained by the ReplicationZookeeper.ReplicationStatusTracker + class. It is also cached locally using an AtomicBoolean in the ReplicationZookeeper + class. This value can be changed on a live cluster using the stop_replication + command available through the hbase shell. +

+ 
+                /hbase/replication/state [VALUE: true]
+
+
+
+

+ The peers znode contains a list of all peer replication clusters and the + current replication state of those clusters. It has one child peer znode + for each peer cluster. The peer znode is named with the cluster id provided + by the user in the HBase shell. The value of the peer znode contains + the peers cluster key provided by the user in the HBase Shell. The cluster key + contains a list of zookeeper nodes in the clusters quorum, the client port for the + zookeeper quorum, and the base znode for HBase + (i.e. “zk1.host.com,zk2.host.com,zk3.host.com:2181:/hbase”). +

+ 
+                /hbase/replication/peers
+                    /1 [Value: zk1.host.com,zk2.host.com,zk3.host.com:2181:/hbase]
+                    /2 [Value: zk5.host.com,zk6.host.com,zk7.host.com:2181:/hbase]
+
+

+ Each of these peer znodes has a child znode that indicates whether or not + replication is enabled on that peer cluster. These peer-state znodes do not + have child znodes and simply contain a boolean value (i.e. ENABLED or DISABLED). + This value is read/maintained by the ReplicationPeer.PeerStateTracker class. + It is also cached locally using an AtomicBoolean in the ReplicationPeer class. +

+ 
+                /hbase/replication/peers
+                    /1/peer-state [Value: ENABLED]
+                    /2/peer-state [Value: DISABLED]
+
+
+
+

+ The rs znode contains a list of all outstanding HLog files in the cluster + that need to be replicated. The list is divided into a set of queues organized by + region server and the peer cluster the region server is shipping the HLogs to. The + rs znode has one child znode for each region server in the cluster. The child + znode name is simply the regionserver name (a concatenation of the region server’s + hostname, client port and start code). These region servers could either be dead or alive. +

+ 
+                /hbase/replication/rs
+                    /hostname.example.org,6020,1234
+                    /hostname2.example.org,6020,2856
+
+

+ Within each region server znode, the region server maintains a set of HLog replication + queues. Each region server has one queue for every peer cluster it replicates to. + These queues are represented by child znodes named using the cluster id of the peer + cluster they represent (see the peer znode section). +

+ 
+                /hbase/replication/rs
+                    /hostname.example.org,6020,1234
+                        /1
+                        /2
+
+

+ Each queue has one child znode for every HLog that still needs to be replicated. + The value of these HLog child znodes is the latest position that has been replicated. + This position is updated every time a HLog entry is replicated. +

+ 
+                /hbase/replication/rs
+                    /hostname.example.org,6020,1234
+                        /1
+                            23522342.23422 [VALUE: 254]
+                            12340993.22342 [VALUE: 0]
+
+
+
+
+
+

+ All of the base znode names are configurable through parameters: +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
ParameterDefault Value
zookeeper.znode.parent/hbase
zookeeper.znode.replicationreplication
zookeeper.znode.replication.peerspeers
zookeeper.znode.replication.peers.statepeer-state
zookeeper.znode.replication.rsrs
+

+ The default replication znode structure looks like the following: +

+ 
+                /hbase/replication/state
+                /hbase/replication/peers/{peerId}/peer-state
+                /hbase/replication/rs
+
+
+
+ +
+

When a master cluster RS initiates a replication source to a slave cluster,