From dev-return-58894-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Wed Dec 4 23:42:03 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 1F6AC180656 for ; Thu, 5 Dec 2019 00:42:03 +0100 (CET) Received: (qmail 93437 invoked by uid 500); 4 Dec 2019 23:42:02 -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 93425 invoked by uid 99); 4 Dec 2019 23:42:02 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Dec 2019 23:42:02 +0000 Received: from jira-he-de.apache.org (static.172.67.40.188.clients.your-server.de [188.40.67.172]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 248C1E2E12 for ; Wed, 4 Dec 2019 23:42:01 +0000 (UTC) Received: from jira-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira-he-de.apache.org (ASF Mail Server at jira-he-de.apache.org) with ESMTP id 326D3780459 for ; Wed, 4 Dec 2019 23:42:00 +0000 (UTC) Date: Wed, 4 Dec 2019 23:42:00 +0000 (UTC) From: "Geoffrey Jacoby (Jira)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (PHOENIX-5604) Index rebuilds should not skip WAL MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Geoffrey Jacoby created PHOENIX-5604: ---------------------------------------- Summary: Index rebuilds should not skip WAL Key: PHOENIX-5604 URL: https://issues.apache.org/jira/browse/PHOENIX-5604 Project: Phoenix Issue Type: Bug Reporter: Geoffrey Jacoby Assignee: Geoffrey Jacoby Currently both Index read repairs and IndexTool build/rebuilds in the new d= esign continue to skip the WAL, following the same pattern the old Indexer = used. However, there are key differences between the old and new logic that= make this no longer the correct choice. First, recall that all HBase replication is based on tailing the WAL, and t= hat any transaction that skips the WAL doesn't get replicated.=C2=A0 In the old logic, the data table write (and WAL append) would be accompanie= d by an IndexedKeyValue which would contain enough information to reconstit= ute the index edit in the event of a failure before the index edit could be= committed. So skipping the WAL during recovery was _potentially_=C2=A0OK, = because writing to the WAL would be redundant locally. (But that still seem= s to me wrong in a case with replication, since I don't believe IndexedKeyV= alues are replicated, since they use the "magic" METAFAMILY cf.)=C2=A0=C2= =A0 In the new logic, on a normal write, we write to the index first (which wil= l go into a WAL), then the data table (into a potentially different RS's WA= L), and lastly the verified flag flip into the Index, into the original ind= ex write's WAL. If something goes wrong with stage 2 or 3, read repair will= fix it, but if the repair action =E2=80=93 whether a put or delete =E2=80= =93 doesn't go into the WAL, a DR buddy of the index will be out of sync.= =C2=A0 This is even more important on an async initial build of an index, where if= I understand right, there is no WAL append for the index write at all in t= he current UngroupedAggregateRegionObserver rebuild logic. The same would b= e the case of a rebuild of a new-style index in the event of non-Phoenix re= lated corruption (such as HDFS or raw HBase level).=C2=A0 -- This message was sent by Atlassian Jira (v8.3.4#803005)