[
https://issues.apache.org/jira/browse/HBASE-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840824#comment-15840824
]
Enis Soztutar commented on HBASE-17543:
---------------------------------------
Sounds good.
I think we should do a sanity check in the master when addPeer, or
updatePeerConfig is called to check whether the class is loadable (something
like HMaster.sanityCheckTableDescriptor()). Then we should not silently ignore
the wrong class name, but instead throw an exception.
> Create additional ReplicationEndpoint WALEntryFilters by configuration
> ----------------------------------------------------------------------
>
> Key: HBASE-17543
> URL: https://issues.apache.org/jira/browse/HBASE-17543
> Project: HBase
> Issue Type: Improvement
> Components: Replication
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Attachments: HBASE-17543.patch
>
>
> The existing BaseReplicationEndpoint creates a ChainWALEntryFilter containing
> a NamespaceTableCfWALEntryFilter and a ScopeWALEntryFilter. Adding a custom
> WALEntryFilter type to this chain requires creating an entirely new
> ReplicationEndpoint subclass and creating a new peer on the running cluster,
> which can be operationally complex to transition to without data loss in
> cases such as master/master.
> For WALEntryFilters without constructor parameters, it would be
> straightforward to have a Configuration option to list additional
> WALEntryFilter classes the operator wants to include in the filter chain in
> the default endpoint, and then have the endpoint instantiate the filters via
> reflection. Then filter logic could be added (or removed) with only a
> hbase-site.xml change and a rolling restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
