Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.23
-
Linux 3.16.0-4-amd64 (CentOS 7)
Description
Words in bold should be replaced with values from your environment.
Can't create a replication slave using "single-transaction":
mysqldump --all-databases --single-transaction --gtid --master-data -h MASTER.HOST -u USERNAME -p PASSWORD | mysql -h SLAVE.HOST -u USERNAME -p PASSWORD
After dump/import is finished, replication will be broken (err.: HA_ERR_FOUND_DUPP_KEY). It looks like later transaction are visible to mysqldump.
Steps to reproduce:
- prepare two MariaDB databases (one on host MASTER.HOST, second on SLAVE.HOST )
- create a test db and an example table (example_create_stmts.sql) on MASTER.HOST
- start writing to the example table (mysql_insert_loop.sh)
- try to create a mysql slave using the above mysqldump command
- after the command completes, issue "START SLAVE;" on the SLAVE.HOST
You will end up with a broken replication.
A work-around is to use --lock-all-tables instead of --single-transaction. This will block all writes to the MASTER.HOST until the dump/import is complete.
Thanks for the test case, it was easy to reproduce.
It is not a bug though, just lack of functionality in TokUDB.
single-transaction feature depends not only on engine being transactional and capable of REPEATABLE-READ, but also on START TRANSACTION WITH CONSISTENT SNAPSHOT being supported. It is not the case with TokuDB, that's why it doesn't work.
Same happens with upstream (TokuDB on Percona server 5.7). I suppose you could file a feature request for them to implement WITH CONSISTENT SNAPSHOT.
Meanwhile, I think it deserves mentioning in documentation for mysqldump. Even though technically it indicates only InnoDB being supported for single-transaction, the focus is on the engine being transactional, so it's reasonable to assume that for TokuDB it should also work, which is not true.