From: Serge Petrenko via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tml <tarantool-patches@dev.tarantool.org>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v19 3/3] test: add gh-6036-qsync-order test Date: Tue, 5 Oct 2021 16:55:24 +0300 [thread overview] Message-ID: <1c992b36-7ad4-c68b-5252-69a6f1a7b67a@tarantool.org> (raw) In-Reply-To: <YVtvOYqBT2PLE+dE@grain> 05.10.2021 00:16, Cyrill Gorcunov пишет: > On Fri, Oct 01, 2021 at 03:30:41PM +0300, Serge Petrenko wrote: >> Thanks for the test! >> Please, find a couple of comments below. >> I think the test won't be flaky anymore once you fix my comments. > Thanks for comments, Serge! > >>> + >>> +box.once("bootstrap", function() >>> + box.schema.user.grant('guest', 'super') >>> +end) >> Looks like "election_replica.lua" suits our needs perfectly now. >> No need to introduce a new instance file. > yup, I updated the test, thanks! > >>> +test_run:wait_cond(function() return box.space.test:get{1} ~= nil end) >>> + | --- >>> + | - true >>> + | ... >>> + >> >> You may replace both calls with test_run:wait_lsn('master', 'replica') >> Even without switching. > Actually I need switch, otherwise i got stuck, so I use > > test_run:switch("master") > box.ctl.promote() > s = box.schema.create_space('test', {is_sync = true}) > _ = s:create_index('pk') > s:insert{1} > > test_run:switch("replica1") > test_run:wait_lsn('replica1', 'master') > > test_run:switch("replica2") > test_run:wait_lsn('replica2', 'master') > > > which works just fine Yep, that's what I meant. > >>> + >>> +-- >>> +-- Make replica1 been a leader and start writting data, >>> +-- the PROMOTE request get queued on replica2 and not >>> +-- yet processed, same time INSERT won't complete either >>> +-- waiting for PROMOTE completion first. >>> +test_run:switch("replica1") >>> + | --- >>> + | - true >>> + | ... >>> +box.ctl.promote() >>> + | --- >>> + | ... >>> +_ = require('fiber').create(function() box.space.test:insert{2} end) >>> + | --- >>> + | ... >>> + >>> +-- >> Prior to doing something on master, you should make sure >> replica2 has received the promote. >> "wait_lsn" won't work here, because WAL is disabled. You may try >> test_run:wait_cond(function() return box.space.test:get{2} ~= nil end) > Wait, this moment is dubious. Look, once we issue promote it get > stuck inside journal write procedure so the next "insert" won't > proceed until the promote finished. I understand that you point > to the potential race here because even promote() command may get > finished but slowed down on nework level and simply reach replica2 > out of other calls. I think without aditional debug output (such > as promote term exposed via box.info I did in previous series) we > can't be sure about timings and it seems that i've to return back > the box.info patch. I mean currently the command > > test_run:wait_cond(function() return box.space.test:get{2} ~= nil end) > > stucks forever because promote yet not finished and next 'insert' simply > has not been applied. Ok, I see. I didn't think of that at first. Look, your `box.info` patch won't help here as well. Since promote is blocked on its way to WAL, it isn't applied yet, so we won't see the term increase. There is a way to dect a blocked promote: There's ERRINJ_WAL_WRITE_COUNT. It's incremented each time you call wal_write. Even before the write is blocked. So you need to save ERRINJ_WAL_WRITE_COUNT, then do promote on replica1, then return to replica2 and wait until ERRINJ_WAL_WRITE_COUNT gets bigger than your saved value. -- Serge Petrenko
next prev parent reply other threads:[~2021-10-05 13:55 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-30 9:44 [Tarantool-patches] [PATCH v19 0/3] qsync: implement packet filtering (part 1) Cyrill Gorcunov via Tarantool-patches 2021-09-30 9:44 ` [Tarantool-patches] [PATCH v19 1/3] latch: add latch_is_locked helper Cyrill Gorcunov via Tarantool-patches 2021-09-30 9:44 ` [Tarantool-patches] [PATCH v19 2/3] qsync: order access to the limbo terms Cyrill Gorcunov via Tarantool-patches 2021-10-01 12:14 ` Serge Petrenko via Tarantool-patches 2021-10-01 12:31 ` Cyrill Gorcunov via Tarantool-patches 2021-10-01 12:37 ` Serge Petrenko via Tarantool-patches 2021-10-04 21:53 ` Cyrill Gorcunov via Tarantool-patches 2021-10-05 13:25 ` Serge Petrenko via Tarantool-patches 2021-10-05 21:52 ` Cyrill Gorcunov via Tarantool-patches 2021-09-30 9:44 ` [Tarantool-patches] [PATCH v19 3/3] test: add gh-6036-qsync-order test Cyrill Gorcunov via Tarantool-patches 2021-10-01 12:30 ` Serge Petrenko via Tarantool-patches 2021-10-04 21:16 ` Cyrill Gorcunov via Tarantool-patches 2021-10-05 13:55 ` Serge Petrenko via Tarantool-patches [this message] 2021-10-05 22:26 ` Cyrill Gorcunov via Tarantool-patches 2021-10-05 22:32 ` Cyrill Gorcunov via Tarantool-patches 2021-10-06 7:06 ` Cyrill Gorcunov via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1c992b36-7ad4-c68b-5252-69a6f1a7b67a@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=sergepetrenko@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v19 3/3] test: add gh-6036-qsync-order test' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox