From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sergos@tarantool.org>
Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 186144696C3
 for <tarantool-patches@dev.tarantool.org>;
 Tue, 14 Apr 2020 17:43:09 +0300 (MSK)
Date: Tue, 14 Apr 2020 17:43:08 +0300
From: Sergey Ostanevich <sergos@tarantool.org>
Message-ID: <20200414144308.GC1734@tarantool.org>
References: <20200403210836.GB18283@tarantool.org>
 <20200414125848.GA1249@pony.bronevichok.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200414125848.GA1249@pony.bronevichok.ru>
Subject: Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Sergey Bronnikov <sergeyb@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

Hi!

Thanks for review!

On 14 апр 15:58, Sergey Bronnikov wrote:
> Hi,
> 
> see 5 comments inline
> 
> On 00:08 Sat 04 Apr , Sergey Ostanevich wrote:
> > 
> > * **Status**: In progress
> > * **Start date**: 31-03-2020
> > * **Authors**: Sergey Ostanevich @sergos \<sergos@tarantool.org\>
> > * **Issues**:
> 
> 1. Just for convenience, please add https://github.com/tarantool/tarantool/issues/4842
> 
Done.

> > ## Summary
> > 
> > The aim of this RFC is to address the following list of problems
> > formulated at MRG planning meeting:
> >   - protocol backward compatibility to enable cluster upgrade w/o
> >     downtime
> >   - consistency of data on replica and leader
> >   - switch from leader to replica without data loss
> >   - up to date replicas to run read-only requests
> >   - ability to switch async replicas into sync ones
> 
> 2. Ability to switch async replicas into sync ones and vice-versa? Or not?
> 
Both ways, updated.

> >   - guarantee of rollback on leader and sync replicas
> >   - simplicity of cluster orchestration
> >  
> > What this RFC is not:
> >  
> >   - high availability (HA) solution with automated failover, roles
> >     assignments an so on
> >   - master-master configuration support
> > 
> > 
> > ## Background and motivation
> > 
> > There are number of known implemenatation of consistent data presence in
> > a cluster. They can be commonly named as "wait for LSN" technique. The
> > biggest issue with this technique is the abscence of rollback gauarantees
> 
> 3. typo: gauarantees -> guarantees
> 
done

> > at replica in case of transaction failure on one master or some of the 
> > replics in the cluster. 
> 
> 4. typo: replics -> replicas
> > 
done

> > To provide such capabilities a new functionality should be introduced in
> > Tarantool core, with limitation mentioned before - backward compatilibity
> > and ease of cluster orchestration.
> 
> 5. but there is nothing mentioned before about these limitations.
> 
They were named as problems to address, so I renamed them as
requirements.

[cut]

Pushed updated version to the branch.

Thanks,
Sergos