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 E167E6EC55; Tue, 13 Jul 2021 01:32:59 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E167E6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626129180; bh=K8PTYGID62YA06V+rNPYDGBybbV+CImbdqqI+KR4OB8=; 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=R5bD3jNEX64bfQkaej0AP/zWCX6ICx3wzHP7J1weNGyL8V4Pno6viyoKnUHgMSQoA leFTGsFyD5x0xdzqrZw/0OSuUeIL75DnyaE4zL4SUXKlazNFajh8eViA/8MB9gt3ua XPakWoyxluXCy/JYXqwYdlusQ1fVJq8S0WObQQWI= Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 C819E6EC55 for ; Tue, 13 Jul 2021 01:32:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C819E6EC55 Received: by mail-lj1-f172.google.com with SMTP id a6so26815073ljq.3 for ; Mon, 12 Jul 2021 15:32: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:user-agent; bh=XIqoose/3FcRoAj3pbcfefeT/impsI4svFYM2zw2npI=; b=XCbLLIi9hljv65qEA8psR03yNtWyeEOmOtMTbMMEs9DTDS3fzmFF6EQKKV4DpT0mqF G/8/XxLF67QxX49rEGoLYp8IwOd/xnLmdUtXhIN2v5KkZIGsJI3MribMicBIpCwZjoci DTj8iI0Ing4ga52HbspZf95L0k96xBCKveeOD3KWwMD0q3Rrsov5e1YrwfD+DaB1vzs/ jPnqgJKrsbmMRZXN/mYlT4u3uAbfqv9NR2uaBH3xumMj9JE4wlgrQCSFZlFilcjXk8FE ScE+8V9/fiWRweDpDwHEI92ge1yQ5nCkAkAi3NMvkCXp0FCtqd9Ibai3uhCsXtfliiVK fNpg== X-Gm-Message-State: AOAM532tmzu8O6jngK1AgNrM5WjmA36tdewVjf7mTfE11/97qmPfVxJH P4Vh/7bZN6yf6gvPZYvyDflTLc6egpo= X-Google-Smtp-Source: ABdhPJwp+xc1FqeaCfqHF8ydI2xYMf+vw0mPfQ3vv5clrbdxpdbDvB/BJaAM7R9y1RY58XpvVtwnQQ== X-Received: by 2002:a2e:9cd5:: with SMTP id g21mr200959ljj.99.1626129177628; Mon, 12 Jul 2021 15:32:57 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id k10sm1300460lfg.35.2021.07.12.15.32.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 15:32:54 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id EF3565A001E; Tue, 13 Jul 2021 01:32:53 +0300 (MSK) Date: Tue, 13 Jul 2021 01:32:53 +0300 To: Vladislav Shpilevoy Cc: tml Message-ID: References: <20210710222803.253251-1-gorcunov@gmail.com> <4965b115-dd42-0129-0086-a0ff711fa648@tarantool.org> <51e97609-c593-0693-1133-ae09dfbc78cc@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51e97609-c593-0693-1133-ae09dfbc78cc@tarantool.org> User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH] limbo: introduce request processing hooks X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Mon, Jul 12, 2021 at 11:20:17PM +0200, Vladislav Shpilevoy wrote: > >> > >> That is the core problem of your entire approach - why do you imagine > >> we update promote_term_map before writing to WAL? We do not do that. > > > > We don't do that now, and this is all this patch about - we must not > > write the PROMOTE from split-brained node into our wal file at all, > > for exactly this reason I splitted processing into phases: "filter" and > > "application". > > Я вижу, я не могу на английском объяснить. Да, мы не делаем этого сейчас. > Зачем ты начинаешь это делать в своем патче? Ничего не должно меняться > до записи в WAL. Ни vclock с термами, ни что-либо еще. Лимб должен быть > const пока запись в WAL не кончена. > > Я вижу, что ты split processing, но ты на самом деле сделал не filter и > application. Ты сделал apply part 1 и apply part 2. У тебя обе стадии > меняют лимб. Зачем? Filter не должен менять вообще ничего. Только > проверять и отсеивать с ошибкой, если что не так. Потому что выходить с какой-то ошибкой изнутри WAL уже нельзя. Смотри, вот как сейчас фильтруется (с моим патчем) static int limbo_op_filter(struct txn_limbo *limbo, const struct synchro_request *req) { struct txn_limbo_promote *pmt = &limbo->promote; uint32_t origin = req->origin_id; uint64_t term = req->term; if (txn_limbo_replica_term(limbo, origin) < term) { vclock_follow(&pmt->terms_infly, origin, term); if (term > pmt->term_max) pmt->term_max = term; } else if (iproto_type_is_promote_request(req->type) && pmt->term_max > 1) { say_info("RAFT: declining %s request from instance " "id %u for term %llu. Greatest term seen " "before (%llu) is bigger.", iproto_type_name(req->type), origin, (long long)term, (long long)pmt->term_max); diag_set(ClientError, ER_UNSUPPORTED, "RAFT", "backward terms"); --> return -1; } return 0; } Это делается до записи в вал, чтобы ловить одновременно приходящие промоты от разных реплик, пропускать только первый валидный, а остальные выкидывать с ошибкой. Так что ты правильно говоришь ниже, что это защита. Если я не буду ловить такие данные до записи в вал, то получится следующая ситуация: приходит пакет, который будет модифицировать txn_limbo_replica_term, уходит на запись в вал и мы переключаемся на другой апплаер, с него приходит промот, который мы по идее не должны пропустить. Но мы пропускаем, и тоже пихаем его в очередь на запись в вал, просто потому что первая запись в вал еще не успела отработать. Получается такая зависимость от таймингов, если запись отрабатывает быстро, то и фильтрация отловит плохой промот, а если нет, то не отловит. В итоге в вале сможет появиться промот, которого там быть не должно. Сейчас нам пофигу до такой ситуации, потому что мы просто игнорим такие вещи. Но раз мы хотим отваливаться с ошибкой, то отваливаться надо в ранней стадии, даже до того, как данные в вал попадают. Либо надо тогда быть готовым, к тому что в wal будут какие-то промоты которые надо проигнорировать на рестарте. > > >> And you should not do that. Before WAL write there should no be any > >> changes. **Zero changes before WAL write**. Before you write to WAL, > >> you can only validate requests. Using `const struct txn_limbo *`. With > >> zero changes. > > > > If we write screwed PROMOTEs request into our WAL then this patch is not > > needed at all. > > Я не говорил, что надо писать плохие PROMOTE. Я говорю, что ты можешь > их отсеивать с ошибкой не делая никаких изменений состояния лимба до > записи в WAL. Да вот похоже, что не могу (если без локов). > Я так понимаю, ты пытаешься как-то защититься от того, что одновременно > пришло несколько PROMOTE, и пока один пишется, надо остальные сразу > отлупить? Так делает для обычных данных аплаер - он двигает vclock > кластера до записи в WAL, и копирует его в replicaset.vclock если > запись удалась. При этом если во время записи придут еще такие же > транзакции от других инстансов, то они сразу отфильтруются. > > Но в лимбе нет такой проблемы, что все надо делать параллельно. При > любых "паралеллельных" промоутах, конфирмах и прочих изменениях > состояния лимба лучше просто брать на него лок и все. Эти вещи > параллельно от разных инстансов приходить не должны во время нормальной > работы, так что это по перфу самого частого случая не ударит нисколько, > а код упростит значительно. Ну технически да, можно лок\латч взять, для модификаций промота и вклок термов. Это уберет необходимость infly модификаций, что я сделал для filter phase. Я наоборот, хотел избежать локов, но давай действительно попробуем с локами. Если вдруг будет жесткая просадка, то вернемся на схему с inlfy переменными и их обновлениями после записи в вал. Я пока бранч старый удалять не буду. Cyrill