Test sys_vars.rpl_init_slave_func is unstable

[Laurynas Biveinis]

On 5.6 trunk:

sys_vars.rpl_init_slave_func w2 [ fail ]
        Test ended at 2016-12-23 09:37:59

CURRENT_TEST: sys_vars.rpl_init_slave_func
mysqltest: In included file "./include/assert.inc":
included from ./include/assert.inc at line 67:
At line 66: Test assertion failed in assert.inc
...
Assertion text: '@@global.max_connections = @start_max_connections'
Assertion condition: '@@global.max_connections = @start_max_connections'
Assertion condition, interpolated: '@@global.max_connections = @start_max_connections'
Assertion result: '0'

This is also https://jira.mariadb.org/browse/MDEV-10149

[Laurynas Biveinis (laurynas-biveinis)]

A new failure with extra diagnostics:

CURRENT_TEST: sys_vars.rpl_init_slave_func
mysqltest: In included file "./include/assert.inc":
included from ./include/assert.inc at line 75:
At line 74: Test assertion failed in assert.inc
...
Assertion text: '@@global.max_connections = @start_max_connections'
Assertion condition: '@@global.max_connections = @start_max_connections'
Assertion condition, interpolated: '@@global.max_connections = @start_max_connections'
Assertion result: '0'
Assertion debug statement:
SELECT @@global.max_connections, @start_max_connections;
@@global.max_connections @start_max_connections
152 151

This shows that init_slave command has been executed already. It is possible because of a race condition: the slave SQL thread is set to running state very early in its initialisation, and before running the init_slave command. Thus, it's possible that the initial "source include/master-slave.inc;" pick up the command.

[Laurynas Biveinis (laurynas-biveinis)]

     https://github.com/percona/percona-server/pull/1464
     https://github.com/percona/percona-server/pull/1465

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2222