When a replica fails due to corruption or drift, the standard solution is to rebuild it from a fresh copy of the master when pt-table-sync is not an option. Traditionally, when we need to build a new replica, we use a physical backup for speed, but there are some cases where you still need logical backups. For instance, when you migrate to a specific vendor (i.e.: MariaDB to MySQL) or storage engines (in the past MyISAM to InnoDB and nowadays from InnoDB to RocksDB), upgrade to a new database version or move to a cloud based solution. This is where a logical backup shines, offering portability and simplicity, but only if it can be performed quickly. MyDumper emerges as the essential, modern solution, delivering the best of both worlds: the cross-platform, cross-version flexibility of a logical dump combined with the parallel, multi-threaded speed previously reserved for physical methods, making it the clear choice for rapidly rebuilding a consistent replica.

Take the backup

The first step is to take the backup. We have multiple arguments which we can use with mydumper, for this example we are going to use:

The first 3 are related to logging and backup dir, the second line is for ignoring mysql and sys schemas and finally –source-data will instruct mydumper to save in the metadata file, all the info required for the replication configuration after the restore under the section [source].
This is an example of the output:

As we can see, this options are enabled:

However, the execution of the commands are disabled:

Which is needed to automatically configure the replication.

Configure replication

By default, the SOURCE_LOG_FILE and SOURCE_LOG_POS will be used, but you can set the GTID position if you configure SOURCE_AUTO_POSITION = 1.
As you might know, to set up replication we need to execute CHANGE SOURCE. However, depending on your use case, you might need to RESET REPLICA and after executing the CHANGE SOURCE you usually execute START REPLICA. This can be done by myloader automatically if you set it up in the metadata file using:

Or you can use –source-data=7 as a parameter in myloader. Yes! myloader also accepts –source-data.
Depending your use case, you might need to configure in the metadata file, this other options:

As there are multiple use cases:
If you want want to rebuild the replica from scratch then you will need to configure like this:

You already have a replication up and running and you want to rebuild it without changing the host or credentials, then you can configure just in this way:

SSL is another option that is possible to set up in –source-data on myloader, instead of using SOURCE_SSL on the metadata file. The full list of options are: exec_start_slave (1), exec_change_master (2), exec_reset_slave (4), SSL (8), auto_position (16) and exec_start_replica_until (32). Depending on the configuration that you want to set up and the statements that you want to execute, you will need to sum the values and pass it to –source-data.

Restore

After configure the metadata file, you can execute the myloader, which will look like:

In the log, you will find that myloader has send the commands:

mydumper is sending the command but is not checking the output which means that if the replication failed to configure or it was not able to start, you will need to manually check it and fix it. However, it will detect if the command failed, for example if SUORCE_USER is used instead of SOURCE_USER:

Partial rebuild on a stopped replica

There is an interesting use case where we can use START REPLICA UNTIL to fix drift on some tables where pt-table-sync or rebuilding the whole replica are not possible.
Let’s say we have a source and a replica, and we found that data has drifted on the replica and the replication process has stopped with an error like this:

We checked the binary log and it is failing due updates over a set of rows:

We check the database and it is true, the data has drifted:
Source:

Replica:

With MyDumper we can rebuild the table following this procedure:
We need to ignore the table to allow the replica to catchup

Once that the replica is up to date we need to stop the replica:

and take the backup on the Source server:

We are using -T to take the backup of the problematic table and –source-data will enable the replication variables that we need on the metadata file.
Then, we restore the table with the correct value on –source-data

The 32 is to execute the START REPLICA UNTIL.
Finally, we remove the ignore table option and start the replica again:

The START REPLICA UNTIL executed at the beginning of backup by myloader will force the replica to stop at the point where we took the backup of the table, allowing us to continue the replication in a consistent scenario.

Conclusions

The shift from legacy dumping methods to MyDumper represents more than just a performance boost; it represents a modernized approach to data integrity and mobility. By decoupling the backup process from the constraints of single-threaded execution, DBAs can now handle massive datasets with the same agility they once reserved for small test environments.

Incorporating MyDumper into your standard operational playbook ensures you are prepared for the unpredictable—whether it’s an emergency replica rebuild or a planned architectural migration. In an era where data volumes continue to scale exponentially, having a tool that balances logical flexibility with parallelized speed, MyDumper becomes a necessity. Keep it in your toolkit, and the next time you face a “logical-only” recovery scenario, you’ll be doing so with a significant competitive advantage.

Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments