In this post I would like to review how my dumper for MySQL works from the point of view of locks. Since 0.6 serie we have different options, so I will try to explain how they work

As you may know mydumper is multithreaded and this adds a lot of complexity compared with other logical backup tools as it also needs to coordinate all threads with the same snapshot to be consistent. So let review how mydumper does this with the default settings.

By default mydumper uses 4 threads to dump data and 1 main thread

Main Thread

• FLUSH TABLES WITH READ LOCK

Dump Thread X

• START TRANSACTION WITH CONSISTENT SNAPSHOT;
• dump non-InnoDB tables

Main Thread

• UNLOCK TABLES

Dump Thread X

• dump InnoDB tables

As you can see in this case we need FTWRL for two things, coordinate transaction’s snapshots …

One of the tasks within Percona Remote DBA is to ensure we have reliable backups with minimal impact. To accomplish this, one of the tools our team uses is called mydumper. We use mydumper for logical backups because of several nice features. Some of them are:

• multithreaded, producing very fast backups compared to mysqldump
• almost no locking, if not using non innodb tables
• built-in compression
• separate files for each table, making it easy to restore single tables or schema, and the possibility to hardlink files reducing the space needed to keep history of backups. Also this feature give you the possibility to restore with more than one thread.

The mydumper project was started at the beginning of 2009 by …