A week ago Mydumper jumped to the 0.9.1 with a lot of improvements. In the Percona blog we can read:
A significant change included in this version now enables Mydumper to handle all schema objects!! So there is no longer a dependency on using mysqldump to ensure complex schemas are backed up alongside the data.
Let’s review some of the new features:
Full schema support for Mydumper/Myloader
Mydumper now takes care of backing up the schema, including Views and Merged tables. As a result, we now have these new associated options:
-d, --no-data Do not dump table data -G, --triggers Dump triggers -E, --events Dump events -R, --routines Dump stored procedures and functions
These options are not enabled by default to keep backward compatibility with actual mixed solutions using Mysqldump for DDLs.
Locking reduce options
--trx-consistency-only Transactional consistency only
You can think on this as --single-transaction for mysqldump, but still with binlog position. Obviously this position only applies to transactional tables (TokuDB included). One of the advantages of using this option is that the global read lock is only held for the threads coordination, so it’s released as soon as the transactions are started.
GTIDs and Multisource Slave
GTIDs are now recorded on the metadata file. Also Mydumper is now able to detect a multisource slave (MariaDB 10.1.x) and will record all the slaves coordinates.
Myloader single database restore
Until now the only option was to copy the database files to a different directory and restore from it. However, we now have a new option available:
-s, --source-db Database to restore
It can be used also in combination with -B, --database to restore to a different database name.
As always, we have created a x86_64 RPM version for Centos 6.x in our repo: