You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2017/09/19 05:28:00 UTC
[jira] [Created] (HBASE-18846) Accommodate the
hbase-indexer/lily/SEP consumer deploy-type
stack created HBASE-18846:
-----------------------------
Summary: Accommodate the hbase-indexer/lily/SEP consumer deploy-type
Key: HBASE-18846
URL: https://issues.apache.org/jira/browse/HBASE-18846
Project: HBase
Issue Type: Bug
Reporter: stack
This is a follow-on from HBASE-10504, Define a Replication Interface. There we defined a new, flexible replication endpoint for others to implement but it did little to help the case of the lily hbase-indexer. This issue takes up the case of the hbase-indexer.
The hbase-indexer poses to hbase as a 'fake' peer cluster. The hbase-indexer will start up cut-down "RegionServer" processes that are nought but an hbase RpcServer hosting an AdminProtos Service. They make themselves 'appear' to the Replication Source by hoisting up an ephemeral znode 'registering' as a RegionServer. The source cluster then streams WALEdits to the Admin Protos method:
{code}
public ReplicateWALEntryResponse replicateWALEntry(final RpcController controller,
final ReplicateWALEntryRequest request) throws ServiceException {
{code}
The hbase-indexer relies on other hbase internals like Server so it can get a ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
Thoughts on how to proceed include:
* Better formalize its current digestion of hbase internals; make it so rpcserver is allowed to be used by others, etc.
* Start an actual RegionServer only have it register the AdminProtos Service only -- not AdminProtos and ClientProtos, etc. Then have the hbase-indexer implement an AdminCoprocessor to override the replicateWALEntry method (the Admin CP implementation may need work).
I'll be back....
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)