The application of "HBase" zookeeper in HBase

Transferred from: http://support.huawei.com/ecommunity/bbs/10242721.html

The application of zookeeper in HBase

The HBase deployment is relatively a larger action that relies on zookeeper Cluster,hadoop HDFS.

The Zookeeper function is:

1, HBase Regionserver to zookeeper registration, provide hbase regionserver status information (whether online).

2, Hmaster start time will be the HBase system table-root-loaded into zookeeper cluster, through zookeeper cluster can get the current system table. META. The regionserver information corresponding to the store.

Zookeeper is the " coordinator " of the HBase cluster. Because of the lightweight nature of zookeeper, we can share multiple hbase clusters with a single zookeeper cluster to conserve a large number of servers. Multiple hbase clusters share the zookeeper cluster by using the same set of IPs, modifying the "zookeeper.znode.parent" attribute of different hbase clusters so that they use different root directories. For example, Cluster1 uses/hbase-c1,cluster2 to use/HBASE-C2, and so on.

The main function of Hmaster is to maintain the system table-root by Hmaster-,. META., records the region change information for Regionserver. It is also responsible for monitoring Regionserver status change information in the current HBase cluster.

HBase Regionserver is used for multiple/individual maintenance region.

Region corresponds to the table partition data maintenance for the HBase data table.

Reference: http://koven2049.iteye.com/blog/1150484

Hbase.zookeeper.zookeeperwatcher.java class

ZooKeeper Watcher. One instance of this are instantiated for each Master, Regionserver, and client process. Each master, RS, and client process will create an instance of Zookeeperwatcher.

1. Initialize zookeeper connection and watcher

① Setting the node name

②zkutil.connet

③ If the connection is successful, create some new nodes, such as zkutil.createandfailsilent (this, baseznode); If the node exists, it is no longer created. No watch. The persistence node is created here and has open access.

The Znode in HBase

/hbase Baseznode

Node name (fault)	Node classification		Zookeeperwatcher created when initializing
/hbase	Baseznode	Root Znode of a cluster	√
/hbase/root-region-server	Rootserverznode	The node that contains the server location for the-root-region
/hbase/rs	Rsznode	Temporary node of RS	√
/hbase/draining	Drainingznode	Draining RS Temporary node	√
/hbase/master	Masteraddressznode	Currently Active Master	Create in Hbase.master.Hmaster
/hbase/backup-masters	Backupmasteraddressesznode	Backup Master directory, if not the active master	√
/hbase/shutdown	Clusterstateznode	Znode containing the current cluster state
/hbase/unassigned	Assignmentznode	Region Transitioning and assignment	√ A child node of the node is created when the RS is started. Zkassign will manipulate this node and create child nodes to indicate the status of the Rs.
/hbase/table	Tableznode	Table disabling/enabling	√
/hbase/hbaseid	Clusteridznode	containing the unique cluster ID
/hbase/splitlog	Splitlogznode	Log Splitting work assignment	√

The function of the Zookeeperwatcher constructor is to initialize a zookeeper connection and set the watcher. Therefore, the nodes created at Zookeeperwatcher initialization indicate that these nodes will be created as soon as HBase is connected to zookeeper.

1,/hbase Sub-node:

2. The list command in HBase is compared to the sub-node under/hbase/table: The former does not include-root-and. META. Table:

3. When you start HBase, the/hbase/unassigned node changes:

Zookeeperlistener.java

Package org.apache.hadoop.hbase.zookeeper;

Abstract class that implements the monitoring of hbase internal zookeeper events. Zookeeperwatcher will implement the appropriate method to implement the class. In order to receive events from watcher, each listener must be registered with Zookeeperwatcher. Subclasses need to rewrite the required methods. It is important to note that the listener's watcher can cause blocking when executing these methods, and therefore cannot run these methods for long periods of time.

A zookeeperwatcher is initialized in the constructor.

The monitored events include nodecreated (string path), nodedeleted (string path), nodedatachanged (string path), Nodechildrenchanged (string Path).

Activemastermanager.java

Role: handles all master-related transactions for the master election. Listens for and responds to zookeeper notifications for master Znode, including nodecreated (node creation) and nodedeleted (node deletion).

Contains blocking methods, prepare master to wait for Master master to fail.

The class is instantiated in the Blockuntilbecomingactivemaster method of the Hmaster constructor.

Implements the nodecreated (node creation) and nodedeleted (node deletion) methods in abstract class Zookeeperlistener.

Scenarios for using zookeeper in HBase (not finished)

1, Master and Standby master switch

