Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Leistungstests mit MySQLdump und dem MySQL-Shell-Dienstprogramm

In meinem vorherigen Beitrag habe ich erklärt, wie man ein logisches Backup mit den mysql-Shell-Dienstprogrammen erstellt. In diesem Beitrag werden wir die Geschwindigkeit des Sicherungs- und Wiederherstellungsprozesses vergleichen.

MySQL Shell-Geschwindigkeitstest 

Wir werden einen Vergleich der Sicherungs- und Wiederherstellungsgeschwindigkeit von mysqldump- und MySQL-Shell-Utility-Tools durchführen.

Die folgenden Tools werden für den Geschwindigkeitsvergleich verwendet:

  • mysqldump
  • util.dumpInstance
  • util.loadDump

Hardwarekonfiguration

Zwei eigenständige Server mit identischen Konfigurationen.

Server 1

   * IP:192.168.33.14

   * CPU:2 Kerne

   * RAM:4 GB

   * FESTPLATTE:200-GB-SSD

Server 2

   * IP:192.168.33.15

   * CPU:2 Kerne

   * RAM:4 GB

   * FESTPLATTE:200-GB-SSD

Workload-Vorbereitung

Auf Server 1 (192.168.33.14) haben wir ca. 10 GB Daten geladen.

Jetzt wollen wir die Daten von Server 1 (192.168.33.14) auf Server 2 (192.168.33.15) wiederherstellen.

MySQL-Setup

MySQL-Version:8.0.22

Größe des InnoDB-Pufferpools:1 GB

Größe der InnoDB-Protokolldatei:16 MB

Binäre Protokollierung:Ein

Wir haben 50 Millionen Datensätze mit Sysbench geladen.

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

In diesem Fall erstellen wir ein logisches Backup mit dem Befehl mysqldump.

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

Es dauerte fast 20 Minuten und 19 Sekunden, um einen Dump aller Datenbanken mit einer Gesamtgröße von etwa 10 GB zu erstellen.

Testfall Zwei

Versuchen wir es jetzt mit dem MySQL-Shell-Dienstprogramm. Wir werden dumpInstance verwenden, um eine vollständige Sicherung zu erstellen.

Beispiel 

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

Es dauerte insgesamt 1 Minute 27 Sekunden, um einen Dump der gesamten Datenbank zu erstellen (dieselben Daten wie für mysqldump) und es zeigt auch den Fortschritt an, was sehr hilfreich sein wird, um zu wissen, wie viel von der Sicherung abgeschlossen ist. Es gibt die Zeit an, die für die Durchführung der Sicherung benötigt wurde.

Die Parallelität hängt von der Anzahl der Kerne im Server ab. Eine grobe Erhöhung des Wertes wird in meinem Fall nicht hilfreich sein. (Meine Maschine hat 2 Kerne).

Wiederherstellungsgeschwindigkeitstest 

Im Wiederherstellungsteil werden wir die mysqldump-Sicherung auf einem anderen eigenständigen Server wiederherstellen. Die Sicherungsdatei wurde bereits mit rsync auf den Zielserver verschoben.

Testfall 1 

Beispiel 

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

Es dauerte etwa 16 Minuten und 26 Sekunden, um die 10 GB an Daten wiederherzustellen.

Testfall 2 

In diesem Fall verwenden wir das mysql-Shell-Dienstprogramm, um die Sicherungsdatei auf einen anderen eigenständigen Host zu laden. Wir haben die Sicherungsdatei bereits auf den Zielserver verschoben. Beginnen wir mit dem Wiederherstellungsprozess.

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

Es dauerte etwa 40 Minuten und 6 Sekunden, um die 10 GB an Daten wiederherzustellen.

Lassen Sie uns nun versuchen, das Redo-Protokoll zu deaktivieren und den Datenimport mit mysql zu starten Shell-Dienstprogramm.

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

Nach dem Deaktivieren des Redo-Logs wurde der durchschnittliche Durchsatz auf das Doppelte erhöht.

Hinweis:Deaktivieren Sie die Redo-Protokollierung nicht auf einem Produktionssystem. Es ermöglicht das Herunterfahren und Neustarten des Servers, während die Redo-Protokollierung deaktiviert ist, aber ein unerwarteter Serverstopp, während die Redo-Protokollierung deaktiviert ist, kann zu Datenverlust und Instanzbeschädigung führen.

Physische Sicherungen 

Wie Sie vielleicht bemerkt haben, sind die logischen Backup-Methoden selbst bei einem kleinen Datensatz, mit dem wir sie getestet haben, ziemlich zeitaufwändig, selbst wenn sie Multithreading verwenden. Dies ist einer der Gründe, warum ClusterControl eine physische Sicherungsmethode bereitstellt, die auf dem Kopieren der Dateien basiert – in diesem Fall sind wir nicht durch die SQL-Schicht begrenzt, die die logische Sicherung verarbeitet, sondern durch die Hardware – wie schnell die Festplatte die Dateien lesen kann und wie schnell das Netzwerk Daten zwischen dem Datenbankknoten und dem Sicherungsserver übertragen kann.

ClusterControl bietet verschiedene Möglichkeiten, physische Sicherungen zu implementieren, welche Methode verfügbar ist, hängt vom Clustertyp und manchmal sogar vom Anbieter ab. Werfen wir einen Blick auf das von ClusterControl ausgeführte Xtrabackup, das eine vollständige Sicherung der Daten in unserer Testumgebung erstellt.

Wir werden diesmal eine Ad-hoc-Sicherung erstellen, aber ClusterControl lässt zu Sie erstellen auch einen vollständigen Backup-Zeitplan.

Hier wählen wir die Sicherungsmethode (xtrabackup) sowie den Host, den wir verwenden werden das Backup von nehmen. Wir können es auch lokal auf dem Knoten speichern oder es kann zu einer ClusterControl-Instanz gestreamt werden. Außerdem können Sie das Backup in die Cloud hochladen (AWS, Google Cloud und Azure werden unterstützt).

Die Sicherung dauerte etwa 10 Minuten. Hier die Protokolle aus der Datei 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"

 }

Nun versuchen wir dasselbe mit ClusterControl wiederherzustellen. ClusterControl> Sicherung> Sicherung wiederherstellen 

Hier wählen wir die Backup-Wiederherstellungsoption, die zeit- und protokollbasiert unterstützt Erholung auch.

Hier wählen wir den Quellpfad der Sicherungsdatei und dann den Zielserver. Sie müssen auch sicherstellen, dass dieser Host über SSH vom ClusterControl-Knoten aus erreichbar ist.

Wir möchten nicht, dass ClusterControl Software einrichtet, also haben wir diese Option deaktiviert. Nach der Wiederherstellung wird der Server am Laufen gehalten.

Es dauerte ungefähr 4 Minuten und 18 Sekunden, um die 10 GB Daten wiederherzustellen. Xtrabackup sperrt Ihre Datenbank während des Sicherungsvorgangs nicht. Bei großen Datenbanken (100+ GB) bietet es im Vergleich zum Dienstprogramm mysqldump/shell eine viel bessere Wiederherstellungszeit. Auch lusterControl unterstützt Teilsicherung und -wiederherstellung, wie einer meiner Kollegen in seinem Blog erklärt:Teilweise Sicherung und Wiederherstellung.

Schlussfolgerung

Jede Methode hat ihre eigenen Vor- und Nachteile. Wie wir gesehen haben, gibt es nicht eine Methode, die für alles, was Sie tun müssen, am besten funktioniert. Wir müssen unser Tool basierend auf unserer Produktionsumgebung und der Zielzeit für die Wiederherstellung auswählen.