[
https://issues.apache.org/jira/browse/PHOENIX-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated PHOENIX-4115:
------------------------------------
Fix Version/s: (was: 4.15.0)
> Global indexes of replicated, immutable tables should be replicated
> -------------------------------------------------------------------
>
> Key: PHOENIX-4115
> URL: https://issues.apache.org/jira/browse/PHOENIX-4115
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Reporter: Geoffrey Jacoby
> Priority: Major
>
> Global indexes are stored in their own standalone tables, and for indexes on
> immutable tables, they're populated purely by client-side logic and don't go
> through the indexing coprocessors.
> This means that if a global index is created on an immutable table that's
> replicated to a different HBase cluster (say for DR), the index edits won't
> also be replicated to the remote cluster, because the server-side indexing
> logic won't fire when the base table edits are processed on either side.
> Indexes aren't created with a replication scope, and so HBase defaults to
> "don't replicate"
> Easiest fix for this is to set REPLICATION_SCOPE=1 on the index table when
> creating a global index on an immutable table that has REPLICATION_SCOPE=1.
> Interesting questions for potential followup JIRAs:
> 1. Should Phoenix automatically update existing immutable indexes on upgrade
> that are suffering from this problem, or just a release note to operators
> explaining the necessary fix?
> 2. Should Phoenix honor replication filters on an indexed column family or
> column in the data table on the index side? (Since these can change over
> time, that would get complicated very quickly.)
> Thanks, [~mujtabachohan] for pointing out and verifying this problem!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)