sql >> Database teknologi >  >> RDS >> Mysql

Ydelsestest ved hjælp af MySQLdump og MySQL Shell Utility

I mit tidligere indlæg forklarede jeg, hvordan man tager en logisk sikkerhedskopi ved hjælp af mysql shell-værktøjerne. I dette indlæg skal vi sammenligne hastigheden af ​​backup- og gendannelsesprocessen.

MySQL Shell Speed ​​Test 

Vi skal lave en sammenligning af sikkerhedskopierings- og gendannelseshastigheden for mysqldump og MySQL shell-værktøjer.

Nedenstående værktøjer bruges til hastighedssammenligning:

  • mysqldump
  • util.dumpInstance
  • util.loadDump

Hardwarekonfiguration

To selvstændige servere med identiske konfigurationer.

Server 1

   * IP:192.168.33.14

   * CPU:2 kerner

   * RAM:4 GB

   * DISK:200 GB SSD

Server 2

   * IP:192.168.33.15

   * CPU:2 kerner

   * RAM:4 GB

   * DISK:200 GB SSD

Forberedelse af arbejdsbelastning

På server 1 (192.168.33.14) har vi indlæst ca. 10 GB data.

Nu vil vi gendanne dataene fra Server 1 (192.168.33.14) til Server 2 (192.168.33.15).

MySQL-opsætning

MySQL-version:8.0.22

InnoDB Buffer Pool Størrelse:1 GB

InnoDB-logfilstørrelse:16 MB

Binær logning:Til

Vi indlæste 50 mio. poster ved hjælp af 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'...

Test Case One

I dette tilfælde tager vi en logisk sikkerhedskopi ved hjælp af mysqldump-kommandoen.

Eksempel 
[[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

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

Det tog næsten 20 minutter og 19 sekunder at tage et dump af alle databaser med en samlet størrelse på omkring 10 GB.

Testsag to

Lad os nu prøve med MySQL shell-værktøjet. Vi skal bruge dumpInstance til at tage en fuld backup.

Eksempel 

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

Det tog i alt 1 minut og 27 sekunder at tage et dump af hele databasen (samme data som brugt til mysqldump), og det viser også dens fremskridt, hvilket vil være virkelig nyttigt at vide, hvor meget af sikkerhedskopieringen er gennemført. Det giver den tid, det tog at udføre sikkerhedskopieringen.

Parallellen afhænger af antallet af kerner i serveren. Groft forøgelse af værdien vil ikke være nyttigt i mit tilfælde. (Min maskine har 2 kerner).

Gendannelseshastighedstest 

I gendannelsesdelen skal vi gendanne mysqldump-sikkerhedskopien på en anden selvstændig server. Sikkerhedskopieringsfilen blev allerede flyttet til destinationsserveren ved hjælp af rsync.

Testsag 1 

Eksempel 

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

Det tog omkring 16 minutter og 26 sekunder at gendanne de 10 GB data.

Testcase 2 

I dette tilfælde bruger vi mysql shell-værktøjet til at indlæse backup-filen på en anden selvstændig vært. Vi har allerede flyttet backupfilen til destinationsserveren. Lad os starte gendannelsesprocessen.

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

Det tog omkring 40 minutter og 6 sekunder at gendanne de 10 GB data.

Lad os nu prøve at deaktivere gentag-loggen og starte dataimporten ved hjælp af mysql shell-værktøj.

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

Efter deaktivering af gentag-loggen blev den gennemsnitlige gennemstrømning øget op til 2x.

Bemærk:Undlad at deaktivere logning igen på et produktionssystem. Det tillader lukning og genstart af serveren, mens logning igen er deaktiveret, men et uventet serverstop, mens logning igen er deaktiveret, kan forårsage datatab og forekomstkorruption.

Fysiske sikkerhedskopier 

Som du måske har bemærket, er de logiske sikkerhedskopieringsmetoder, selvom de er multithreaded, ret tidskrævende selv for et lille datasæt, som vi testede dem mod. Dette er en af ​​grundene til, at ClusterControl tilbyder en fysisk sikkerhedskopieringsmetode, der er baseret på kopiering af filerne - i sådanne tilfælde er vi ikke begrænset af SQL-laget, der behandler logisk sikkerhedskopiering, men snarere af hardware - hvor hurtigt disken kan læse filerne og hvor hurtigt netværket kan overføre data mellem databasenoden og backupserveren.

ClusterControl kommer med forskellige måder at implementere fysiske sikkerhedskopier på, hvilken metode der er tilgængelig afhænger af klyngetypen og nogle gange endda leverandøren. Lad os tage et kig på Xtrabackup'en udført af ClusterControl, som vil skabe en fuld backup af dataene i vores testmiljø.

Vi vil oprette en ad-hoc backup denne gang, men ClusterControl giver mulighed for du opretter også en fuld backup tidsplan.

Her vælger vi backupmetoden (xtrabackup) samt den vært, vi vil tage backup fra. Vi kan også gemme det lokalt på noden, eller det kan streames til en ClusterControl-instans. Derudover kan du uploade sikkerhedskopien til skyen (AWS, Google Cloud og Azure understøttes).

Sikkerhedskopieringen tog omkring 10 minutter at fuldføre. Her er logfilerne fra filen 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"

 }

Lad os nu prøve det samme for at gendanne ved hjælp af ClusterControl. ClusterControl> Sikkerhedskopiering> Gendan sikkerhedskopi 

Her vælger vi muligheden for gendannelse af sikkerhedskopiering, den vil understøtte tids- og logbaseret også genopretning.

Her vælger vi backupfilens kildesti og derefter destinationsserveren. Du skal også sørge for, at denne vært kan nås fra ClusterControl node ved hjælp af SSH.

Vi ønsker ikke, at ClusterControl skal konfigurere software, så vi deaktiverede denne mulighed. Efter gendannelse vil den holde serveren kørende.

Det tog omkring 4 minutter og 18 sekunder at gendanne de 10 GB data. Xtrabackup låser ikke din database under backup-processen. For store databaser (100+ GB) giver det meget bedre gendannelsestid sammenlignet med mysqldump/shell-værktøjet. LusterControl understøtter også delvis backup og gendannelse, som en af ​​mine kolleger forklarede i sin blog:Delvis backup og gendannelse.

Konklusion

Hver metode har sine egne fordele og ulemper. Som vi har set, er der ikke én metode, der fungerer bedst til alt, hvad du skal gøre. Vi skal vælge vores værktøj baseret på vores produktionsmiljø og målrette tid for genopretning.


  1. VBA-kode for at tilføje sammenkædet tabel med primærnøgle

  2. Sådan aktiverer du CDC på sæt af tabeller ELLER aktiverer på alle tabeller i en database i SQL Server - SQL Server Tutorial

  3. PL/SQL-program til at udskrive medarbejderoplysninger

  4. En databasemodel til en onlineundersøgelse. Del 2