Backup and restore methods are concepts that everyone knows the importance of. Over the years, open-source tools emerged like MyDumper, Xtrabackup, and Mariabackup. Also, with MySQL 8 new shell, new utils for dump and restore were introduced as well.
In this presentation, we are going to compare the newest backup/restore methods with the most used ones. We will see how parallelization can influence the speed of backup and restore process and also how the compression algorithms can influence the performance.
In this talk, we will compare mysqldump, mydumper/myloader, mysqlpump, MySQL Shell utils, and Xtrabackup.
Thank you, Vinnie, and hello everyone.
Let’s keep the pace, but at this time, speaking about the restore results.
As you might know, a good backup policy needs to consider the restore process as well, and for that, we are going to share the number we got over the tests that can help you with your decisions.
The restore process did run at the same machine.
Here is a brief review to refresh that information:
32 CPUs
Two nvme disks with the same size and throughput capacity.
The tools were on the latest version at that time.
And database size of 98GB.
Let’s start with the restore time.
As we can see, mysqldump took around 27hrs to finish the restore.
On the other hand, the other tools did perform way better.
But we can not forget to mention that as a single threaded tool, and theses results with mysqldump was expected on our side.
For a clear visualization, let's zoom in and look into that information without the noise of mysqldump.
Here we can see that either MySQLShell or myloader performed very well.
Myloader was the fastest, but by a slight margin running a no compressed restore, it took around 36minutes while MySQLShell took around 37 minutes, not that much, right?! But very good results for both, even during the higher parallelism tests.
But do you remember what I said at the begging of my presentation? So, yeahA good backup policy needs to consider a restore process as well.
I’m pointing out that because mysqlpump had a great battle during the backup tests. But unfortunately, when we moved to restoration, the lack of parallelism had a critical impact on its performance.
And last but not least, we have Xtrabackup with 2 minutes to restore non-compressed data and 7 minutes with a compressed dataset.
======================================# time cp no_compress/* /mysql/ -R
real 4m34.742s 274 seconds + 3 seconds prepare = 277 seconds
# time xtrabackup --prepare --target-dir=/backup/xtrabackup/no_compress/
real 0m3.013s
# time xtrabackup --decompress --parallel=16 --target-dir=/backup/xtrabackup/compress
real 2m28.039s
After these rounds of testing, let’s summarize backup and restore and see what we got at the end of this battle.
Here we have the result in seconds. And seem before, the battle between MySQLShell and myloader/mydumper didn’t finish.
Let’s zoom in again and see the numbers closer.
By a very close margin, the result time varies a little between both, and at this point, to pick a side, it goes more on personal preferences than numbers themselves, since both got very good values.
Mysqlpump had a great start with the power of parallelism for backups. However, when requested for restores, it, unfortunately, lacks such a feature, which caused the bump in the numbers leading the entire procedure to take around 3hours to complete.
And again, with excellent numbers, we have Xtrabackup, which took less than 10min to run a backup and restore routine.