Description:
When mysqld is started with --initialize and binlog enabled, all commands related to 'mysql' and 'performance_schema' instances go into binlog.
This creates very inconvenient behavior for expected action sequence when deploying instances for GTID replication. Expected sequence is:
1) create desired my.cnf (specifying dozen parameters required for GTID-replication)
2) initialize 5.7 master and slave using --initialize option
3) set up replication using AUTO_POSITION=1
Because of this bug - initialization commands from master are tryingto be replicated, which may lead to various unwanted effects.
E.g. if some filters like 'binlog-ignore-db=mysql' exists - P_S tables will be gone from Slave because they are actually executed in 'mysql' database:
use `mysql`/*!*/;
CREATE TABLE performance_schema.cond_instances(NAME VARCHAR(128) not null,OBJECT_INSTANCE_BEGIN BIGINT unsigned not null)ENGINE=PERFORMANCE_SCHEMA
How to repeat:
--intitialize 5.7 Master and Slave with following options:
log-bin
gtid_mode=ON
binlog-ignore-db=mysql
--execute on slave CHANGE MASTER ... AUTO_POSITION=1
--observe that all tables in P_S are dropped.
Suggested fix:
This particular test case may be fixed by executing CREATE TABLE for P_S not in mysql database, but I believe that the problem is more generic.
There is no need to enable binlog during initialize, because binlog is intended to be loaded (or replicated) only into already initialized instances.
