Bug #81947 binlog should be disabled during --initialize
Submitted: 21 Jun 2016 10:12 Modified: 19 Sep 2016 8:16
Reporter: Andrii Nikitin Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.7.13 OS:Any
Assigned to: CPU Architecture:Any

[21 Jun 2016 10:12] Andrii Nikitin
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:

--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.
[19 Sep 2016 8:16] Erlend Dahl
Duplicate of

Bug#78972 Enabling GTID at startup results in unnecessary GTID sets