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 E36A023657 for ; Fri, 27 Apr 2018 06:42:01 -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 QLEhgxSugmst for ; Fri, 27 Apr 2018 06:42:01 -0400 (EDT) Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (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 A1C4B23639 for ; Fri, 27 Apr 2018 06:42:01 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH] replication: do not fetch records twice in a full mesh References: <20180427102359.96686-1-k.belyavskiy@tarantool.org> From: Vladislav Shpilevoy Message-ID: <4d5ee862-786b-e6f9-dbc0-63e547b4df68@tarantool.org> Date: Fri, 27 Apr 2018 13:41:57 +0300 MIME-Version: 1.0 In-Reply-To: <20180427102359.96686-1-k.belyavskiy@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: tarantool-patches@freelists.org, Konstantin Belyavskiy , georgy@tarantool.org Hello. See my 6 comments below. On 27/04/2018 13:23, Konstantin Belyavskiy wrote: > --- > Ticket: https://github.com/tarantool/tarantool/issues/3294 > Branch: https://github.com/tarantool/tarantool/compare/gh-3294-do-not-fetch-records-twice > Link: https://github.com/tarantool/tarantool/blob/gh-3294-do-not-fetch-records-twice/doc/rfc/3294-implement-selective-subscribe-to-avoid-fetch-record-twice.md > > ...ective-subscribe-to-avoid-fetch-record-twice.md | 44 ++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > create mode 100644 doc/rfc/3294-implement-selective-subscribe-to-avoid-fetch-record-twice.md > > diff --git a/doc/rfc/3294-implement-selective-subscribe-to-avoid-fetch-record-twice.md b/doc/rfc/3294-implement-selective-subscribe-to-avoid-fetch-record-twice.md > new file mode 100644 > index 000000000..aa97fec77 > --- /dev/null > +++ b/doc/rfc/3294-implement-selective-subscribe-to-avoid-fetch-record-twice.md > @@ -0,0 +1,44 @@ > +# Replication: do not fetch records twice in a full mesh > + > +* **Status**: In progress > +* **Start date**: 25-04-2018 > +* **Authors**: Konstantin Belyavskiy @kbelyavs k.belyavskiy@tarantool.org, Georgy Kirichenko @georgy georgy@tarantool.org, Konstantin Osipov @kostja kostja@tarantool.org > +* **Issues**: \[#3294\](https://github.com/tarantool/tarantool/issues/3294) 1. Please hide the URL using correct markup. > + > +## Summary > + > +replication: do not fetch records twice in a full mesh 2. Please, write a more informative summary. It is not a commit header, and is not limited with one line and 50 symbols. For example, see https://github.com/tarantool/tarantool/blob/gh-3328-new-iproto/doc/rfc/3328-wire_protocol.md. > + > +## Background and motivation > + > +Extend IPROTO_SUBSCRIBE command with a list of server ids for which SUBSCRIBE should fetch changes. In a full mesh configuration, only download records originating from the immediate peer. Do not download the records from other peers twice. 3. Same - it is not a commit message. You must not write using imperative mood. Users, which will read this, do not know that it IPROTO_SUBSCRIBE command. > + > +For example, imagine a full mesh of 3 replicas. Currently each Tarantool instance will download from all peers all records in their WAL excepts records with instance id equal to the self instance id. Instead, it could send a subscribe request to its peers with server ids which are not present in other subscribe requests. > + > +## Implementation > + > +After issuing IPROTO_REQUEST_VOTE to all peers we know a map of server ids, their peers and their vclocks. Sort 4. RFC either must not contain implementation, or it must be at the end of the document. the map by server id. Iterate over each server in the list of peers, and assign its id to this server's SUBSCRIBE request. Assign all the remaining ids in \_cluster table to the last peer (alternatively, if there are many ids in 5. A new user does not know what it _cluster table, and it is a space, not a table. > +## Rationale and alternatives > + > +Here existing alternatives are described, and why they appeared to be worse than an implemented thing. 6. Where are alternatives? If no one, then delete this template, please.