Join the DZone community and get the full member experience.
Join For FreeSensu is an open source monitoring event pipeline. Try it today.
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
- FLUSH TABLES WITH READ LOCK
- START TRANSACTION WITH CONSISTENT SNAPSHOT;
- dump non-InnoDB tables
- UNLOCK TABLES
- dump InnoDB tables
- FLUSH TABLES WITH READ LOCK
- START TRANSACTION WITH CONSISTENT SNAPSHOT;
- LOCK TABLES non-InnoDB
- UNLOCK TABLES
- dump non-InnoDB tables
- UNLOCK non-InnoDB
- dump InnoDB tables
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.
For the next release we will implement backup locks that will avoid us to run FTWRL.
The post mydumper [less] locking appeared first on MySQL Performance Blog.
Sensu: workflow automation for monitoring. Learn more—download the whitepaper.
Like This Article? Read More From DZone
Published at DZone with permission of Peter Zaitsev , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}