sql >> Databasteknik >  >> RDS >> Mysql

Prestandatestning med MySQLdump och MySQL Shell Utility

I mitt tidigare inlägg förklarade jag hur man tar en logisk säkerhetskopia med hjälp av mysql-skalverktygen. I det här inlägget ska vi jämföra hastigheten på säkerhetskopieringen och återställningsprocessen.

MySQL Shell Speed ​​Test 

Vi ska göra en jämförelse av säkerhetskopierings- och återställningshastigheten för mysqldump- och MySQL-skalverktygen.

Nedanstående verktyg används för hastighetsjämförelse:

  • mysqldump
  • util.dumpInstance
  • util.loadDump

Hårdvarukonfiguration

Två fristående servrar med identiska konfigurationer.

Server 1

   * IP:192.168.33.14

   * CPU:2 kärnor

   * RAM:4 GB

   * DISK:200 GB SSD

Server 2

   * IP:192.168.33.15

   * CPU:2 kärnor

   * RAM:4 GB

   * DISK:200 GB SSD

Arbetsbelastningsförberedelse

På Server 1 (192.168.33.14) har vi laddat ca 10 GB data.

Nu vill vi återställa data från Server 1 (192.168.33.14) till Server 2 (192.168.33.15).

MySQL-inställningar

MySQL-version:8.0.22

InnoDB Buffer Pool Storlek:1 GB

InnoDB-loggfilstorlek:16 MB

Binär inloggning:På

Vi laddade 50 miljoner poster med 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'...

Testfall ett

I det här fallet kommer vi att ta en logisk säkerhetskopia med kommandot mysqldump.

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

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

Det tog nästan 20 minuter och 19 sekunder att ta en dumpning av alla databaser med en total storlek på cirka 10 GB.

Testfall två

Låt oss nu försöka med MySQL-skalverktyget. Vi kommer att använda dumpInstance för att ta en fullständig säkerhetskopia.

Exempel 

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 totalt 1 minut och 27 sekunder att ta en dump av hela databasen (samma data som används för mysqldump) och den visar också dess framsteg vilket kommer att vara till stor hjälp för att veta hur mycket av säkerhetskopieringen som har slutförts. Det ger den tid det tog att utföra säkerhetskopieringen.

Parallelliteten beror på antalet kärnor i servern. Att grovt öka värdet kommer inte att vara till hjälp i mitt fall. (Min maskin har 2 kärnor).

Återställningshastighetstest 

I återställningsdelen kommer vi att återställa mysqldump-säkerhetskopian på en annan fristående server. Säkerhetskopieringsfilen har redan flyttats till målservern med rsync.

Testfall 1 

Exempel 

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

Det tog cirka 16 minuter och 26 sekunder att återställa 10 GB data.

Testfall 2 

I det här fallet använder vi mysql-skalverktyget för att ladda säkerhetskopian på en annan fristående värd. Vi har redan flyttat säkerhetskopian till målservern. Låt oss börja restaureringsprocessen.

Exempel 
​ 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 cirka 40 minuter och 6 sekunder att återställa 10 GB data.

Låt oss nu försöka inaktivera redo-loggen och starta dataimporten med mysql skalverktyg.

​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 att ha inaktiverat redo-loggen ökades den genomsnittliga genomströmningen upp till 2x.

Obs:Inaktivera inte gör om loggning på ett produktionssystem. Den tillåter avstängning och omstart av servern medan omloggning är inaktiverad, men ett oväntat serverstopp medan omloggning är inaktiverat kan orsaka dataförlust och instanskorruption.

Fysiska säkerhetskopior 

Som du kanske har märkt är de logiska säkerhetskopieringsmetoderna, även om de är flertrådade, ganska tidskrävande även för en liten datamängd som vi testade dem mot. Detta är en av anledningarna till att ClusterControl tillhandahåller en fysisk säkerhetskopieringsmetod som är baserad på kopiering av filerna - i sådana fall är vi inte begränsade av SQL-lagret som bearbetar logisk säkerhetskopiering utan snarare av hårdvara - hur snabbt disken kan läsa filerna och hur snabbt nätverket kan överföra data mellan databasnoden och backupservern.

ClusterControl kommer med olika sätt att implementera fysiska säkerhetskopior, vilken metod som är tillgänglig beror på klustertypen och ibland även leverantören. Låt oss ta en titt på Xtrabackup som körs av ClusterControl som kommer att skapa en fullständig säkerhetskopia av data i vår testmiljö.

Vi kommer att skapa en ad-hoc-säkerhetskopia den här gången men ClusterControl låter du skapar också ett fullständigt säkerhetskopieringsschema.

Här väljer vi backupmetoden (xtrabackup) samt den värd som vi ska ta säkerhetskopian från. Vi kan också lagra det lokalt på noden eller så kan det streamas till en ClusterControl-instans. Dessutom kan du ladda upp säkerhetskopian till molnet (AWS, Google Cloud och Azure stöds).

Säkerhetskopieringen tog cirka 10 minuter att slutföra. Här loggarna från 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"

 }

Låt oss nu försöka samma sak för att återställa med ClusterControl. ClusterControl> Säkerhetskopiering> Återställ säkerhetskopia 

Här väljer vi alternativet för återställning av backup, det kommer att stödja tids- och loggbaserat återhämtning också.

Här väljer vi sökvägen till backupfilens källa och sedan destinationsservern. Du måste också se till att denna värd kan nås från ClusterControl-noden med hjälp av SSH.

Vi vill inte att ClusterControl ska konfigurera programvara, så vi inaktiverade det alternativet. Efter återställning kommer den att hålla servern igång.

Det tog cirka 4 minuter och 18 sekunder att återställa 10 GB data. Xtrabackup låser inte din databas under säkerhetskopieringsprocessen. För stora databaser (100+ GB) ger det mycket bättre återställningstid jämfört med mysqldump/shell-verktyget. LusterControl stöder också partiell säkerhetskopiering och återställning som en av mina kollegor förklarade i sin blogg:Partiell backup och återställning.

Slutsats

Varje metod har sina egna för- och nackdelar. Som vi har sett finns det inte en metod som fungerar bäst för allt du behöver göra. Vi måste välja vårt verktyg baserat på vår produktionsmiljö och måltid för återhämtning.


  1. MySQL återställningsfråga

  2. Utveckling av feltolerans i PostgreSQL:replikeringsfas

  3. Stänger JDBC-anslutningar i pool

  4. Hur SQLite Char() fungerar