Bug #77122 mysql_install_db always writes to the binary log which can break replication

• Submitted: 21 May 2015 18:23
• Modified: 7 Jul 2015 11:49
• Reporter: Pim VAN DER WAL
• Status: Verified
• Category: MySQL Server: Installing
• Severity: S3 (Non-critical)
• Version: 5.5.41, 5.6.25, 5.6.27
• OS: Linux (Ubuntu 12.04.4 LTS 64 bit)
• CPU Architecture: Any
• Tags: mysql_install_db

[21 May 2015 18:23] Pim VAN DER WAL

Description:
Running mysql_install_db causes DDL to be run even if the MySQL data dir already exists. By itself this is no problem except that if binary logging is enabled the changes also get written to the binary log. Since these changes are always local they should not be written to the binary log. If replication is enabled it can cause unwanted system table upgrades on the slaves, empty performance_schema databases on the slaves and, if the slave is being upgraded as well, replication conflicts.

I verified this behavior on 5.5.41 and 5.6.24.

mysql_upgrade has similar behavior but has the --skip-write-binlog option. For both mysql_install_db and mysql_upgrade the default behavior should be not to write to the binary logs.

How to repeat:
Run mysql_install_db and check the binary logs for DDL statements on system tables.

Suggested fix:
Change mysql_install_db to stop writing to the binary logs or add an option for this and make it the default.

[7 Jul 2015 11:49] MySQL Verification Team

Hello Pim,

Thank you for the report.

Thanks,
Umesh