[Tarantool-patches] [PATCH 2/2] replication: fix replica disconnect upon reconfiguration

Vladislav Shpilevoy v.shpilevoy at tarantool.org
Fri Oct 1 01:15:48 MSK 2021


Hi! Thanks for the patch!

See 6 comments below.

> diff --git a/src/box/box.cc b/src/box/box.cc
> index 219ffa38d..89cda5599 100644
> --- a/src/box/box.cc
> +++ b/src/box/box.cc> @@ -1261,7 +1261,9 @@ box_sync_replication(bool connect_quorum)
>  			applier_delete(appliers[i]); /* doesn't affect diag */
>  	});
>  
> -	replicaset_connect(appliers, count, connect_quorum);
> +	bool connect_quorum = strict;
> +	bool keep_connect = !strict;
> +	replicaset_connect(appliers, count, connect_quorum, keep_connect);

1. How about passing both these parameters explicitly to box_sync_replication?
I don't understand the link between them so that they could be one.

It seems the only case when you need to drop the old connections is when
you turn anon to normal. Why should they be fully reset otherwise?

> diff --git a/src/box/replication.cc b/src/box/replication.cc
> index 1288bc9b1..e5fce6c8c 100644
> --- a/src/box/replication.cc
> +++ b/src/box/replication.cc
> @@ -664,11 +681,11 @@ applier_on_connect_f(struct trigger *trigger, void *event)
>  
>  void
>  replicaset_connect(struct applier **appliers, int count,
> -		   bool connect_quorum)
> +		   bool connect_quorum, bool keep_connect)
>  {
>  	if (count == 0) {
>  		/* Cleanup the replica set. */
> -		replicaset_update(appliers, count);
> +		replicaset_update(appliers, count, keep_connect);

2. In case of count 0 it means all the appliers must be terminated,
mustn't they? So you could pass always false here. Up to you.

>  		return;
>  	}

3. A few lines below I see that all the appliers are started via
applier_start and gather connections. Even if you have them already.
Wasn't the point of this patchset not to create connections when you
already have them? You could find matches by URI even before you
try to create a connection.

Otherwise when I do this:

	box.cfg{replication = {3313, 3314}}
	box.cfg{replication = {3313, 3314, 3315}}

you create 3 connections in the second box.cfg. While you
could create just 1.

> diff --git a/src/box/replication.h b/src/box/replication.h
> index 4c82cd839..a8fed45e8 100644
> --- a/src/box/replication.h
> +++ b/src/box/replication.h
> @@ -439,10 +439,12 @@ replicaset_add_anon(const struct tt_uuid *replica_uuid);
>   * \param connect_quorum if this flag is set, fail unless at
>   *                       least replication_connect_quorum
>   *                       appliers have successfully connected.
> + * \param keep_connect   if this flag is set do not force a reconnect if the
> + *                       old connection to the replica is fine.

4. Why do you need to touch it even if the replica is not fine?
Shouldn't it reconnect automatically anyway? You could maybe force
it to reconnect right now if you don't want to wait until its
reconnect timeout expires.

>   */
>  void
>  replicaset_connect(struct applier **appliers, int count,
> -		   bool connect_quorum);
> +		   bool connect_quorum, bool keep_connect);
>  
> diff --git a/test/replication-luatest/gh_4669_applier_reconnect_test.lua b/test/replication-luatest/gh_4669_applier_reconnect_test.lua
> new file mode 100644
> index 000000000..62adff716
> --- /dev/null
> +++ b/test/replication-luatest/gh_4669_applier_reconnect_test.lua
> @@ -0,0 +1,42 @@
> +local t = require('luatest')
> +local fio = require('fio')
> +local Server = t.Server
> +local Cluster = require('test.luatest_helpers.cluster')

5. Are we using first capital letters for variable names now? Maybe
stick to the guidelines and use lower case letters?

> +
> +local g = t.group('gh-4669-applier-reconnect')
> +
> +local function check_follow_master(server)
> +    return t.assert_equals(
> +        server:eval('return box.info.replication[1].upstream.status'), 'follow')
> +end
> +
> +g.before_each(function()
> +    g.cluster = Cluster:new({})
> +    g.master = g.cluster:build_server(
> +        {}, {alias = 'master'}, 'base_instance.lua')
> +    g.replica = g.cluster:build_server(
> +        {args={'master'}}, {alias = 'replica'}, 'replica.lua')
> +
> +    g.cluster:join_server(g.master)
> +    g.cluster:join_server(g.replica)
> +    g.cluster:start()
> +    check_follow_master(g.replica)
> +end)
> +
> +g.after_each(function()
> +    g.cluster:stop()
> +end)
> +
> +-- Test that appliers aren't recreated upon replication reconfiguration.
> +g.test_applier_connection_on_reconfig = function(g)
> +    g.replica:eval(
> +        'box.cfg{'..
> +            'replication = {'..
> +                'os.getenv("TARANTOOL_LISTEN"),'..
> +                'box.cfg.replication[1],'..
> +            '}'..
> +        '}'
> +    )

6. Are we really supposed to write Lua code as Lua strings now?
You could use here [[ ... ]] btw, but the question still remains.

Not a comment for your patch. But it looks unusable. What if the
test would be a bit more complicated? Look at qsync tests for instance.
Imagine writing all of them as Lua strings with quotes and all.

Especially if you want to pass into the strings some parameters not
known in advance.

Could you maybe make it on top of master as a normal .test.lua test?

> +    check_follow_master(g.replica)
> +    t.assert_equals(g.master:grep_log("exiting the relay loop"), nil)
> +end
> 


More information about the Tarantool-patches mailing list