HBase устанавливает сеанс с ZooKeeper и немедленно закрывает сеанс

Question

Я обнаружил, что наши региональные серверы часто подключаются к ZooKeeper. Кажется, они постоянно устанавливают сеанс, закрывают его и снова подключают ZooKeeper. Вот журнал для обеих сторон сервера и клиента. Я понятия не имею, почему это происходит и как с этим бороться? Мы используем HBase 0.94.11 и ZooKeeper 3.4.4.

Бревно из HBase RegionServer:

 
2014-09-18,16:38:17,867 INFO org.apache.zookeeper.ZooKeeper: Initiating client connection, connectString=10.2.201.74:11000,10.2.201.73:11000,10.101.10.67:11000,10.101.10.66:11000,10.2.201.75:11000 sessionTimeout=30000 watcher=catalogtracker-on-org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@69d892a1 
2014-09-18,16:38:17,868 INFO org.apache.zookeeper.client.ZooKeeperSaslClient: Client will use GSSAPI as SASL mechanism. 
2014-09-18,16:38:17,868 INFO org.apache.zookeeper.ClientCnxn: Opening socket connection to server lg-hadoop-srv-ct01.bj/10.2.201.73:11000. Will attempt to SASL-authenticate using Login Context section 'Client' 
2014-09-18,16:38:17,868 INFO org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper: The identifier of this process is 11787@lg-hadoop-srv-st05.bj 
2014-09-18,16:38:17,868 INFO org.apache.zookeeper.ClientCnxn: Socket connection established to lg-hadoop-srv-ct01.bj/10.2.201.73:11000, initiating session 
2014-09-18,16:38:17,870 INFO org.apache.zookeeper.ClientCnxn: Session establishment complete on server lg-hadoop-srv-ct01.bj/10.2.201.73:11000, sessionid = 0x248782700e52b3c, negotiated timeout = 30000 
2014-09-18,16:38:17,876 INFO org.apache.zookeeper.ZooKeeper: Session: 0x248782700e52b3c closed 
2014-09-18,16:38:17,876 INFO org.apache.zookeeper.ClientCnxn: EventThread shut down 
2014-09-18,16:38:17,878 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSink: Total replicated: 24 

Бревно из своего Zookeeper сервера:

 
2014-09-18,16:38:17,869 INFO org.apache.zookeeper.server.NIOServerCnxnFactory: [myid:2] Accepted socket connection from /10.2.201.76:55621 
2014-09-18,16:38:17,869 INFO org.apache.zookeeper.server.ZooKeeperServer: [myid:2] Client attempting to establish new session at /10.2.201.76:55621 
2014-09-18,16:38:17,870 INFO org.apache.zookeeper.server.ZooKeeperServer: [myid:2] Established session 0x248782700e52b3c with negotiated timeout 30000 for client /10.2.201.76:55621 
2014-09-18,16:38:17,872 INFO org.apache.zookeeper.server.auth.SaslServerCallbackHandler: [myid:2] Successfully authenticated client: authenticationID=hbase_srv/hadoop@XIAOMI.HADOOP; authorizationID=hbase_srv/hadoop@XIAOMI.HADOOP. 
2014-09-18,16:38:17,872 INFO org.apache.zookeeper.server.auth.SaslServerCallbackHandler: [myid:2] Setting authorizedID: hbase_srv 
2014-09-18,16:38:17,872 INFO org.apache.zookeeper.server.ZooKeeperServer: [myid:2] adding SASL authorization for authorizationID: hbase_srv 
2014-09-18,16:38:17,877 INFO org.apache.zookeeper.server.NIOServerCnxn: [myid:2] Closed socket connection for client /10.2.201.76:55621 which had sessionid 0x248782700e52b3c 

Answer 1

Наконец я нашел причину.

Да, речь идет о ReplicationSink, и я нашел журнал, «2014-09-23,14: 58: 01,736 DEBUG org.apache.hadoop.hbase.replication.regionserver.ReplicationSink: репликация для таблицы online_miliao_recent».

Затем я смотрю на соответствующий код и обнаружил, что каждый раз, когда он вызывает replicateEntries(), он вызывает sharedHBaseAdmin.tableExists (table).

ОбщийHBaseAdmin.tableExists() создаст новый объект CatalogTracker, который также является клиентом ZooKeeper.

Когда этот метод выйдет, он очистит клиент ZooKeeper и сеанс.

Таким образом, этот журнал выглядит разумным, так как выполняется репликация. Но tableExists() немного тяжелый, и я не думаю, что мы должны ссылаться на него каждый раз, когда я реплицирую. Я также заметил, что CatalogTracker не находится в ReplicationSink после 0.94.11, поэтому это не проблема для более поздних версий.

Было бы здорово, если бы я нашел jira, который удаляет CatalogTracker из ReplicationSink :-)