[
https://issues.apache.org/jira/browse/PHOENIX-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073995#comment-14073995
]
Anoop Sam John commented on PHOENIX-1107:
-----------------------------------------
bq.what APIs does the replay go through? I'm guessing they're HBase APIs, not
Phoenix APIs in which case the index updates wouldn't happen.
It will use HTable#batch() API calls in peer cluster. So will go through the
HRegion normal write paths and CPs. If the CPs for secondary indexing is ON in
the peer cluster, then the index updates would happen right?
bq.Went the route that replication doesn't write any of the index edits that
are stored with the primary table (those are only kept around in the case of
failures for WAL replay). So the index gets written on the replication target
either by the table on the target cluster or by replicating the index table
itself.
\+1 for this idea. Any way the index table data directly wont get replicated
(?) [index table is created with REPLICATION_SCOPE_LOCAL only (The default
value) ?]
> Support mutable indexes over replication
> ----------------------------------------
>
> Key: PHOENIX-1107
> URL: https://issues.apache.org/jira/browse/PHOENIX-1107
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 3.1, 4.1
> Reporter: Jesse Yates
> Assignee: Jesse Yates
> Attachments: phoenix-1107-3.0.v0
>
>
> Mutable indexes don't support usage with replication. For starters, the
> replication WAL Listener checks the family of the edits, which can throw a
> NPE for the IndexedKeyValue
--
This message was sent by Atlassian JIRA
(v6.2#6252)
