Dalam posting saya sebelumnya, saya menjelaskan cara mengambil cadangan logis menggunakan utilitas shell mysql. Dalam posting ini, kita akan membandingkan kecepatan proses pencadangan dan pemulihan.
Uji Kecepatan Shell MySQL
Kita akan melakukan perbandingan kecepatan pencadangan dan pemulihan alat utilitas mysqldump dan shell MySQL.
Alat di bawah ini digunakan untuk perbandingan kecepatan:
- mysqldump
- util.dumpInstance
- util.loadDump
Konfigurasi Perangkat Keras
Dua server mandiri dengan konfigurasi identik.
Server 1
* IP:192.168.33.14
* CPU:2 Core
* RAM:4 GB
* DISK:SSD 200 GB
Server 2
* IP:192.168.33.15
* CPU:2 Core
* RAM:4 GB
* DISK:SSD 200 GB
Persiapan Beban Kerja
Pada Server 1 (192.168.33.14), Kami telah memuat sekitar 10 GB data.
Sekarang, Kami ingin memulihkan data dari Server 1 (192.168.33.14) ke Server 2 (192.168.33.15).
Pengaturan MySQL
Versi MySQL:8.0.22
Ukuran Pool Buffer InnoDB:1 GB
Ukuran File Log InnoDB:16 MB
Log Biner:Aktif
Kami memuat 50 juta data menggunakan sysbench.
[[email protected] sysbench]# sysbench oltp_insert.lua --table-size=5000000 --num-threads=8 --rand-type=uniform --db-driver=mysql --mysql-db=sbtest --tables=10 --mysql-user=root --mysql-password=****** prepare
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Initializing worker threads...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest7'...
Creating table 'sbtest1'...
Creating table 'sbtest2'...
Creating table 'sbtest8'...
Creating table 'sbtest5'...
Creating table 'sbtest6'...
Inserting 5000000 records into 'sbtest1'
Inserting 5000000 records into 'sbtest3'
Inserting 5000000 records into 'sbtest7
.
.
.
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest10'...Uji Kasus Satu
Dalam hal ini kita akan melakukan backup logis menggunakan perintah mysqldump.
Contoh
[[email protected] vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events --set-gtid-purged=OFF --all-databases |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gzstart_time =09-11-2020 17:40:02
end_time =09-11-2020 37:19:08
Butuh waktu hampir 20 menit 19 detik untuk membuang semua database dengan ukuran total sekitar 10 GB.
Kasus Uji Dua
Sekarang mari kita coba dengan utilitas shell MySQL. Kami akan menggunakan dumpInstance untuk mengambil cadangan penuh.
Contoh
MySQL localhost:33060+ ssl JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})
Acquiring global read lock
Global read lock acquired
All transactions have been started
Locking instance for backup
Global read lock has been released
Checking for compatibility with MySQL Database Service 8.0.22
NOTE: Progress information uses estimated values and may not be accurate.
Data dump for table `sbtest`.`sbtest1` will be written to 38 files
Data dump for table `sbtest`.`sbtest10` will be written to 38 files
Data dump for table `sbtest`.`sbtest3` will be written to 38 files
Data dump for table `sbtest`.`sbtest2` will be written to 38 files
Data dump for table `sbtest`.`sbtest4` will be written to 38 files
Data dump for table `sbtest`.`sbtest5` will be written to 38 files
Data dump for table `sbtest`.`sbtest6` will be written to 38 files
Data dump for table `sbtest`.`sbtest7` will be written to 38 files
Data dump for table `sbtest`.`sbtest8` will be written to 38 files
Data dump for table `sbtest`.`sbtest9` will be written to 38 files
2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed
1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed
Duration: 00:01:27s
Schemas dumped: 3
Tables dumped: 10
Uncompressed data size: 9.78 GB
Compressed data size: 4.41 GB
Compression ratio: 2.2
Rows written: 50000000
Bytes written: 4.41 GB
Average uncompressed throughput: 111.86 MB/s
Average compressed throughput: 50.44 MB/s Butuh total 1 menit 27 detik untuk membuang seluruh database (data yang sama seperti yang digunakan untuk mysqldump) dan juga menunjukkan kemajuannya yang akan sangat membantu untuk mengetahui berapa banyak cadangan yang telah selesai. Ini memberikan waktu yang diperlukan untuk melakukan pencadangan.
Paralelisme tergantung pada jumlah inti di server. Meningkatkan nilainya secara kasar tidak akan membantu dalam kasus saya. (Mesin saya memiliki 2 inti).
Uji Kecepatan Pemulihan
Pada bagian restorasi, kita akan mengembalikan cadangan mysqldump di server mandiri lainnya. File cadangan sudah dipindahkan ke server tujuan menggunakan rsync.
Kasus Uji 1
Contoh
[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -pButuh sekitar 16 menit 26 detik untuk memulihkan 10 GB data.
Kasus Uji 2
Dalam hal ini kami menggunakan utilitas shell mysql untuk memuat file cadangan pada host mandiri lainnya. Kami sudah memindahkan file cadangan ke server tujuan. Mari kita mulai proses pemulihan.
Contoh
MySQL localhost:33060+ ssl JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `cluster_control`
Executing DDL script for schema `proxydemo`
Executing DDL script for schema `sbtest`
.
.
.
2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done
2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done
[Worker001] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
[Worker002] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
Executing common postamble SQL
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)Butuh sekitar 40 menit 6 detik untuk memulihkan 10 GB data.
Sekarang mari kita coba nonaktifkan redo log dan mulai mengimpor data menggunakan mysql utilitas shell.
mysql> alter instance disable innodb redo_log;
Query OK, 0 rows affected (0.00 sec)
MySQL localhost:33060+ ssl JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
.
.
.
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)
0 warnings were reported during the load.Setelah menonaktifkan redo log, throughput rata-rata meningkat hingga 2x.
Catatan:Jangan nonaktifkan redo logging pada sistem produksi. Ini memungkinkan shutdown dan restart server saat redo logging dinonaktifkan, tetapi penghentian server yang tidak terduga saat redo logging dinonaktifkan dapat menyebabkan kehilangan data dan kerusakan instans.
Cadangan Fisik
Seperti yang mungkin telah Anda perhatikan, metode pencadangan logis, meskipun multithread, cukup memakan waktu bahkan untuk kumpulan data kecil yang kami uji. Ini adalah salah satu alasan mengapa ClusterControl menyediakan metode pencadangan fisik yang didasarkan pada penyalinan file - dalam hal ini kami tidak dibatasi oleh lapisan SQL yang memproses pencadangan logis melainkan oleh perangkat keras - seberapa cepat disk dapat membaca file dan seberapa cepat jaringan dapat mentransfer data antara node database dan server cadangan.
ClusterControl hadir dengan berbagai cara untuk mengimplementasikan pencadangan fisik, metode mana yang tersedia akan bergantung pada jenis cluster dan terkadang bahkan vendornya. Mari kita lihat Xtrabackup yang dijalankan oleh ClusterControl yang akan membuat cadangan penuh data di lingkungan pengujian kita.
Kali ini kita akan membuat cadangan ad-hoc tetapi ClusterControl memungkinkan Anda juga membuat jadwal pencadangan lengkap.
Di sini kami memilih metode pencadangan (xtrabackup) serta host yang kami akan mengambil cadangan dari. Kami juga dapat menyimpannya secara lokal di node atau dapat dialirkan ke instance ClusterControl. Selain itu, Anda dapat mengunggah cadangan ke cloud (AWS, Google Cloud, dan Azure didukung).
Pencadangan memakan waktu sekitar 10 menit untuk diselesaikan. Berikut log dari file cmon_backup.metadata.
[[email protected] BACKUP-9]# cat cmon_backup.metadata
{
"class_name": "CmonBackupRecord",
"backup_host": "192.168.33.14",
"backup_tool_version": "2.4.21",
"compressed": true,
"created": "2020-11-17T23:37:15.000Z",
"created_by": "",
"db_vendor": "oracle",
"description": "",
"encrypted": false,
"encryption_md5": "",
"finished": "2020-11-17T23:47:47.681Z"
}Sekarang mari kita coba yang sama untuk memulihkan menggunakan ClusterControl. ClusterControl> Cadangan> Pulihkan Cadangan
Di sini kami memilih opsi pemulihan cadangan, ini akan mendukung waktu dan berbasis log pemulihan juga.
Di sini kita memilih jalur sumber file cadangan dan kemudian server tujuan. Anda juga harus memastikan host ini dapat dijangkau dari node ClusterControl menggunakan SSH.
Kami tidak ingin ClusterControl mengatur perangkat lunak, jadi kami menonaktifkan opsi itu. Setelah pemulihan, server akan tetap berjalan.
Butuh sekitar 4 menit 18 detik untuk memulihkan 10GB data. Xtrabackup tidak mengunci database Anda selama proses pencadangan. Untuk database besar (100+ GB), ini memberikan waktu pemulihan yang jauh lebih baik dibandingkan dengan utilitas mysqldump/shell. lusterControl juga mendukung pencadangan dan pemulihan sebagian seperti yang dijelaskan oleh salah satu rekan saya di blognya:Pencadangan dan pemulihan sebagian.
Kesimpulan
Setiap metode memiliki kelebihan dan kekurangannya masing-masing. Seperti yang telah kita lihat, tidak ada satu metode yang paling cocok untuk semua yang perlu Anda lakukan. Kami perlu memilih alat kami berdasarkan lingkungan produksi kami dan target waktu untuk pemulihan.
