[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873649#comment-16873649
]
Geoffrey Jacoby commented on HBASE-22622:
-----------------------------------------
[~stack] - Adding an additional, non-persisted Cell into a WALEdit would also
work but I share [~apurtell]'s concern about backporting it. If it could be
done in a backwards compatible way, it's a viable solution, but the WALKey one
seems more natural to me.
FYI, Phoenix already provides an optional WALEntryFilter plugin that allows
operators to turn on replication for System.Catalog for user-defined schema but
not global schema (PHOENIX-3639). There's also a proprietary
ReplicationEndpoint and WALEntryFilter we use pretty extensively at Salesforce
for filtering replication streams at a tenant level that I've been meaning to
contribute for ages over at PHOENIX-3939.
They both have to do some ugly black magic (parsing the row key in the WALEdit
Cells to get tenant Ids) to get around the lack of just this sort of
annotation.
> WALKey Extended Attributes
> --------------------------
>
> Key: HBASE-22622
> URL: https://issues.apache.org/jira/browse/HBASE-22622
> Project: HBase
> Issue Type: New Feature
> Components: wal
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
>
> It would be useful if the WAL protobuf and WALKey class included an optional
> map of extended key/value attributes that downstream coprocessors could use
> to annotate WAL Entries. While standard HBase replication would not use them,
> custom replication endpoints could use the data to make filtering decisions
> or take actions.
> An example use case would be allowing a tool like Phoenix to annotate
> WAL.Entries to indicate that a given Entry is associated with a particular
> Phoenix view rather than the base Phoenix table. (Multiple logical views in
> Phoenix can map to the same physical HBase table.) A custom replication
> endpoint might choose to replicate some views but not others.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
