Heim  >  Artikel  >  Datenbank  >  Einführung in die Archivierung neuer MySQL-Funktionen

Einführung in die Archivierung neuer MySQL-Funktionen

angryTom
angryTomnach vorne
2019-08-07 16:43:052879Durchsuche

Einführung in die Archivierung neuer MySQL-Funktionen

MySQL 8.0.17 wurde veröffentlicht. Nachdem ich den Versionshinweis gelesen hatte, stellte ich fest, dass die Redo-Log-Archivierungsfunktion wie erwartet wiederhergestellt wurde. Der Grund, warum es „Recovery“ genannt wird, liegt darin, dass es in einer sehr alten Version von InnoDB (Versionen vor MySQL 4.0.6) existierte und später abgeschafft wurde. Zu diesem Zeitpunkt wurde die Redo-Log-Spiegelung noch unterstützt, und möglicherweise ältere MySQL-DBAs Ich habe immer noch den Eindruck, aber diese beiden Funktionen waren damals von geringem Nutzen und wurden daher gestrichen.

Vorschlags-Tutorial: Einführungsvideo-Tutorial zur MySQL-Datenbank

Dieses Mal startet InnoDB die Redo-Log-Archivierungsfunktion neu Nach Angaben des Entwicklungsteams geht es vor allem darum, das Problem der Backup-Konsistenz zu lösen. Im Dokument heißt es:

Backup utilities that copy redo log records may sometimes fail to keep pacewith redo log generation while a backup operation is in progress, resultingin lost redo log records due to those records being overwritten. The redolog archiving feature addresses this issue by sequentially writing redo logrecords to an archive file. Backup utilities can copy redo log records fromthe archive file as necessary, thereby avoiding the potential loss of data.
in lost redo log records due to those records being overwritten. The redo
log archiving feature addresses this issue by sequentially writing redo log
records to an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential loss of data.

Kurz gesagt: Die Backup-Geschwindigkeit kann nicht mit der Geschwindigkeit der Redo-Log-Erstellung mithalten. Infolgedessen wird das Redo-Log überschrieben und die Sicherung kann nicht garantiert werden Konsistenz. Mit der Redo-Log-Archivierung können Sie das Redo-Log-Archiv synchron starten, wenn die Sicherung beginnt, und das Redo-Log-Archiv synchron stoppen, wenn die Sicherung endet. Auf diese Weise können Sie dieses Problem vermeiden und die dabei generierten Daten verwenden Dieser Zeitraum wird nach Abschluss des Backups für die Datenwiederherstellung erneut protokolliert.

Um die Redo-Log-Archivierungsfunktion zu aktivieren, legen Sie einfach die Option innodb_redo_log_archive_dirs fest, die dynamische Online-Änderungen unterstützen kann, zum Beispiel:

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs/";

Geben Sie das Verzeichnis /data/mysql8-redologs/ als Redo-Log-Archiv an Speicherpfad und geben Sie als Bezeichnung "redolog-archiving-for-backup" an, d. h., dies ist das Speicherverzeichnis des Redo-Log-Archivs, das für die Sicherung vorgesehen ist.

Wir können auch ein anderes Verzeichnis für die zukünftige physische Replikation basierend auf dem Redo-Log festlegen (ich vermute, dass dies möglicherweise nicht so bald implementiert wird).

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs1/;redolog-archiving-for-repl:/data/mysql8-redologs2";

 Option innodb_redo_log_archive_dirs kann mehrere Verzeichnisse als Archiv-Redo-Log-Speicherorte angeben. Allerdings weist diese Option mehrere Einschränkungen auf:

Nach der Einrichtung können Sie mit der Redo-Log-Archivierung beginnen.

Der erste Parameter ist eine zuvor definierte Bezeichnung, und der zweite Parameter ist das Unterverzeichnis unter dem Verzeichnis, das der Bezeichnung entspricht, also "/data/mysql8-redologs/20190722". Wir können eine solche Redo-Log-Archivdatei im entsprechenden Verzeichnis sehen:

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 0 Jul 22 20:54 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

Die Zeichenfolge, die häufig im Dateinamen enthalten ist, ist die UUID dieser Instanz. Die Größe der Datei beträgt zu diesem Zeitpunkt 0 Byte.

Wir starten in einer weiteren Sitzung einen Sysbench-OLTP-Test. Nach der Ausführung des Sysbench-Tests haben wir die Redo-Log-Archivierungsarbeit gestoppt:

[root@yejr.me]> DO innodb_redo_log_archive_stop();Query OK, 0 rows affected (0.00 sec)

Ich habe die Änderungen im Redo-Log-LSN vor und nach dem Test wie folgt aufgezeichnet:

# 测试前的LSNLOG---Log sequence number          27938813989...# 测试后的LSNLOG---Log sequence number          27945024531
---
Log sequence number          27938813989
...

# 测试后的LSN
LOG
---
Log sequence number          27945024531

Der Unterschied zwischen den beiden LSNs ist: 6210542 Byte.

Dann überprüfen wir die Größe der Redo-Log-Archivdatei:

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 6213632 Jul 22 21:19 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

Sie können sehen, dass die Dateigröße 6213632 Bytes beträgt, was nur 3090 Bytes von den oben genannten 6210542 Bytes unterscheidet Das vom Test generierte Protokoll hat eine vergleichbare Größe. Wir können dieses Redo-Log später für die Datenwiederherstellung verwenden (die entsprechenden offiziellen Tools wurden jedoch noch nicht entwickelt, wir werden also abwarten).

Unter normalen Umständen hat die Redo-Log-Archivierung einen relativ geringen Einfluss auf die Leistung (sequentielles Schreiben). In Szenarien mit einer großen Anzahl hochgradig gleichzeitiger Transaktionen kann der Einfluss auf die Leistung etwas größer sein, aber keine Sorge Zu viel. In Zukunft werde ich bei Gelegenheit einen Leistungsvergleich durchführen.

Vor dem Start erinnerte mich Yueyue daran, dass das Backup-Tool der MySQL Enterprise Edition die Redo-Archivierung bereits im Voraus unterstützt. Ich hoffe, dass Percona Xtrabackup dies so schnell wie möglich auch unterstützen kann.

Zum Schluss noch etwas. Sie können auch feststellen, dass MySQL nach Version 8.0 ORACLE immer ähnlicher wird. Mit ORACLE, der erfolgreichsten kommerziellen Datenbank, vor uns, haben wir allen Grund, uns keine Sorgen um die Zukunft von MySQL zu machen.

Das obige ist der detaillierte Inhalt vonEinführung in die Archivierung neuer MySQL-Funktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:csdn.net. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen