We are setting up a replicated slave from a MySQL database running 5.6.37. The slave is running the exact same version. All tables use InnoDB as engine. Mysqldump is invoked with:

mysqldump –master-data –routines –single-transaction –skip-lock-tables –databases db_1 db_2

We have two databases that should be replicated.

After reading documentation and following examples found when searching, this is the command that should be used for a live database. Specifically, –skip-lock-tables, to avoid a global read lock, though such a lock is acquired for the master data.

After restoring the slave with this backup and doing the necessary to connect to the master, we start seeing differences compared to master. Almost immediately we receive a write error due to primary key already being in use (autogenerated id). Via manual inspection, we also see rows in a table X on the slave, that are not present in master.

We use ROW as binlog format.

What these errors have in common is that the affected tables are tables that are purely written by triggers, either directly or indirectly via a stored procedure (called by a trigger).

For example, by checking timestamps that we store, I can determine that the rows we see in table X on the slave, that are not present on the master, were inserted during the time mysqldump was running. They are no longer present on the master as these rows are quickly deleted (poor man’s queue; one process inserts, another processes and deletes). So the rows were inserted after mysqldump was started, but are still available in the dump. But the rows are also deleted during the dump, but these removals never reach the slave via the replicated binlogs. Likewise, the error with primary key was also a write performed when the mysqldump was running.

It therefore feels that the usage of triggers to perform inserts doesn’t play well with –single-transaction, though that ought to be the expected behaviour(?). Am I wrong in this conclusion, or is it even possible that this MySQL version has known bugs? Again, all tables are InnoDB, no MyIASM. Other than that I don’t know what configuration could create this behaviour.

Next step would be to run mysqldump without –skip-lock-tables to create a global read lock. However, as that would effectively disable our database for about an hour, the live approach is obviously much preferred.