Id
| Name |
|
1
| A |
|
2
| B |
|
3
| C |
|
4
| D |
1.2 Rückgängig-Parameter
MySQL-Parametereinstellungen im Zusammenhang mit dem Rückgängigmachen umfassen Folgendes:
mysql> show global variables like '%undo%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 |
| innodb_undo_directory | ./ |
| innodb_undo_log_truncate | OFF |
| innodb_undo_logs | 128 |
| innodb_undo_tablespaces | 3 |
+--------------------------+------------+
mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128 |
| innodb_undo_log_truncate | OFF |
+--------------------------------------+-------+
Steuern Sie die Größe der maximalen Rückgängig-Tablespace-Datei. Wenn innodb_undo_log_truncate gestartet wird, wird die Rückgängig-Tabelle gestartet Nur wenn der Platz die überschreitet innodb_max_undo_log_size Schwellenwert Versucht zu kürzen. Die Standardgröße dieses Werts beträgt 1 GB und die Standardgröße nach dem Abschneiden beträgt 10 MB.
Legen Sie die Anzahl der unabhängigen Rückgängig-Tabellenbereiche fest. Der Bereich liegt zwischen 0 und 128, der Standardwert ist 0. 0 bedeutet, dass der unabhängige Rückgängig-Tabellenbereich nicht geöffnet wird und das Rückgängig-Protokoll im gespeichert wird ibdata-Datei. Dieser Parameter kann nur beim Initialisieren der MySQL-Instanz angegeben werden. Wenn die Instanz erstellt wurde, kann dieser Parameter nicht geändert werden. Wenn die in der Datenbankkonfigurationsdatei.cnf angegebene Anzahl größer ist als die beim Erstellen der Instanz angegebene Anzahl. Das wird der Fall sein Der Start ist fehlgeschlagen, was darauf hinweist, dass die Parametereinstellung falsch ist.
Wenn dieser Parameter auf n (n>0) eingestellt ist, werden n Undo-Dateien (undo001, undo002 ... undo n) im Undo-Verzeichnis erstellt. Die Standardgröße jeder Datei beträgt 10 MB.
Wann müssen Sie diesen Parameter einstellen?
Wenn der DB-Schreibdruck hoch ist, können Sie einen unabhängigen UNDO-Tabellenbereich einrichten, das UNDO-LOG von der ibdata-Datei trennen und das Verzeichnis innodb_undo_directory für die Speicherung angeben. Es kann einer Hochgeschwindigkeitsfestplatte zugewiesen werden Erhöhen Sie die Lese- und Schreibleistung des UNDO LOG.
Der Bereinigungsthread von InnoDB wird entsprechend der innodb_undo_log_truncate-Einstellung, dem Parameterwert von innodb_max_undo_log_size und der Häufigkeit des Abschneidens zur Durchführung des Speicherplatzrecyclings und der Neuinitialisierung aktiviert oder deaktiviert isierung von Undo-Dateien.
Voraussetzung für die Wirksamkeit dieses Parameters ist, dass unabhängige Tabellenbereiche eingerichtet wurden und die Anzahl der unabhängigen Tabellenbereiche größer oder gleich 2 ist.
Beim Abschneiden der Rückgängig-Protokolldatei muss der Löschthread prüfen, ob aktive Transaktionen in der Datei vorhanden sind. Wenn nicht, muss die Rückgängig-Protokolldatei als nicht zuordenbar markiert werden In anderen Dateien aufgezeichnet, sodass mindestens zwei unabhängige Tabellenbereichsdateien erforderlich sind, um den Kürzungsvorgang auszuführen. Nach dem Markieren als nicht zuordenbar wird eine unabhängige Datei undo__trunc.log erstellt, um aufzuzeichnen, dass eine bestimmte Rückgängig-Protokolldatei vorhanden ist Die Datei „undo__trunc.log“ wird gerade abgeschnitten. Anschließend wird die Datei „undo__trunc.log“ initialisiert, die die Abschneideaktion darstellt Der Datenbankdienst wird neu gestartet. Nach dem Neustart findet der Dienst diese Datei und führt sie weiter aus. Nachdem der Kürzungsvorgang abgeschlossen ist, wird die Rückgängig-Protokolldatei als für die Zuordnung verfügbar markiert.
wird verwendet, um die Häufigkeit von Lösch-Rollback-Segmenten zu steuern, der Standardwert ist 128. Angenommen, es ist auf n gesetzt, bedeutet dies, dass, wenn der Koordinationsthread der Innodb-Bereinigungsoperation Transaktionen 128 Mal bereinigt, eine Verlaufsbereinigung ausgelöst wird, um zu prüfen, ob der aktuelle Status des Rückgängig-Protokolltabellenbereichs eine Kürzung auslöst.
1.3 Speicherplatzverwaltung rückgängig machen
Wenn Sie unabhängige Tabellenbereiche einrichten müssen, müssen Sie beim Initialisieren der Datenbankinstanz die Anzahl der unabhängigen Tabellenbereiche angeben.
UNDO besteht intern aus mehreren Rollback-Segmenten, also insgesamt 128, die im ibdata-Systemtabellenbereich gespeichert sind Rollback-Segment, besteht intern aus 1024 Rückgängig-Segmenten.
Das Rollback-Segment wird wie folgt zugewiesen:
Slot 0, reserviert für den Systemtabellenbereich;
Slot 1-32, reserviert für den temporären Tabellenbereich, wird sie neu erstellt der temporäre Tabellenbereich;
slot33-127, wenn es einen unabhängigen Tabellenbereich gibt, ist er für den UNDO-unabhängigen Tabellenbereich reserviert;
Remove 32 aus dem Rollback-Segment Für temporäre Tabellentransaktionen vorgesehen. Die verbleibenden 128-32 = 96 Rollback-Segmente können 96 * 1024 gleichzeitige Transaktionsvorgänge ausführen. Beachten Sie, dass eine temporäre Tabellentransaktion vorhanden ist Ein weiterer Rückgängig-Segment-Slot befindet sich im Rückgängig-Segment-Slot im temporären Tabellenbereich, d. h. es werden 2 Rückgängig-Segment-Slots belegt. Wenn Folgendes im Fehlerprotokoll steht, bedeutet dies, dass zu viele gleichzeitige Transaktionen vorliegen und Sie überlegen müssen, ob Sie das Geschäft auslagern möchten. Cannot find a free slot for an undo log。
Das Rollback-Segment wird mithilfe der Polling-Planung zugewiesen, das Rückgängig-Segment im Rollback-Segment des Systemtabellenbereichs wird jedoch verwendet, wenn das Lookback-Segment verwendet wird Befindet sich der Wert im Abschneidevorgang, wird er nicht zugewiesen.
2 Redo
2.1 Was ist Redo? Wenn die Datenbank die Daten ändert, muss sie die Datenseite von der Festplatte in den Pufferpool lesen und sie dann im Pufferpool ändern Zu diesem Zeitpunkt stimmt die Datenseite im Pufferpool nicht mit dem Inhalt der Datenseite auf der Festplatte überein. Die Datenseite im Pufferpool wird als schmutzige Seite bezeichnet. Wenn zu diesem Zeitpunkt ein abnormaler DB-Dienstneustart auftritt, sind die Daten nicht konsistent im Speicher und ist nicht mit der Festplattendatei synchronisiert (beachten Sie, dass die Synchronisierung mit der Festplattendatei eine zufällige E/A ist), d. h., wenn sich zu diesem Zeitpunkt eine Datei im Puffer befindet Wenn der Pool geändert wird, wird der entsprechende Änderungsdatensatz in dieser Datei aufgezeichnet (beachten Sie, dass das Protokoll in sequentieller E/A aufgezeichnet wird). Wenn der DB-Dienst abstürzt und die Datenbank wiederhergestellt wird, kann der aufgezeichnete Inhalt dieser Datei erneut auf die Datei angewendet werden Datenträgerdatei gespeichert und die Daten bleiben konsistent.
Diese Datei ist das Redo-Log, mit dem die geänderten Daten der Reihe nach aufgezeichnet werden. Dies kann folgende Vorteile bringen:
Wenn die fehlerhafte Seite im Pufferpool nicht auf der Festplatte aktualisiert wurde, kommt es zu einem Absturz. Nach dem Starten des Dienstes können Sie die Datensätze finden, die in der Festplattendatei aktualisiert werden müssen das Redo-Log;
-
Die Daten im Pufferpool werden direkt in die Festplattendatei geschrieben, was eine zufällige E/A ist, die weniger effizient ist, während das Aufzeichnen der Daten im Pufferpool im Redo-Log eine sequentielle E/A ist. Dies kann die Geschwindigkeit der Transaktionsübermittlung verbessern.
-
Hypothese Ändern Sie die Zeilendaten mit der ID = 2 in der TBA-Tabelle und ändern Sie Name = „B“ in Name = „B2“. Dann wird das Redo-Protokoll zum Speichern verwendet Datensatz von Name='B2'. Wenn diese Änderung in die Festplattendatei geschrieben wird. Wenn eine Ausnahme auftritt, können Sie das Redo-Protokoll verwenden, um Redo-Vorgänge zu implementieren und die Haltbarkeit der Transaktion sicherzustellen.
Id
Name |
| 1
A |
| 2
B |
| 3
C |
| 4
| D |
|
Achten Sie auf den Unterschied zwischen Redo-Log und Binär-Log. Redo-Log wird von der Speicher-Engine-Schicht generiert, während Binär-Log von der Datenbank-Schicht generiert wird. Angenommen, eine große Transaktion fügt 100.000 Datensätze in tba ein. Während dieses Vorgangs werden Datensätze kontinuierlich nacheinander im Redo-Protokoll aufgezeichnet, das Binärprotokoll wird jedoch nicht aufgezeichnet. Erst wenn die Transaktion festgeschrieben wird, wird sie in die Binärprotokolldatei geschrieben einmal. Für Binärprotokolle stehen drei verschiedene Aufzeichnungsformate zur Verfügung, nämlich Zeilen-, Anweisungs- und gemischte Protokolle, und die Aufzeichnungsformen sind unterschiedlich.
2.2redoParameter
redo Die Anzahl der Protokolldateien, Benennungsmethode wie: ib_logfile0, iblogfile1... ib logfile. Der Standardwert ist 2, der Höchstwert ist 100.
Größe der Dateieinstellung, der Standardwert beträgt 48 MB, der Maximalwert beträgt 512 GB. Beachten Sie, dass sich der Maximalwert auf die Summe der gesamten Redo-Log-Seriendateien bezieht, d. h. (innodb_log_files_in_group * innodb_log_file_size) darf nicht größer als der Maximalwert von 512G sein.
Dateispeicherpfad
Redo-Log-Cache-Bereich, Standard 8M, kann eingestellt werden bis 1-8M. Verzögern Sie das Schreiben des Transaktionsprotokolls auf die Festplatte, legen Sie das Redo-Protokoll in den Puffer und leeren Sie das Protokoll dann entsprechend der Einstellung des Parameters innodb_flush_log_at_trx_commit aus dem Puffer auf die Festplatte.
innodb_flush_log_at_trx_commit=1, jeder Commit schreibt das Redo-Log aus dem Redo-Log-Puffer in das System und fsynct es mit der Festplattendatei.
innodb_flush_log_at_trx_commit=2, jedes Mal, wenn eine Transaktion festgeschrieben wird, schreibt MySQL das Protokoll aus dem Redo-Log-Puffer in das System, jedoch nur in den Dateisystempuffer, und das System synchronisiert es intern mit der Festplattendatei. Wenn die Datenbankinstanz abstürzt, geht das Redo-Protokoll nicht verloren. Wenn der Server jedoch abstürzt, geht dieser Teil der Daten verloren, da der Dateisystempuffer keine Zeit hatte, sich mit der Festplattendatei zu synchronisieren.
innodb_flush_log_at_trx_commit = 0, während des Transaktionsprozesses befindet sich das Protokoll wie bei anderen Einstellungen immer im Redo-Log-Puffer. Wenn die Transaktion jedoch festgeschrieben wird, erfolgt kein Redo-Schreibvorgang, sondern der interne MySQL-Vorgang erfolgt einmal pro Sekunde. schreibt Daten aus dem Redo-Log-Puffer in das System. Bei einem Absturz gehen die Transaktionsänderungsvorgänge innerhalb einer Sekunde verloren.
2.3 Redo Space Management
Die Redo-Log-Datei ist nach ib_logfile[number] benannt. Wenn sie voll ist, geht sie zurück zur ersten Datei und überschreibt es. (Beim Redo-Checkpoint wird jedoch auch die Header-Checkpoint-Markierung der ersten Protokolldatei aktualisiert, sodass dies streng genommen nicht als sequentielles Schreiben gezählt wird.)
Tatsächlich besteht das Redo-Log aus zwei Teilen: dem Redo-Log-Puffer und der Redo-Log-Datei. Im Pufferpool werden Datenänderungen im Redo-Log-Puffer aufgezeichnet. Wenn Folgendes auftritt, wird das Redo-Log in die Redo-Log-Datei geschrieben:
3 um Transaktionen mit Rückgängigmachen und Wiederherstellen aufzuzeichnen
3.1 Rückgängig machen + Vereinfachter Prozess von Redo-Transaktionen
Angenommen, es gibt zwei Daten A und B mit den Werten 1 und 2. Der Operationsinhalt der Transaktion lautet: Ändern Sie 1 auf 3 und 2 auf 4. Dann die tatsächliche Der Datensatz lautet wie folgt (vereinfacht):
A. Transaktion beginnt.
B. Zeichnen Sie A=1 auf, um das Protokoll rückgängig zu machen.
C. Ändern Sie A=3.
D. Zeichnen Sie A=3 auf, um das Protokoll erneut zu erstellen.
E. Zeichnen Sie B=2 auf, um das Protokoll rückgängig zu machen.
I. Transaktionseinreichung
3.2 IO-Auswirkungen
Der Hauptzweck des Entwurfs von Undo + Redo besteht darin, die Eingabe- und Ausgabeleistung zu verbessern und die Verarbeitungskapazität der Datenbank zu erhöhen. Es ist ersichtlich, dass B D E G H alle neue Operationen sind, B D E G jedoch im Pufferbereich gepuffert ist. Um sicherzustellen, dass Redo Log eine bessere E / A-Leistung aufweist, verfügt das Redo Log-Design von InnoDB über die folgenden Funktionen:
B. Versuchen Sie sicherzustellen, dass Redo Log in einem kontinuierlichen Speicherplatz gespeichert wird. Daher wird der Speicherplatz der Protokolldatei beim ersten Systemstart vollständig zugewiesen. Um die Leistung zu verbessern, wird das Redo-Protokoll in einer sequentiellen IO-Methode aufgezeichnet und schrittweise abgeschlossen. B. Protokolle stapelweise schreiben. Das Protokoll wird nicht direkt in die Datei geschrieben, sondern zuerst in den Redo-Log-Puffer. Wenn das Protokoll auf die Festplatte geleert werden muss (z. B. bei der Übermittlung einer Transaktion), werden viele Protokolle zusammen auf die Festplatte geschrieben.
C. Gleichzeitig Transaktionen teilen sich den Redo-Log-Speicherplatz, ihre Redo-Logs werden abwechselnd entsprechend der Ausführungsreihenfolge der Anweisungen aufgezeichnet, um den vom Protokoll belegten Speicherplatz zu reduzieren. Der Datensatzinhalt im Redo-Log kann beispielsweise wie folgt aussehen:
Datensatz 1:
Datensatz 2:
Datensatz 3:
Datensatz 4:
Datensatz 5:
D. Wegen C, wenn eine Transaktion das Redo-Log in das schreibt disk werden die Protokolle anderer nicht festgeschriebener Transaktionen ebenfalls auf die Festplatte geschrieben.
E. Im Redo-Log werden nur sequentielle Anhängevorgänge ausgeführt. Wenn eine Transaktion zurückgesetzt werden muss, werden ihre Redo-Log-Datensätze nicht aus dem Redo-Log gelöscht.
3.3 Wiederherstellung
Wie bereits erwähnt, werden nicht festgeschriebene Transaktionen und zurückgesetzte Transaktionen auch im Redo-Protokoll aufgezeichnet, sodass diese Transaktionen während der Wiederherstellung speziell verarbeitet werden müssen. Es gibt zwei verschiedene Wiederherstellungsstrategien:
A. Bei der Wiederherstellung wiederholen Sie nur die festgeschriebenen Transaktionen.
Bei der Wiederherstellung müssen alle Transaktionen erneut ausgeführt werden, einschließlich nicht festgeschriebener und zurückgesetzter Transaktionen. Setzen Sie dann diese nicht festgeschriebenen Transaktionen über das Rückgängig-Protokoll zurück.
Die InnoDB-Speicher-Engine der MySQL-Datenbank verwendet Strategie B. Der Wiederherstellungsmechanismus in der InnoDB-Speicher-Engine weist mehrere Merkmale auf: A. Beim Wiederherstellen des Redo-Logs ist die Transaktionalität nicht wichtig. Während der Wiederherstellung gibt es kein BEGIN-, COMMIT- oder ROLLBACK-Verhalten. Es spielt keine Rolle, zu welcher Transaktion jedes Protokoll gehört. Obwohl transaktionsbezogene Inhalte wie die Transaktions-ID im Redo-Log aufgezeichnet werden, werden diese Inhalte nur als Teil der zu verarbeitenden Daten betrachtet.
B. Bei Verwendung von Strategie B muss das Undo-Log beibehalten werden und das entsprechende Undo-Log muss auf die Festplatte geschrieben werden, bevor das Redo-Log geschrieben wird. Diese Beziehung zwischen Undo- und Redo-Log erschwert die Persistenz. Um die Komplexität zu reduzieren, behandelt InnoDB das Undo-Log als Daten, sodass der Vorgang der Aufzeichnung des Undo-Logs auch im Redo-Log aufgezeichnet wird. Durch das Zwischenspeichern von Undo-Logs im Speicher entfällt die Notwendigkeit, Redo-Logs vor dem Schreiben auf die Festplatte zu schreiben.
Das Redo-Protokoll, das den Undo-Log-Vorgang enthält, sieht folgendermaßen aus: Datensatz 1: Einfügung des Protokolls rückgängig machen > Datensatz 2:
Datensatz 3: Protokolleinfügung rückgängig machen
>
Datensatz 4:
Datensatz 5: Protokolleinfügung rückgängig machen
> Datensatz 6: C. Zu diesem Zeitpunkt gibt es immer noch ein Problem, das nicht geklärt wurde. Da Redo nicht transaktional ist, würde es dann nicht die zurückgesetzte Transaktion erneut ausführen?
Es ist wahr. Gleichzeitig zeichnet Innodb auch die Vorgänge während des Transaktions-Rollbacks im Redo-Log auf. Wenn ein Rollback-Vorgang durchgeführt wird, werden die Änderungen an den Daten im Redo-Log aufgezeichnet, da der Rollback-Vorgang im Wesentlichen auch die Daten ändert. Das Redo-Protokoll einer zurückgesetzten Transaktion sieht folgendermaßen aus:
Datensatz 1: > Datensatz 2: insert A&hellip ;>> > Datensatz 6: delete C…> Datensatz 7: insert C
> Datensatz 8: update B zu altbewährtem Sex.
