![© 2022 Percona | Confidential
It is possible to squeeze more juice from logical restores. Disabling writes in
the binary logs, flexing ACID properties so it makes writes asynchronous,
disable double write buffer are options that can be taken if you can trade
reliability for performance.
Blog post:
How to improve InnoDB performance by 55% for write-bound loads
Example of settings:
[mysqld]
innodb_write_io_threads=8 innodb_buffer_pool_size=20G
innodb_log_file_size = X Gb #Small log files, more page flush
innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=0
skip-innodb-doublewrite #commented or not depending on test
Analysis](https://image.slidesharecdn.com/backupandrestoreperformance-220213171953/95/MySQL-backup-and-restore-performance-22-638.jpg)
MySQL backup and restore performance
- 1. Backup/Restore tools performance comparison Vinicius M Grippa/Support Engineer Jean Da Silva/Support Engineer
- 2. © 2022 Percona | Confidential About us • Support Engineers • Working with MySQL and MongoDB • Vinicius Grippa - https://www.linkedin.com/in/vinicius- grippa/ • Jean Da Silva - https://www.linkedin.com/in/jenunes/ 2
- 3. Backup Tools
- 4. © 2022 Percona | Confidential Backup Tools ● mysqldump ● mydumper ● mysqlpump ● Xtrabackup ● MySQL shell
- 5. © 2022 Percona | Confidential Backup Options ● Physical Backups - Copies all the physical files that belongs to the database. ● Logical Backup - You don't take copies of files, you only extracted data from the data files into dump files.
- 6. © 2022 Percona | Confidential Things to consider when taking a backup ● Network Encryption ● File encryption ● Single Thread x Multi Thread ● Data compression ● Backup Size ● Backup Time ● Restore Time ● Total time ● PITR ● etc…
- 7. Backup Benchmark The first side of the history…
- 8. © 2022 Percona | Confidential Benchmark Specs of the benchmark: ● 32 CPUs ( m5dn.8xlarge ) ● 128GB Memory ● 2x io1 disks 600GB and 5000 IOPs ● Centos 7.9 Tool Version: ● MySQL 8.0.26 ● MySQL shell 8.0.26 ● mydumper 0.11.5 – gzip ● mydumper 0.11.5 – zstd ● Xtrabackup 8.0.26 Database: ● 96GB (In-Disk) ● 90 Tables ● Different sizes ● tpcc (sysbench)
- 9. © 2022 Percona | Confidential Results
- 10. © 2022 Percona | Confidential Results
- 11. © 2022 Percona | Confidential Results
- 12. © 2022 Percona | Confidential Results without mysqldump
- 13. © 2022 Percona | Confidential Questions and comments 13 Does xtrabackup support zstd? A: No, but we opened a FR: https://jira.percona.com/browse/PXB-2669 You can "pipe" xtrabackup output TCP/IP vs Socket? A: The impact is neglectable. SSL vs No SSL? Compared both options with mydumper and it does not seem a big difference: SSL: 76s No SSL: 72s
- 14. Restore Benchmark The second side of the history…
- 15. © 2022 Percona | Confidential Benchmark Specs of the benchmark: ● 32 CPUs ( m5dn.8xlarge ) ● 128GB Memory ● 2x io1 disks 600GB and 5000 IOPs ● Centos 7.9 Tool Version: ● MySQL 8.0.26 ● MySQL shell 8.0.26 ● mydumper 0.11.5 – gzip ● mydumper 0.11.5 – zstd ● Xtrabackup 8.0.26 Database: ● 96GB (In-Disk) ● 90 Tables ● Different sizes ● tpcc (sysbench)
- 16. © 2022 Percona | Confidential Benchmark
- 17. © 2022 Percona | Confidential Benchmark (without mysqldump)
- 18. Conclusion The final side of the history…
- 19. © 2022 Percona | Confidential Backup + Restore
- 20. © 2022 Percona | Confidential Backup + Restore (without mysqldump)
- 21. © 2022 Percona | Confidential Xtrabackup seems to offer the best balance between backup/restore time with backup size (when using compression). mydumper/myloader and MySQL shell are the best backup/restore options for logical backup. mysqlpump offers great backup capacity, but the lack of parallelism to restore the data is a great disadvantage for the tool. Overall, using compression does not impact significantly the performance of backup/restore. The big advantage is disk saving. The parallelism offers a big boost in performance. However, the benefits of increasing the number of threads are limited by the I/O capacity. Analysis
- 22. © 2022 Percona | Confidential It is possible to squeeze more juice from logical restores. Disabling writes in the binary logs, flexing ACID properties so it makes writes asynchronous, disable double write buffer are options that can be taken if you can trade reliability for performance. Blog post: How to improve InnoDB performance by 55% for write-bound loads Example of settings: [mysqld] innodb_write_io_threads=8 innodb_buffer_pool_size=20G innodb_log_file_size = X Gb #Small log files, more page flush innodb_flush_method=O_DIRECT innodb_flush_log_at_trx_commit=0 skip-innodb-doublewrite #commented or not depending on test Analysis
- 23. © 2022 Percona | Confidential Choice of the presenter So Vinicius/Jean, which backup and restore method would you pick? And why?
- 24. © 2022 Percona | Confidential Choice of the presenter - Vinicius Grippa If it is a one-time backup, I would use MySQL Shell (in case of MySQL 8) or mydumper/myloader (MySQL 5.7 and 8). I'm familiar with the commands and they execute relatively fast, which is good to rebuild replica servers. If it is a backup/restore routine, I would go with xtrabackup. Mainly because of the PITR feature.
- 25. © 2022 Percona | Confidential Choice of the presenter - Jean da Silva Generally speaking, I would choose to go with Xtrabackup. It’s nice to see tools like MySQLShell and mydumper/myloader with great numbers over the tests, and mainly being a viable option for the community. But thinking in the routine as whole or even to quickly build a node. Xtrabackup provides the necessary means for that.
- 26. 谢谢 Thank you Grazie Obrigado Gracias percona.com/contact | info@percona.com vinicius.grippa@percona.com
Editor's Notes
- #15: 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.
- #16: 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.
- #17: 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.
- #18: 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, yeah A 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
- #19: After these rounds of testing, let’s summarize backup and restore and see what we got at the end of this battle.
- #20: 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.
- #21: 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.
- #22: Vinicius
- #23: Vinicius