Testování výkonu pomocí MySQLdump a MySQL Shell Utility

Ve svém předchozím příspěvku jsem vysvětlil, jak provést logickou zálohu pomocí nástrojů shellu mysql. V tomto příspěvku porovnáme rychlost procesu zálohování a obnovy.

Test rychlosti prostředí MySQL 

Provedeme srovnání rychlosti zálohování a obnovy nástrojů mysqldump a shellu MySQL.

Níže uvedené nástroje se používají k porovnání rychlosti:

• mysqldump
• util.dumpInstance
• util.loadDump

Konfigurace hardwaru

Dva samostatné servery s identickou konfigurací.

Server 1

   * IP:192.168.33.14

   * CPU:2 jádra

   * RAM:4 GB

   * DISK:200 GB SSD

Server 2

   * IP:192.168.33.15

   * CPU:2 jádra

   * RAM:4 GB

   * DISK:200 GB SSD

Příprava pracovní zátěže

Na Server 1 (192.168.33.14) jsme načetli přibližně 10 GB dat.

Nyní chceme obnovit data ze serveru 1 (192.168.33.14) na server 2 (192.168.33.15).

Nastavení MySQL

Verze MySQL:8.0.22

Velikost fondu vyrovnávací paměti InnoDB:1 GB

Velikost souboru protokolu InnoDB:16 MB

Binární protokolování:Zapnuto

Načetli jsme 50 milionů záznamů pomocí 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'...

Testovací případ 1

V tomto případě provedeme logickou zálohu pomocí příkazu mysqldump.

Příklad 

[[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.gz

start_time =2020-11-09 17:40:02

end_time   =2020-11-09 37:19:08

Vyjmutí všech databází o celkové velikosti přibližně 10 GB trvalo téměř 20 minut a 19 sekund.

Testovací případ 2

Nyní zkusme s shellem MySQL. K vytvoření úplné zálohy použijeme dumpInstance.

Příklad 

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    

Vypsání výpisu z celé databáze trvalo celkem 1 minutu 27 sekund (stejná data jako pro mysqldump) a také ukazuje její průběh, což bude opravdu užitečné, když zjistíte, jak velká část zálohy byla dokončena. Udává čas potřebný k provedení zálohy.

Paralelismus závisí na počtu jader na serveru. Hrubé zvýšení hodnoty v mém případě nepomůže. (Můj počítač má 2 jádra).

Test rychlosti obnovy 

V části obnovy obnovíme zálohu mysqldump na jiném samostatném serveru. Záložní soubor již byl přesunut na cílový server pomocí rsync.

Testovací případ 1 

Příklad 

[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -p

Obnovení 10GB dat trvalo přibližně 16 minut a 26 sekund.

Testovací případ 2 

V tomto případě používáme nástroj mysql shell k načtení záložního souboru na jiný samostatný hostitel. Záložní soubor jsme již přesunuli na cílový server. Začněme proces obnovy.

Příklad 

​ 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)

Obnovení 10 GB dat trvalo přibližně 40 minut a 6 sekund.

Nyní zkusme deaktivovat redo log a spustit import dat pomocí mysql nástroj shellu.

​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.

Po deaktivaci redo logu se průměrná propustnost zvýšila až 2x.

Poznámka:Nezakazujte opakování protokolování v produkčním systému. Umožňuje vypnutí a restart serveru, když je zakázáno opakované protokolování, ale neočekávané zastavení serveru při zakázání opakovaného protokolování může způsobit ztrátu dat a poškození instance.

Fyzické zálohy 

Jak jste si mohli všimnout, metody logického zálohování, i když jsou vícevláknové, jsou poměrně časově náročné i pro malou sadu dat, se kterou jsme je testovali. To je jeden z důvodů, proč ClusterControl poskytuje fyzickou zálohovací metodu založenou na kopírování souborů - v takovém případě nejsme omezeni SQL vrstvou, která zpracovává logické zálohování, ale spíše hardwarem - jak rychle dokáže disk číst soubory a jak rychle může síť přenášet data mezi databázovým uzlem a záložním serverem.

ClusterControl přichází s různými způsoby implementace fyzického zálohování, přičemž dostupná metoda bude záviset na typu clusteru a někdy i na dodavateli. Pojďme se podívat na Xtrabackup spuštěný ClusterControl, který vytvoří úplnou zálohu dat v našem testovacím prostředí.

Tentokrát se chystáme vytvořit zálohu ad-hoc, ale ClusterControl umožňuje vytvoříte také úplný plán zálohování.

Zde vybereme metodu zálohování (xtrabackup) a také hostitele, kterého vezmou zálohu z. Můžeme jej také uložit lokálně v uzlu nebo jej lze streamovat do instance ClusterControl. Navíc můžete zálohu nahrát do cloudu (podporovány jsou AWS, Google Cloud a Azure).

Dokončení zálohy trvalo asi 10 minut. Zde jsou protokoly ze souboru 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"

 }

Nyní zkusme totéž obnovit pomocí ClusterControl. ClusterControl> Záloha> Obnovit zálohu 

Zde vybíráme možnost obnovení zálohy, bude podporovat čas a protokol zotavení také.

Zde zvolíme cestu ke zdroji záložního souboru a poté cílový server. Musíte se také ujistit, že tohoto hostitele lze dosáhnout z uzlu ClusterControl pomocí SSH.

Nechceme, aby ClusterControl nastavoval software, proto jsme tuto možnost zakázali. Po obnovení zůstane server v chodu.

Obnovení 10GB dat trvalo přibližně 4 minuty a 18 sekund. Xtrabackup nezamyká vaši databázi během procesu zálohování. U velkých databází (100+ GB) poskytuje mnohem kratší dobu obnovy ve srovnání s nástrojem mysqldump/shell. LusterControl také podporuje částečné zálohování a obnovení, jak vysvětlil jeden z mých kolegů na svém blogu:Částečné zálohování a obnovení.

Závěr

Každá metoda má svá pro a proti. Jak jsme viděli, neexistuje jedna metoda, která by fungovala nejlépe pro vše, co musíte udělat. Musíme si vybrat náš nástroj na základě našeho produkčního prostředí a cílového času pro obnovu.