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. + + +
+