You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Geoffrey Jacoby (JIRA)" <ji...@apache.org> on 2017/08/23 02:25:00 UTC

[jira] [Created] (PHOENIX-4115) Global indexes of replicated, immutable tables should be replicated

Geoffrey Jacoby created PHOENIX-4115:
----------------------------------------

             Summary: 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
             Fix For: 4.12.0


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
(v6.4.14#64029)