diff --git src/main/docbkx/book.xml src/main/docbkx/book.xml
index 00c5041..41a4f0b 100644
--- src/main/docbkx/book.xml
+++ src/main/docbkx/book.xml
@@ -3011,6 +3011,205 @@ ctime = Sat Jun 23 11:13:40 PDT 2012
+
+ Region State Transition
+ HBase maintains a state for each region and persists the state in META. The state
+ of the META region itself is persisted in ZooKeeper. You can see the states of regions
+ in transition in the Master web UI. Following is the list of possible region
+ states.
+
+
+ Possible Region States
+
+ OFFLINE: the region is offline and not opening
+
+
+ OPENING: the region is in the process of being opened
+
+
+ OPEN: the region is open and the region server has notified the master
+
+
+ FAILED_OPEN: the region server failed to open the region
+
+
+ CLOSING: the region is in the process of being closed
+
+
+ CLOSED: the region server has closed the region and notified the master
+
+
+ FAILED_CLOSE: the region server failed to close the region
+
+
+ SPLITTING: the region server notified the master that the region is
+ splitting
+
+
+ SPLIT: the region server notified the master that the region has finished
+ splitting
+
+
+ SPLITTING_NEW: this region is being created by a split which is in
+ progress
+
+
+ MERGING: the region server notified the master that this region is being merged
+ with another region
+
+
+ MERGED: the region server notified the master that this region has been
+ merged
+
+
+ MERGING_NEW: this region is being created by a merge of two regions
+
+
+
+
+ Region State Transitions
+
+
+
+
+
+ This graph shows all allowed transitions a region can undergo. In the graph,
+ each node is a state. A node has a color based on the state type, for readability.
+ A directed line in the graph is a possible state transition.
+
+
+
+
+
+ Graph Legend
+
+ Peru: Offline state, a special state that can be transient (after closed before
+ opening), terminal (regions of disabled tables), or initial (regions of newly
+ created tables)
+
+ Palegreen: Online state that regions can serve requests
+
+ Lightblue: Transient states
+
+ Red: Failure states that need OPS attention
+
+ Gold: Terminal states of regions split/merged
+
+ Grey: Initial states of regions created through split/merge
+
+
+
+ Region State Transitions Explained
+
+ The master moves a region from OFFLINE to
+ OPENING state and tries to assign the region to a region
+ server. The region server may or may not have received the open region request. The
+ master retries sending the open region request to the region server until the RPC
+ goes through or the master runs out of retries. After the region server receives the
+ open region request, the region server begins opening the region.
+
+
+ If the master is running out of retries, the master prevents the region server
+ from opening the region by moving the region to CLOSING state and
+ trying to close it, even if the region server is starting to open the region.
+
+
+ After the region server opens the region, it continues to try to notify the
+ master until the master moves the region to OPEN state and
+ notifies the region server. The region is now open.
+
+
+ If the region server cannot open the region, it notifies the master. The master
+ moves the region to CLOSED state and tries to open the region on
+ a different region server.
+
+
+ If the master cannot open the region on any of a certain number of regions, it
+ moves the region to FAILED_OPEN state, and takes no further
+ action until an operator intervenes from the HBase shell, or the server is
+ dead.
+
+
+ The master moves a region from OPEN to
+ CLOSING state. The region server holding the region may or may
+ not have received the close region request. The master retries sending the close
+ request to the server until the RPC goes through or the master runs out of
+ retries.
+
+
+ If the region server is not online, or throws
+ NotServingRegionException, the master moves the region to
+ OFFLINE state and re-assigns it to a different region
+ server.
+
+
+ If the region server is online, but not reachable after the master runs out of
+ retries, the master moves the region to FAILED_CLOSE state and
+ takes no further action until an operator intervenes from the HBase shell, or the
+ server is dead.
+
+
+ If the region server gets the close region request, it closes the region and
+ notifies the master. The master moves the region to CLOSED state
+ and re-assigns it to a different region server.
+
+
+ Before assigning a region, the master moves the region to
+ OFFLINE state automatically if it is in
+ CLOSED state.
+
+
+ When a region server is about to split a region, it notifies the master. The
+ master moves the region to be split from OPEN to
+ SPLITTING state and add the two new regions to be created to
+ the region server. These two regions are in SPLITING_NEW state
+ initially.
+
+
+ After notifying the master, the region server starts to split the region. Once
+ past the point of no return, the region server notifies the master again so the
+ master can update the META. However, the master does not update the region states
+ until it is notified by the server that the split is done. If the split is
+ successful, the splitting region is moved from SPLITTING to
+ SPLIT state and the two new regions are moved from
+ SPLITTING_NEW to OPEN state.
+
+
+ If the split fails, the splitting region is moved from
+ SPLITTING back to OPEN state, and the two
+ new regions which were created are moved from SPLITTING_NEW to
+ OFFLINE state.
+
+
+ When a region server is about to merge two regions, it notifies the master
+ first. The master moves the two regions to be merged from OPEN to
+ MERGINGstate, and adds the new region which will hold the
+ contents of the merged regions region to the region server. The new region is in
+ MERGING_NEW state initially.
+
+
+ After notifying the master, the region server starts to merge the two regions.
+ Once past the point of no return, the region server notifies the master again so the
+ master can update the META. However, the master does not update the region states
+ until it is notified by the region server that the merge has completed. If the merge
+ is successful, the two merging regions are moved from MERGING to
+ MERGED state and the new region is moved from
+ MERGING_NEW to OPEN state.
+
+
+ If the merge fails, the two merging regions are moved from
+ MERGING back to OPEN state, and the new
+ region which was created to hold the contents of the merged regions is moved from
+ MERGING_NEW to OFFLINE state.
+
+
+ For regions in FAILED_OPEN or FAILED_CLOSE
+ states , the master tries to close them again when they are reassigned by an
+ operator via HBase Shell.
+
+
+
+