Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B092C200D08 for ; Wed, 23 Aug 2017 04:25:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id AD2DF1680C6; Wed, 23 Aug 2017 02:25:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id F31551680BE for ; Wed, 23 Aug 2017 04:25:03 +0200 (CEST) Received: (qmail 39020 invoked by uid 500); 23 Aug 2017 02:25:03 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 39009 invoked by uid 99); 23 Aug 2017 02:25:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Aug 2017 02:25:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 91D3F1A1710 for ; Wed, 23 Aug 2017 02:25:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id mHSTEw2TGiRX for ; Wed, 23 Aug 2017 02:25:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 229885FAF7 for ; Wed, 23 Aug 2017 02:25:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 54BB6E0ECE for ; Wed, 23 Aug 2017 02:25:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 0ED402537F for ; Wed, 23 Aug 2017 02:25:00 +0000 (UTC) Date: Wed, 23 Aug 2017 02:25:00 +0000 (UTC) From: "Geoffrey Jacoby (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (PHOENIX-4115) Global indexes of replicated, immutable tables should be replicated MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 23 Aug 2017 02:25:04 -0000 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)