From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 EA98042EF5C for ; Thu, 11 Jun 2020 18:17:30 +0300 (MSK) References: <20200430145033.GF112@tarantool.org> <20200506085249.GA2842@atlas> <20200506163901.GH112@tarantool.org> <20200506184445.GB24913@atlas> <20200512155508.GJ112@tarantool.org> <78713377-806f-8cf6-efe0-5019f3d3e428@tarantool.org> <20200514203811.GN112@tarantool.org> <20200520205925.GA58@tarantool.org> <887a0ec5-3a01-565a-0c31-f7fab619af8f@tarantool.org> <20200527211735.GA50@tarantool.org> <20200609161929.GF50@tarantool.org> From: Vladislav Shpilevoy Message-ID: <6678e2a7-9f95-ce3d-1c2f-1eaf20589005@tarantool.org> Date: Thu, 11 Jun 2020 17:17:29 +0200 MIME-Version: 1.0 In-Reply-To: <20200609161929.GF50@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org Hi! Thanks for the updates! > ### Connection liveness > > There is a timeout-based mechanism in Tarantool that controls the > asynchronous replication, which uses the following config: > ``` > * replication_connect_timeout = 4 > * replication_sync_lag = 10 > * replication_sync_timeout = 300 > * replication_timeout = 1 > ``` > For backward compatibility and to differentiate the async replication > we should augment the configuration with the following: > ``` > * synchro_replication_heartbeat = 4 Heartbeats are already being sent. I don't see any sense in adding a second heartbeat option. > * synchro_replication_quorum_timeout = 4 Since this is a replication option, it should start from replication_ prefix. > ``` > Leader should send a heartbeat every synchro_replication_heartbeat if > there were no messages sent. Replicas should respond to the heartbeat > just the same way as they do it now. As soon as Leader has no response > for another heartbeat interval, it should consider the replica is lost. All of that is already done in the regular heartbeats, not related nor bound to any synchronous activities. Just like failure detection should be. > As soon as leader appears in a situation it has not enough replicas > to achieve quorum, it should stop accepting write requests. There's an > option for leader to rollback to the latest transaction that has quorum: > leader issues a 'rollback' message referring to the [LEADER_ID, LSN] > where LSN is of the first transaction in the leader's undo log. What is that option? > The rollback message replicated to the available cluster will put it in a > consistent state. After that configuration of the cluster can be > updated to a new available quorum and leader can be switched back to > write mode. > > During the quorum collection it can happen that some of replicas become > unavailable due to some reason, so leader should wait at most for > synchro_replication_quorum_timeout after which it issues a Rollback > pointing to the oldest TXN in the waiting list.