tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Howard <curtis.james.how...@gmail.com>
Subject Re: Tephra + Phoenix - configuration for high availability
Date Fri, 09 Nov 2018 19:36:52 GMT
Hi Andreas,

Thanks very much for the quick response!  We will go ahead with this HA
approach using CFG_DATA_TX_ZOOKEEPER_QUORUM.

Curtis

On Fri, Nov 9, 2018 at 1:08 PM Andreas Neumann <anew@apache.org> wrote:

> 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 <
> curtis.james.howard@gmail.com>
> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message