sql >> Database >  >> RDS >> Mysql

Prestatietests met MySQLdump en het MySQL Shell-hulpprogramma

In mijn vorige post heb ik uitgelegd hoe je een logische back-up kunt maken met behulp van de mysql shell-hulpprogramma's. In dit bericht zullen we de snelheid van het back-up- en herstelproces vergelijken.

MySQL Shell-snelheidstest 

We gaan een vergelijking maken van de back-up- en herstelsnelheid van mysqldump en MySQL shell-hulpprogramma's.

Hieronder worden tools gebruikt voor snelheidsvergelijking:

  • mysqldump
  • util.dumpInstance
  • util.loadDump

Hardwareconfiguratie

Twee zelfstandige servers met identieke configuraties.

Server 1

   * IP:192.168.33.14

   * CPU:2 kernen

   * RAM:4 GB

   * SCHIJF:200 GB SSD

Server 2

   * IP:192.168.33.15

   * CPU:2 kernen

   * RAM:4 GB

   * SCHIJF:200 GB SSD

Voorbereiding werklast

Op server 1 (192.168.33.14) hebben we ongeveer 10 GB aan gegevens geladen.

Nu willen we de gegevens herstellen van Server 1 (192.168.33.14) naar Server 2 (192.168.33.15).

MySQL-configuratie

MySQL-versie:8.0.22

InnoDB-bufferpoolgrootte:1 GB

InnoDB-logbestandsgrootte:16 MB

Binaire logboekregistratie:aan

We hebben 50 miljoen records geladen met 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'...

Testcase één

In dit geval gaan we een logische back-up maken met de opdracht mysqldump.

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

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

Het duurde bijna 20 minuten en 19 seconden om alle databases met een totale grootte van ongeveer 10 GB te dumpen.

Testcase twee

Laten we het nu eens proberen met het MySQL-shell-hulpprogramma. We gaan dumpInstance gebruiken om een ​​volledige back-up te maken.

Voorbeeld 

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

Het kostte in totaal 1 minuut en 27 seconden om de hele database te dumpen (dezelfde gegevens als gebruikt voor mysqldump) en het laat ook de voortgang zien, wat erg handig zal zijn om te weten hoeveel van de back-up is voltooid. Het geeft de tijd aan die nodig was om de back-up uit te voeren.

Het parallellisme hangt af van het aantal cores in de server. Het grofweg verhogen van de waarde zal in mijn geval niet helpen. (Mijn machine heeft 2 kernen).

Restauratiesnelheidstest 

In het herstelgedeelte gaan we de mysqldump-back-up terugzetten op een andere zelfstandige server. Het back-upbestand is al met rsync naar de doelserver verplaatst.

Testcase 1 

Voorbeeld 

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

Het duurde ongeveer 16 minuten en 26 seconden om de 10 GB aan gegevens te herstellen.

Testcase 2 

In dit geval gebruiken we mysql shell-hulpprogramma om het back-upbestand op een andere zelfstandige host te laden. We hebben het back-upbestand al naar de doelserver verplaatst. Laten we beginnen met het herstelproces.

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

Het duurde ongeveer 40 minuten en 6 seconden om de 10 GB aan gegevens te herstellen.

Laten we nu proberen het logboek voor opnieuw uitvoeren uit te schakelen en het importeren van gegevens te starten met mysql shell-hulpprogramma.

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

Na het uitschakelen van het logboek voor opnieuw uitvoeren, werd de gemiddelde doorvoer tot 2x verhoogd.

Opmerking:Schakel het opnieuw loggen niet uit op een productiesysteem. Het staat afsluiten en herstarten van de server toe terwijl het opnieuw uitvoeren van logboekregistratie is uitgeschakeld, maar een onverwachte onderbreking van de server terwijl het opnieuw uitvoeren van logboekregistratie is uitgeschakeld, kan gegevensverlies en beschadiging van de instantie veroorzaken.

Fysieke back-ups 

Zoals je misschien hebt gemerkt, zijn de logische back-upmethoden, zelfs als ze multithreaded zijn, behoorlijk tijdrovend, zelfs voor een kleine dataset waarop we ze hebben getest. Dit is een van de redenen waarom ClusterControl een fysieke back-upmethode biedt die is gebaseerd op het kopiëren van de bestanden - in dat geval worden we niet beperkt door de SQL-laag die logische back-ups verwerkt, maar eerder door hardware - hoe snel de schijf de bestanden kan lezen en hoe snel het netwerk gegevens kan uitwisselen tussen het databaseknooppunt en de back-upserver.

ClusterControl wordt geleverd met verschillende manieren om fysieke back-ups te implementeren, welke methode beschikbaar is, hangt af van het clustertype en soms zelfs van de leverancier. Laten we eens kijken naar de Xtrabackup uitgevoerd door ClusterControl die een volledige back-up zal maken van de gegevens in onze testomgeving.

We gaan deze keer een ad-hoc back-up maken, maar ClusterControl laat u maakt ook een volledig back-upschema.

Hier kiezen we de back-upmethode (xtrabackup) en de host die we de back-up gaan halen. We kunnen het ook lokaal opslaan op het knooppunt of het kan worden gestreamd naar een ClusterControl-instantie. Bovendien kunt u de back-up uploaden naar de cloud (AWS, Google Cloud en Azure worden ondersteund).

Het duurde ongeveer 10 minuten om de back-up te voltooien. Hier de logs van het bestand 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"

 }

Laten we nu hetzelfde proberen om te herstellen met ClusterControl. ClusterControl> Back-up> Back-up herstellen 

Hier kiezen we de herstelback-upoptie, deze ondersteunt tijd en loggebaseerd herstel ook.

Hier kiezen we het bronpad van het back-upbestand en vervolgens de doelserver. Je moet er ook voor zorgen dat deze host kan worden bereikt vanaf het ClusterControl-knooppunt met behulp van SSH.

We willen niet dat ClusterControl software instelt, dus hebben we die optie uitgeschakeld. Na herstel blijft de server draaiende.

Het duurde ongeveer 4 minuten en 18 seconden om de 10 GB aan gegevens te herstellen. Xtrabackup vergrendelt uw database niet tijdens het back-upproces. Voor grote databases (100+ GB) biedt het een veel betere hersteltijd in vergelijking met het hulpprogramma mysqldump/shell. Ook lusterControl ondersteunt gedeeltelijke back-up en herstel, zoals een van mijn collega's heeft uitgelegd in zijn blog:Gedeeltelijke back-up en herstel.

Conclusie

Elke methode heeft zijn eigen voor- en nadelen. Zoals we hebben gezien, is er niet één methode die het beste werkt voor alles wat u moet doen. We moeten onze tool kiezen op basis van onze productieomgeving en de beoogde hersteltijd.


  1. Zet Unix-tijdstempel om in voor mensen leesbare datum met MySQL

  2. Foutafhandeling op afgestudeerd niveau

  3. Hoe u werkdagen of uren tussen twee datums kunt krijgen

  4. Welk MySQL-gegevenstype moet worden gebruikt voor het opslaan van booleaanse waarden