From dev-return-2298-archive-asf-public=cust-asf.ponee.io@tephra.incubator.apache.org Fri Nov 9 19:08:48 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id BB288180627 for ; Fri, 9 Nov 2018 19:08:47 +0100 (CET) Received: (qmail 34075 invoked by uid 500); 9 Nov 2018 18:08:46 -0000 Mailing-List: contact dev-help@tephra.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tephra.incubator.apache.org Delivered-To: mailing list dev@tephra.incubator.apache.org Received: (qmail 34059 invoked by uid 99); 9 Nov 2018 18:08:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Nov 2018 18:08:46 +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 D4F41C0310 for ; Fri, 9 Nov 2018 18:08:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id gEeNZvQWJXzi for ; Fri, 9 Nov 2018 18:08:44 +0000 (UTC) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 691EC60E14 for ; Fri, 9 Nov 2018 18:00:42 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id x204-v6so2218384oia.0 for ; Fri, 09 Nov 2018 10:00:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L7iKJrQhc40dbsQEBgY5eVK71PAbnYaY2/LKe0uEDsI=; b=CVdB+V4meTOlz5mNwd4bxKrAQqc9BIbbLg/WW2Gmp+zcNqzWzvpz6ZHZKfz3gnKZgR YkuUuDEp+i4I2bGNCuN81I5Ua8WtoAMRY3wxvkh246GjhZN3w5Gr8HcMUe8pZywAxcU3 t8tiMVRqCOepRVQyi9129qgdIvQKRrKmAinhNdWG9x956DyjlOIgcnodF8Z3FnWpL/Q4 fertJAaU+E/izNTHGMMhLOyCCyIjXWFP9YHF6AHJEtaiZZs7nBNUxYZhRONBPH04WW2t Xi024azR6Vktsz7suT4eW5C4rvPFSFRx0414u7duxMbC15u4RIwpFdUilTqF80Fyge66 kUIA== X-Gm-Message-State: AGRZ1gLFWomu3fwykE+zF9dNMEIFeWabHKjN+0BcIWwwYTLK/v/kBtsc FmkBtHrody0vo8m+2+LOunmLC1Vj8JQwkdCSWyIDSg7J X-Google-Smtp-Source: AJdET5ceXum3f2WD3nlEzqW3B5nC7PQ3UYwj3MAz+PsBdDXLrG40ee62PZonofNH2ZusO3e5yo6aMEfj1X2supSTM/M= X-Received: by 2002:aca:60c5:: with SMTP id u188-v6mr5194341oib.151.1541786435806; Fri, 09 Nov 2018 10:00:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andreas Neumann Date: Fri, 9 Nov 2018 10:00:24 -0800 Message-ID: Subject: Re: Tephra + Phoenix - configuration for high availability To: dev@tephra.incubator.apache.org Content-Type: multipart/alternative; boundary="000000000000d36c75057a3f2034" --000000000000d36c75057a3f2034 Content-Type: text/plain; charset="UTF-8" Hi Curtis, All changes to the transaction state, including in-process transactions, are captured in the transaction log. When a failover occurs, the new transaction manager recreates the entire transaction state by replaying the log from the last snapshot. In-flight transactions should still be able to commit normally. It could happen, however, that a client rolls back during the short time that the transaction manager is down. That client would not be able to notify the tx manager that it has rolled back its transaction. Such a transaction would time out and become an invalid transaction. This is tested (not for failover, but for restart) here: https://github.com/apache/incubator-tephra/blob/master/tephra-core/src/test/java/org/apache/tephra/persist/AbstractTransactionStateStorageTest.java#L124 Cheers -Andreas On Fri, Nov 9, 2018 at 6:17 AM Curtis Howard wrote: > Hi, > > We are using Tephra to support transactions with Phoenix and would like to > configure Tephra in HA mode. > It seems that one option could be through the CFG_DATA_TX_ZOOKEEPER_QUORUM > property: > > https://github.com/apache/incubator-tephra/blob/d0a1c4c295fd28e68223db220b13dc1b12b326da/tephra-core/src/main/java/org/apache/tephra/TxConstants.java#L224-L226 > > I've tested this with a couple of Tephra manager processes on different > hosts, and they do seem to pass off control as the leader/standby > instance. It's not clear to me though how "in-flight" transactions that > have been initiated but not committed yet would be handled during a > failover? > > Is this the recommended approach? Are the any other settings besides > CFG_DATA_TX_ZOOKEEPER_QUORUM that we need to consider? > > Thank you! > Curtis > --000000000000d36c75057a3f2034--