[
https://issues.apache.org/jira/browse/HBASE-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16171133#comment-16171133
]
stack commented on HBASE-10504:
-------------------------------
All subtasks in this issue are done. A Replication Interface has been
implemented. Resolving.
But first, on rereading the clean discussion above, this implementation has
little for the lily/SEP/hbase-indexer "fake cluster" case. The lily-folks
reasonably want to index in a separate process. They want to be able to scale
up and down this consumer independent of RegionServer count and they don't want
to have to implement our rpc, security or serde.
In "Gabriel Reid added a comment - 11/Feb/14 23:59", he states that
hbase-indexer makes use of o.a.h.h.replication.regionserver.ReplicationSource
and o.a.h.h.Server, as well as the generated AdminProtos. He continued: " The
one thing I can think of right now that would be nice is a better hook into
o.a.h.h.replication.regionserver.ReplicationSource#removeNonReplicableEdits.
Right now we override that method to do additional filtering on HLog entries
that we know we don't want do send to the indexer"
This latter asked-for-functionality, a sender-side filtering mechanism, was
added in a subtask of this issue, HBASE-11367, where you can define
implementations of WALEntryFilter when you define a ReplicationEndpoint (The
current SEP has actually stopped filtering source-side because breakage was
common).
That leaves all the rest: the standing up of an hbase rpcserver instance that
floats an Admin Service doing a hokey register of the RegionServer ephemeral
znode up in zk.
As suggested above, lets open a distinct issue for helping out the
hbase-indexer case.
> Define Replication Interface
> ----------------------------
>
> Key: HBASE-10504
> URL: https://issues.apache.org/jira/browse/HBASE-10504
> Project: HBase
> Issue Type: Task
> Components: Replication
> Reporter: stack
> Assignee: Enis Soztutar
> Priority: Blocker
> Attachments: hbase-10504_v1.patch, hbase-10504_wip1.patch
>
>
> HBase has replication. Fellas have been hijacking the replication apis to do
> all kinds of perverse stuff like indexing hbase content (hbase-indexer
> https://github.com/NGDATA/hbase-indexer) and our [~toffer] just showed up w/
> overrides that replicate via an alternate channel (over a secure thrift
> channel between dcs over on HBASE-9360). This issue is about surfacing these
> APIs as public with guarantees to downstreamers similar to those we have on
> our public client-facing APIs (and so we don't break them for downstreamers).
> Any input [~phunt] or [~gabriel.reid] or [~toffer]?
> Thanks.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
