[Tarantool-patches] [RFC v29 3/3] test: add gh-6036-qsync-order test
Serge Petrenko
sergepetrenko at tarantool.org
Wed Feb 9 12:11:02 MSK 2022
01.02.2022 00:55, Cyrill Gorcunov пишет:
> To test that promotion requests are handled only when appropriate
> write to WAL completes, because we update memory data before the
> write finishes.
>
> Part-of #6036
>
> Signed-off-by: Cyrill Gorcunov<gorcunov at gmail.com>
> ---
> .../gh_6036_qsync_order_test.lua | 137 ++++++++++++++++++
> test/replication-luatest/suite.ini | 1 +
> 2 files changed, 138 insertions(+)
> create mode 100644 test/replication-luatest/gh_6036_qsync_order_test.lua
>
> diff --git a/test/replication-luatest/gh_6036_qsync_order_test.lua b/test/replication-luatest/gh_6036_qsync_order_test.lua
> new file mode 100644
> index 000000000..4c0059764
> --- /dev/null
> +++ b/test/replication-luatest/gh_6036_qsync_order_test.lua
> @@ -0,0 +1,137 @@
> +local t = require('luatest')
> +local cluster = require('test.luatest_helpers.cluster')
> +local asserts = require('test.luatest_helpers.asserts')
> +local helpers = require('test.luatest_helpers')
> +local log = require('log')
> +
> +local g = t.group('gh-6036', {{engine = 'memtx'}, {engine = 'vinyl'}})
You don't need to test engines here.
You always create a memtx space anyway.
> +
> +g.before_each(function(cg)
> + pcall(log.cfg, {level = 6})
You don't use log on the default instance. Why do you need that?
Does it help luatest output somehow?
> +
> + local engine = cg.params.engine
> +
> + cg.cluster = cluster:new({})
> +
Otherwise the test looks fine. Congratulations on writing your first
luatest-test!
Now on the promote/demote test. It should be fairly easy to implement.
You only need 2 servers with election mode off and synchro quorum = 1,
and a sync space.
1. promote server1
2. wait until the promotion is replicated
3. initiate wal delay on server2
4. issue box.ctl.promote() on server2 (it will block on box_issue_promote())
5. while server2 is blocked on writing a promote, do insert{1} on server1
6. wait for replication to server2 (wal is blocked, so rely on
ERRINJ_WAL_WRITE_COUNT)
7. unblock wal on server2
8. make sure insert{1} wasn't applied on server2.
Speaking of the demote test. Demotion only works on the queue owner, so
no one should be able
to write obsolete data during the DEMOTE wal write. I can't think of a
test here and I think we may
leave it untested.
More information about the Tarantool-patches
mailing list