Return-Path: X-Original-To: apmail-phoenix-dev-archive@minotaur.apache.org Delivered-To: apmail-phoenix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C414318386 for ; Wed, 2 Dec 2015 22:31:17 +0000 (UTC) Received: (qmail 53288 invoked by uid 500); 2 Dec 2015 22:31:14 -0000 Delivered-To: apmail-phoenix-dev-archive@phoenix.apache.org Received: (qmail 53227 invoked by uid 500); 2 Dec 2015 22:31:14 -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 53216 invoked by uid 99); 2 Dec 2015 22:31:14 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Dec 2015 22:31:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id ED5ABC0473 for ; Wed, 2 Dec 2015 22:31:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.226 X-Spam-Level: * X-Spam-Status: No, score=1.226 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.554] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id G-A7sbHcCuKs for ; Wed, 2 Dec 2015 22:31:13 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with SMTP id 10F22204DE for ; Wed, 2 Dec 2015 22:31:11 +0000 (UTC) Received: (qmail 52474 invoked by uid 99); 2 Dec 2015 22:31:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Dec 2015 22:31:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 2136A2C1F74 for ; Wed, 2 Dec 2015 22:31:11 +0000 (UTC) Date: Wed, 2 Dec 2015 22:31:11 +0000 (UTC) From: "Alicia Ying Shu (JIRA)" To: dev@phoenix.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-2221) Option to make data regions not writable when index regions are not available MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036775#comment-15036775 ] Alicia Ying Shu commented on PHOENIX-2221: ------------------------------------------ [~jamestaylor] Thanks for the review. Summarize the changes below with a revised patch. 1) In Indexer.java, it needs a constructor with only PerRegionIndexWriteCache as the parameter. So need to have a constructor for that. 2) Since we do not want the delegator of stopping region server ever to be null, instantiates one of KillServerOnFailurePolicy. 3) Test is now derived from BaseHBaseManagedTimeIT. 4) In Indexer, make INDEX_RECOVERY_FAILURE_POLICY_KEY public 5) No change in PhoenixIndexCodec. Set INDEX_RECOVERY_FAILURE_POLICY_KEY in the hbase-site.xml. 6) Need changes in QueryOptimizer because during index rebuild, index is readable. When choosing a plan for a scan submitted during index rebuild, if an index is in READABLE state, we can choose index scan since there is no new data written except those failed ones. This applies to those applications that can tolerate minor data loss during a minimum time. 7) Add a new READABLE index state. The reason we used PIndexState.READABLE is that during index rebuild, index is not blocked for read. It is still readable. Only the writes to data table are blocked. > Option to make data regions not writable when index regions are not available > ----------------------------------------------------------------------------- > > Key: PHOENIX-2221 > URL: https://issues.apache.org/jira/browse/PHOENIX-2221 > Project: Phoenix > Issue Type: Improvement > Reporter: Devaraj Das > Assignee: Alicia Ying Shu > Attachments: PHOENIX-2221-v1.patch, PHOENIX-2221-v2.patch, PHOENIX-2221.patch > > > In one usecase, it was deemed better to not accept writes when the index regions are unavailable for any reason (as opposed to disabling the index and the queries doing bigger data-table scans). > The idea is that the index regions are kept consistent with the data regions, and when a query runs against the index regions, one can be reasonably sure that the query ran with the most recent data in the data regions. When the index regions are unavailable, the writes to the data table are rejected. Read queries off of the index regions would have deterministic performance (and on the other hand if the index is disabled, then the read queries would have to go to the data regions until the indexes are rebuilt, and the queries would suffer). -- This message was sent by Atlassian JIRA (v6.3.4#6332)