Application Scenarios	Using classes	Calling functions	Note
Master boot	Hmaster	Hmaster (constructor)	Connection Zookeeper
Master Standby Master Switchover	Hmaster	Becomeactivemaster (Monitoredtask startupstatus)	Register a Listener
Client Connection HBase	Hconnectionmanager	Hconnectionimplementation

(see Hbase.zookeeper source-bene.xlsx in the Sheet2)

Zookeeper Communication Legacy issues

1, follower and Observer can write data, the main difference is what?

Observerrequestprocessor will send a request for any modification status received to leader. Both observer and follower send a request to leader when the following actions are encountered

Switch (Request.type) {

Case OpCode. Sync:

Zks . Pendingsyncs. Add (Request);

Zks.getfollower (). request (request);

Zks.getobserver (). request (request);

break;

Case OpCode. Create:

Case OpCode. Delete:

Case OpCode. SetData:

Case OpCode. SetACL:

Case OpCode. CreateSession:

Case OpCode. CloseSession:

Case OpCode. Multi:

Zks.getfollower (). request (request);

Zks.getobserver (). request (request);

Main difference: Observer does not participate in leader elections and polls.

Follower can write data, observer do not participate when the client writes data, mainly through the sync operation to update the data.

The main difference between the two is that follower participates in elections and polls, and Observer does not participate in elections and polls.

The role of voting in writing data: When a client sends a write data operation, follower or observer forwards the write data request to leader and leader to the role with voting rights (that is, follower and leader) When more than half of these nodes are fed back to the leader vote, leader thinks the write data is successful.

Observer is a newly added role in the zookeeper-3.3 version, and they were introduced to solve the Byzantine general problem that could be caused by a decline in network reliability after the expansion of the zookeeper cluster.

2. How to guarantee the atomicity of the writing data?

Both read and write data in zookeeper are atomic.

The atomicity of read data refers to the data that is read from a node, which returns all the data from that node to the client.

The atomicity of writing data means that writing data does not partially fail or partially succeed. A successful write operation must be guaranteed to be written to the permanent storage of most zookeeper servers (not all servers that were last mentioned).

3. Is the child node of the/HBASE/RS Node a persistent node or a temporary node?

temporary node . You can view the data of the/HBASE/RS node and its child nodes in a shell script,/hbase/rs is a persistent node, and its child nodes are temporary nodes, for example.

/hbase/rs is a persistent node:

This znode[linux-jay1.jay,20020,1345715787547] is a temporary znode, and when the Regionserver is closed, the znode disappears, Then the Watcher Master will be the first to perceive the regionserver exit.

Note: If this is a persistent node, the value of Ephemeralowner is 0.

Each parameter of get is interpreted as:

Czxid:the Zxid of the change, caused this znode to be created.

Mzxid:the Zxid of the modified this znode.

Ctime:the time in milliseconds from epoch time this znode is created.

Mtime:the time in milliseconds from epoch time this znode is last modified.

Version:the number of changes to the data of this znode.

Cversion:the number of changes to the children of this znode.

Aversion:the number of changes to the ACL of this Znode

Ephemeralowner:the session ID of the the owner of this znode if the Znode are an ephemeral node. If It is a ephemeral node, it would be zero.

Datalength:the length of the data field of this znode.

Numchildren:the number of children of this znode.

4. What is the function of sync operation?

The role of the sync operation is to synchronize the client's Znode view with zookeeper, because the read operation may exist on one of the zookeeper servers where the data is not up-to-date. So zookeeper allows the client to update itself with sync (how to implement the Zookeeper kernel, which is not yet seen).

5, Watcher set is a one-time, why should be so designed?

Watch is set by the operation of the zookeeper service and triggered by other operations of the service, and watcher is only triggered once. For example, a client invokes a exists operation on a znode and adds a watch to the node, and if the node does not exist, the exists operation returns FALSE. If, after some time, the Znode is created by another client, the watch will be triggered to notify the first client Znode the message was created.

Because it is set up for operation, it is easy to distinguish the state that was said during the last communication. Zookeeper set watch during read operations exists, GetChildren, and GetData, which are triggered by write operations create, delete, and SetData.

In this case, not all actions will trigger watch, and not all operations will set watch. and through the path of Znode can determine which Znode has changed, by the type of operation can determine what the node changes. Personally, this setting does increase versatility and also reduces resource consumption.

In addition :

Zookeeper provides configuration services by using the Znode path to record keys, using Znode data to store values, so you can use Znode to store key-value pairs.

For example, the path of/hbase/root-region-server represents the address of the server where the-root-table is stored, and then uses the value of that Znode to store its address value

The application of "HBase" zookeeper in HBase