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 1FB9F26F9D for ; Mon, 11 Mar 2019 15:52:17 -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 QarQyE7anxrS for ; Mon, 11 Mar 2019 15:52:16 -0400 (EDT) Received: from smtp63.i.mail.ru (smtp63.i.mail.ru [217.69.128.43]) (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 BAB3426B4D for ; Mon, 11 Mar 2019 15:52:16 -0400 (EDT) From: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= Subject: [tarantool-patches] Re: [PATCH v3 1/2] Write rows without a lsn to the transaction tail Date: Mon, 11 Mar 2019 22:52:10 +0300 Message-ID: <2621145.aQjCMBtlp2@home.lan> In-Reply-To: <20190311140439.GA13774@chai> References: <1611415.TB3NjmJXjb@localhost> <20190311140439.GA13774@chai> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2701706.E3lLz25N0K"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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: Konstantin Osipov Cc: tarantool-patches@freelists.org --nextPart2701706.E3lLz25N0K Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, March 11, 2019 5:04:39 PM MSK Konstantin Osipov wrote: > * 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. I don't think it is a good approach because of: 1. If replica A produces a transaction and replica B writes this transaction with local changes then state of replica C is unknown (we couldn't predict which replica A or B replicates faster). Also what should happen if C replicates from A and D replicates from B - they both will have different data. 2. In case of synchronous replication replica B how replica B should confirm its local changes? Using replica A confirmation, but replica A doesn't know anything about that as well as other replicaset items that replicates from A first. So if this local changes could not even be replicated should we allow such changes only for local spaces? 3. This breaks row format - now each row has full info about its transaction (replica id and tsn), but without separate tsn_replica_id item we should rely on external information (tx row number, previous rows and other). Please keep in mind a possibility of interleaving transactions. > > > 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. --nextPart2701706.E3lLz25N0K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEFB+nbqWGnp59Rk9ZFSyY70x8X3sFAlyGvGoACgkQFSyY70x8 X3vBgQgAm8Z8mEIbE4fq6JFsyCF1sQYUwJSqoBro7YFhJl1a6CSha5X4eFpw7IRS Qh+3tSCnHa97NHBe3wEgpKos0NGzxBkkBtwhjATwcjt7KXNb+lnV6Z3IRA4DPnNN 9+8+lJp9nV9pie9fWOKRossMMa9gpjdc+5WsC0hP5A/pke+MAG20wSumxYzZAZoo h3gcta96qaVTP+ehrR+yknmzdJ/BSx4f8hZzzQg7VCecy5De3ve0xtuFxeUTxHw8 cacPjQaGEOGm9jRlMJ7hpql8J9iWrDcPfMiMS62fALryiNxKUCojYarjBdjM/lK+ CgiACoJlQHszSPLxMofaX7A6JfTuDg== =KeQH -----END PGP SIGNATURE----- --nextPart2701706.E3lLz25N0K--