From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id F36366EC41; Sun, 15 Aug 2021 10:56:59 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org F36366EC41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1629014220; bh=rcsXnUl5t+jA7J3FhF8y5KseKdw9shHO3nYd75ETxbs=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Pmav8pXQOa+Fn8h6v3CY260EkF7wtT9hMQ2ByM2PZ5MfWalBvZ1o58rVeW7QZyRO6 nPnYb9fQLLVTKSkfJVpajY2bRrz0+77BBLWRgSG91TZuw76xit2N2hlSYqxd4zyAmt ZRrIz2857v/Wa+DMxuiQy8LX729kbHTvuBhcJluU= Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 2F75A6EC40 for ; Sun, 15 Aug 2021 10:56:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2F75A6EC40 Received: by mail-lj1-f171.google.com with SMTP id y7so22373081ljp.3 for ; Sun, 15 Aug 2021 00:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=gau9T6h7YJHWbT0yWmB2atFjXLuzd/T27Q9gjFsR+Wk=; b=IoSj8pg3KNtCORgL178TAOG+qWwuKtcUU60ehG7qUv2/lyVYxFeu7uQ1nGBeBOnNOT LcyyM5UEZQv6O409pVFSKmGQ2uta0U4bu13w9tRo6iow8oS5hUIxzml2ECxY2tx/xpjD myoULuHKTUOtIi7M1SAKioAylS7YZDOK1Zabueo5fECz4yb+XTh2u/Rzqzw65dgkosbs 3UXnCw7/hi0Q36zqm+haHp+9byzkAtNooCoKgW82fMwdQ7/e6BVUwVh8YRxKbh3oy1E2 TvNTaF5W9CVqQydOP7DjbzH7s5Kum22LznqIjXb6SW4NSpWJHS1GBR3rD9vcnMNZzIZT fgpw== X-Gm-Message-State: AOAM532vqdG5ceAo1KC/Fj/nj2P8svjtAGUXIjlBTTK7KBvB+Ljjvfox DA4X6XbVcLyEf6GfTuiSRw== X-Google-Smtp-Source: ABdhPJwO0L1iJ+YsSAjQXXBO0p7KMfO/6VsxJiy0s9ddD0HNVsxpyd2YWM/wmUDqOCvKcW1S3TFu0w== X-Received: by 2002:a05:651c:4d4:: with SMTP id e20mr8168558lji.130.1629014217488; Sun, 15 Aug 2021 00:56:57 -0700 (PDT) Received: from sterling.local ([46.188.68.12]) by smtp.gmail.com with ESMTPSA id f24sm63998lfh.241.2021.08.15.00.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 00:56:56 -0700 (PDT) Received: by sterling.local (Postfix, from userid 1000) id DE1A7E611C7; Sun, 15 Aug 2021 10:56:54 +0300 (MSK) Date: Sun, 15 Aug 2021 10:56:54 +0300 To: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0J7QsdGD0YXQvtCy?= Cc: tarantool-discussions@dev.tarantool.org Message-ID: <20210815075654.GA22409@starling> References: <1628957596.509402934@f394.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1628957596.509402934@f394.i.mail.ru> Subject: Re: [Tarantool-discussions] =?utf-8?b?0JzQvtC30LPQvtGI0YLRg9GA0Lw6?= =?utf-8?b?INCk0LXQudC70L7QstC10YAg0YEg0YDQtdC20LjQvNC+0Lwg0LTQtdCz0YA=?= =?utf-8?b?0LDQtNCw0YbQuNC4?= X-BeenThere: tarantool-discussions@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Konstantin Osipov via Tarantool-discussions Reply-To: Konstantin Osipov Errors-To: tarantool-discussions-bounces@dev.tarantool.org Sender: "Tarantool-discussions" * Дмитрий Обухов via Tarantool-discussions [21/08/15 03:02]: Сначала надо реализовать изменение конфигурации как часть протокола Рафт, и реализовать raft learner расширение протокола, описанное в PhD. Проблему чётного числа узлов нужно решать именно с помощью raft learners (non-voting nodes). Режим автоматического уменьшения размера кворума описан в PhD и был реализован, по сути это автоматическая инициация configuration change после длительной недоступности одного узла. Репликационный фактор, как и placement/locality - это свойство данных, а не свойство топологии. Для одной таблицы он может быть 3, для других 7, при этом дата центра может быть хоть 2 хоть 10. И менятьего должен DBA а не СУБД автоматически. То что в тарантуле это "слито" воедино - просто наследственность. > А вот давайте попробуем пообсуждать здесь. Может такой формат больше народу подойдёт. >   > В этом релизе у нас появляется автоматический фейловер «на борту» Тарантула — RAFT. >   > Это прекрасное событие, однако у него есть некоторые недостатки: > > - Беспроблемные гарантированные выборы возможны только если число участников выборов нечётное. Или число кворума больше половины числа участников на 1. Для 2 — это 2. Для 3 это 2. Для 4 это 3. >   > Кроме того ещё несколько вводных в виде F.A.Q: >   > Q: Для чего пользователи ставят репликасет в нескольких ДЦ? > A: Чтобы при недоступности одного (или нескольких) ДЦ сервис продолжал работу. >   > Q: Если сервис располагается в X датацентрах, умерли все кроме одного последнего. Хочет ли пользователь чтоб его сервис был доступен клиентам? > A: Безусловно >   > Q: Какая инсталляция по нескольким ДЦ самая популярная? > A: Инсталляция на 2 независимых ДЦ (минимальный случай резервирования, экономически самый дешёвый) >   >   > Если порефлексировать над этими вводными, то мы можем сформулировать требования к «идеальному» фейловеру: >   > - Работоспособность сервиса должна сохраняться «до последнего ДЦ» > - Из предыдущего пункта следует необходимость поддержки «режима деградации» — по аналогии с режимом деградациии в RAID: отключили винчестер, избыточность исчезла, но RAID продолжает работу > - Работоспособность сервиса не должна «предпочитать» чётные/нечётные числа, а должна сохраняться при снижении числа работоспособных узлов от N до 1. >   >   > Исходя из перечисленного, я вижу RAFT — это только подузел такого механизма, а над ним действуют какие-то правила, которые плавно снижают кворум, выводя из игры недоступные узлы, вплоть до 1 (кворума нет, остался последний боец). >   > Очевидно (мне очевидно, я могу ошибаться), что такой фейловер невозможен, если только сами узлы будут решать кто главный: рано или поздно ситуация что кластер разделился на две независимые половины, каждая со своим главным — произойдёт. >   > Если взглянуть на многие пользовательские сервисы, то увидим, что пользователи заходят на них через одну точку входа: на mail.ru — через адрес mail.ru. На сервис банка — через адрес банка. И так далее. Возможно, если разместить stateful мониторы в этих точках, то подобный фейловер можно реализовать? >   > Есть у кого-то мысли как построить подобный фейловер? >   > -- > Дмитрий Обухов -- Konstantin Osipov, Moscow, Russia