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