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 0DB4024ABD for ; Thu, 12 Sep 2019 00:54:39 -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 04iCN0I61bpY for ; Thu, 12 Sep 2019 00:54:38 -0400 (EDT) Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) (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 5292F24ABB for ; Thu, 12 Sep 2019 00:54:36 -0400 (EDT) Received: by smtp34.i.mail.ru with esmtpa (envelope-from ) id 1i8H7q-0004ot-Js for tarantool-patches@freelists.org; Thu, 12 Sep 2019 07:54:34 +0300 Date: Thu, 12 Sep 2019 07:54:29 +0300 From: Kirill Yukhin Subject: [tarantool-patches] [sergepetrenko@tarantool.org: [server-dev] [PATCH] replication: disallow bootstrap of read-only masters] Message-ID: <20190912045429.kv7cs54od52gbklb@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Hello, ----- Forwarded message from Serge Petrenko ----- Date: Tue, 3 Sep 2019 20:06:41 +0300 From: Serge Petrenko To: georgy@tarantool.org Cc: server-dev@tarantool.org, Serge Petrenko Subject: [server-dev] [PATCH] replication: disallow bootstrap of read-only masters X-Mailer: git-send-email 2.20.1 (Apple Git-117) In a configuration with several read-only and read-write instances, if replication_connect_quorum is not greater than the amount of read-only instances and replication_connect_timeout happens to be small enough for some read-only instances to form a quorum and exceed the timeout before any of the read-write instaces start, all these read-only instances will choose themselves a read-only bootstrap leader. This 'leader' will successfully bootstrap itself, but will fail to register any of the other instances in _cluster table, since it isn't writeable. As a result, some of the read-only instances will just die unable to bootstrap from a read-only bootstrap leader, and when the read-write instances are finally up, they'll see a single read-only instance which managed to bootstrap itself and now gets a REPLICASET_UUID_MISMATCH error, since no read-write instance will choose it as bootstrap leader, and will rather bootstrap from one of its read-write mates. The described situation is clearly not what user has hoped for, so throw an error, when a read-only instance tries to initiate the bootstrap. The error will give the user a cue that he should increase replication_connect_timeout. Closes #4321 This patch was reviewed during ML downtime. Checked in to 1.10, 2.1, 2.2 and master. -- Regards, Kirill Yukhin