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

["Geoffrey Jacoby (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137814#comment-16137814 ] 

Geoffrey Jacoby commented on PHOENIX-4115:
------------------------------------------

Thinking about this some more...there's something else that makes it more complicated. Replication will stall if you have edits to a replicated table on one side where the table doesn't exist on the remote side. 

This means the ideal order would be:
1. Create index on DR
2. Create index on primary
3. Turn replication on for DR (if master-master replication is desired)
4. Turn replication on for primary
5. Populate the index
6. Activate the index

Which seems quite difficult for Phoenix to orchestrate. Yet it's a lot to ask operators to get right (speaking as an operator who's gotten it wrong. :-)  )

> 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)