Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
We need to integrate the idea of RMap (Global Region Locator) into HBase.
RMap:
In Hydrabase, we wanted to avoid having special tables that require to be online and available, before other servers can start processing their regions. To this end, in hydrabase, we use a notion of RMap — that tells the servers which regions to open; and also servers as a look up place for the clients to discover the set of servers handling a particular region.
This RMap is stored in a well known path, as specified in the configuration. Upon initialization, RegionServers read this file and determine the set of regions that it needs to open; and the set of peers that it expects to hear from for each of those regions.
Since RMap is stored in HDFS, the only way to change it is to create a new HDFS file and update the servers about it. This is intended to be a not-so-common operation; however, this may be required when a new machine joins the service, or an existing machine needs to be taken away for a significant amount of time to perform maintenance.
We run a daemon, every 15 minutes, (currently in the master) to determine the set of machines going to repair and vice versa; and update the RMap accordingly.
1. In the current hydraBase model, updating the RMap is done by a single daemon; while every region server individually reads and updates itself accordingly.
2. OSS HBase seems to be using a model where a dedicated master/server manager is responsible for coordinating the regions that should be opened/served by each region server. Region servers simply follow the instructions received from the server manager.
With respect to integrating both. We plan to use the servermanager to read the RMap and coordinate the region opens on various regionservers.
Storing the RMap:
1) RMap can either still be stored as a HDFS file, that will be read by the ServerManager/Master to assign regions. or,
2) We can integrate Rmap into the hbase:meta. So, it works similar to the favoured nodes etc.
our current implementation is closer to 1. But, 2 might be a cleaner solution going forward. However, for a multiple dc deployment, we would have to ensure that we just have one meta across all the deployments.