From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9972C28F41 for ; Mon, 11 Mar 2019 10:04:42 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7EdZhNaRZH0 for ; Mon, 11 Mar 2019 10:04:42 -0400 (EDT) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id EF12427834 for ; Mon, 11 Mar 2019 10:04:41 -0400 (EDT) Date: Mon, 11 Mar 2019 17:04:39 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v3 1/2] Write rows without a lsn to the transaction tail Message-ID: <20190311140439.GA13774@chai> References: <48e024c9ada966ce68447a7cf24c201b1ebaf27b.1552248901.git.georgy@tarantool.org> <20190311095926.GA9866@chai> <1611415.TB3NjmJXjb@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1611415.TB3NjmJXjb@localhost> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Georgy Kirichenko Cc: tarantool-patches@freelists.org * Georgy Kirichenko [19/03/11 13:54]: It seems we should be able to allow using statements with different server_id in the same transaction. When deciding which transactions to send back in multi-master mode, we should only look at the first statement to find out the source (origin) of the transaction and either send all statements in the transaction or skip all statements. > On Monday, March 11, 2019 12:59:26 PM MSK Konstantin Osipov wrote: > > * Georgy Kirichenko [19/03/11 09:55]: > > > Form a separate transaction with local changes in case of replication. > > > This is important because we should be able to replicate such changes > > > (e.g. made within an on_replace trigger) back. In the opposite case > > > local changes will be incorporated into originating transaction and > > > would be skipped by the originator replica. > > > > I wonder will we possibly have some recovery issues, since in fact > > we're performing a reordering of execution here? > > > > Imagine local and remote statements change the same set of rows. > > During initial execution these changes are intermixed, during > > recovery they are serialized. > If you remember we were agreed that only local spaces are allowed to change in > case of replication triggers. > > > > It seems we clearly have a problem here. We can either open a bug, > > support multiple txn ids in the same stream, support multiple > > server ids in the same transaction, ban triggers in > > multi-statement transaction? > You pushed me to remove txn_replica_id but it was one of the instruments I > planed to use in order to support distributed transactions (with multiple > replica ids in the same transaction) in the future. So I would prefer if we > just disable changing of non-local spaces during replication. In such case we > won't have any issues with reordering. > > > > Can we attribute local changes to the same server id? > It is impossible because of lsn > > We don't have to replicate them back - this is a gray zone and we can do it > > in any way we want. > I'm afraid no because we already have this functionality and it is even > covered with tests. > > So we have to make a high level decision: what is expected behavior. > In any case I will be agreed with your decision what we should to do: disable > non-local replication changes, change behavior of replication for such changes > or start further distributed transaction investigation. > > -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov