Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication

[Sergey Ostanevich <sergos@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