Package org.apache.hadoop.hbase.rsgroup

Class RSGroupInfoManagerImpl

java.lang.Object
org.apache.hadoop.hbase.rsgroup.RSGroupInfoManagerImpl
All Implemented Interfaces:
RSGroupInfoManager
@Private final class RSGroupInfoManagerImpl extends Object implements RSGroupInfoManager
This is an implementation of RSGroupInfoManager which makes use of an HBase table as the persistence store for the group information. It also makes use of zookeeper to store group information needed for bootstrapping during offline mode.

Admin-managed and auto-managed groups

An admin-managed group is a non-default group that is not regex-governed (see hbase.rsgroup.regex.<group>). Its servers are set by an administrator and are stored in hbase:rsgroup and ZooKeeper. A group whose regex is invalid is admin-managed until the regex is fixed. In that time the servers that the group holds in memory count as admin-managed when the membership is computed (resolveRegexBasedRSGroupMembership). After a master restart the group holds only what was stored at the last flush.

An auto-managed group is 'default' or a regex-governed group. Its servers are computed from the live servers and, while the regex is valid, are not stored in hbase:rsgroup and ZooKeeper.

Auto-managed groups exist to make RSGroup work with auto-scaling when HBase runs in a cloud environment such as AWS or GCP. An admin-managed group does not give the elasticity that automatic upscaling and downscaling need: each new RegionServer must be moved into the group by hand. It fits a fixed number of RegionServers, for example to host internal system tables like hbase:meta and hbase:namespace. End user facing tables must be placed on an elastic group, so RegionServers join and leave it automatically. That is the need for auto-managed groups.

Concurrency

RSGroup state is kept locally in Maps. There is a rsgroup name to cached RSGroupInfo Map at RSGroupInfoManagerImpl.RSGroupInfoHolder.groupName2Group. These Maps are persisted to the hbase:rsgroup table (and cached in zk) on each modification.

Mutations on state are synchronized but reads can continue without having to wait on an instance monitor, mutations do wholesale replace of the Maps on update -- Copy-On-Write; the local Maps of state are read-only, just-in-case (see flushConfig).

Reads must not block else there is a danger we'll deadlock.

Clients of this class, the RSGroupAdminEndpoint for example, want to query and then act on the results of the query modifying cache in zookeeper without another thread making intermediate modifications. These clients synchronize on the 'this' instance so no other has access concurrently. Reads must be able to continue concurrently.