HMaster
is the implementation of the Master Server. The Master server
is responsible for monitoring all RegionServer instances in the cluster, and is
the interface for all metadata changes. In a distributed cluster, the Master typically runs on the Section 9.9.1, “NameNode”[21]
If run in a multi-Master environment, all Masters compete to run the cluster. If the active Master loses its lease in ZooKeeper (or the Master shuts down), then then the remaining Masters jostle to take over the Master role.
A common dist-list question is what happens to an HBase cluster when the Master goes down. Because the HBase client talks directly to the RegionServers, the cluster can still function in a "steady state." Additionally, per Section 9.2, “Catalog Tables” ROOT and META exist as HBase tables (i.e., are not resident in the Master). However, the Master controls critical functions such as RegionServer failover and completing region splits. So while the cluster can still run for a time without the Master, the Master should be restarted as soon as possible.
The methods exposed by HMasterInterface
are primarily metadata-oriented methods:
For example, when the HBaseAdmin
method disableTable
is invoked, it is serviced by the Master server.
The Master runs several background threads:
Periodically, and when there are no regions in transition, a load balancer will run and move regions around to balance the cluster's load. See Section 2.5.3.1, “Balancer” for configuring this property.
See Section 9.7.2, “Region-RegionServer Assignment” for more information on region assignment.
Periodically checks and cleans up the .META. table. See Section 9.2.2, “META” for more information on META.
[21] J Mohamed Zahoor goes into some more detail on the Master Architecture in this blog posting, HBase HMaster Architecture .