From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp52.i.mail.ru (smtp52.i.mail.ru [94.100.177.112]) (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 8202E43D678 for ; Tue, 22 Oct 2019 01:59:28 +0300 (MSK) From: Vladislav Shpilevoy Reply-To: tarantool-patches@freelists.org References: <5dc83b86bbeada22342c355648de2daa7766bb73.1568798455.git.georgy@tarantool.org> <1816701.j1k7ruT3f3@home.lan> <569ff681-a670-f4ca-3c6f-75c159e21429@tarantool.org> Message-ID: Date: Tue, 22 Oct 2019 01:04:43 +0200 MIME-Version: 1.0 In-Reply-To: <569ff681-a670-f4ca-3c6f-75c159e21429@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH v2 3/4] wal: xrow buffer cursor List-Id: Tarantool development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Georgy Kirichenko Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org >>>> + break; >>>> + /* Buffer was discarded. */ >>> >>> 4. Ok, perhaps now I understand the idea of why do you discard >>> chunks without any checks if they are in use. Looks cool. >>> >>> But it means, that if a relay sends data too slow, it will fall >>> from the in-memory replication down to disk. Being fallen to a disk, >>> how can it return back? Isn't it a problem, that the chunks will >>> be being written to wal so many and fast, that the relay will never >>> return back to in-memory replication? >> If it is a temporary slowdown and a relay will process data faster than a >> master writes then the relay will return to in-memory replication. In the >> opposite case, if the relay is lower that the master, then the relay will be >> discarded because of collected wall file - in this case there is nothing we can >> do. > > Have you asked Alexander Tikh. to bench you branch? I think > we need to test how realistic is the case, when WAL writes much faster > than replicates, and the replicas just never can keep master's pace. > Is it correct, that relay doesn't send a next transaction until a > previous is ACKed? Any news here?