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
Dump Thread X
As you can see in this case we need FTWRL for two things, coordinate transaction’s snapshots and dump non-InnoDB tables in a consistent way. So we have have global read lock until we dumped all non-InnoDB tables.
What less locking does is this:
Main Thread
- FLUSH TABLES WITH READ LOCK
Dump Thread X
- START TRANSACTION WITH CONSISTENT SNAPSHOT;
LL Dump Thread X
Main Thread
LL Dump Thread X
- dump non-InnoDB tables
- UNLOCK non-InnoDB
Dump Thread X
So now the global read lock its in place until less-locking threads lock non-InnoDB tables, and this is really fast. The only downsize is that it uses double the amount of threads, so for the default (4 threads) we will end up having 9 connections, but always 4 will be running at the same time.
Less-locking really helps when you have MyISAM or ARCHIVE that are not heavily updated by production workload, also you should know that LOCK TABLE … READ LOCAL allows non conflicting INSERTS on MyISAM so if you use that tables to keep logs (append only) you will not notice that lock at all.
For the next release we will implement backup locks that will avoid us to run FTWRL.
