Beherrschen Sie die MySQL-Prinzipien und das Architekturdesign der InnoDB-Speicher-Engine vollständig

Dieser Artikel vermittelt Ihnen relevantes Wissen über das Design der InnoDB-Speicher-Engine-Architektur im MySQL-Prinzip. Ich hoffe, dass er Ihnen hilfreich sein wird.

InnoDB-Komponentenstruktur:

1. Pufferpool: Pufferpool, Festplattendaten zwischenspeichern

2. Redo-Log-Puffer: Vorgänge im Pufferpool aufzeichnen, gemäß Richtlinie auf die Festplatte schreiben, um Ausfallzeiten zu vermeiden, aber die Transaktion hat Datenverlust begangen

3. Rückgängig-Protokoll: Wenn die Daten im Pufferpool geändert werden, kann vor der Übermittlung der Transaktion ein Rollback durchgeführt werden. Der alte Wert wird in die Rückgängig-Protokolldatei geschrieben, um das Rollback zu erleichtern. Die Daten im Pufferpool sind inkonsistent mit der Festplatte.

1. Pufferpool

Angenommen, es gibt eine Aktualisierungsanweisung:

update users set name = 'lisi' where id = 1

muss in der Datenbank aktualisiert werden. Welche Vorgänge führt InnoDB aus?

Zuerst prüft InnoDB, ob die Daten mit der ID = 1 im Pufferpool vorhanden sind. Wenn sie nicht vorhanden sind, werden sie von der Festplatte in den Pufferpool geladen und fügen außerdem eine exklusive Sperre hinzu Ändern Sie auch diese Datenzeile, um mehrere SQLs zu verhindern.

2. Protokolldatei rückgängig machen

Angenommen, der ursprüngliche Wert dieses Datennamens ist name = 'zhangsan', dann brauchen wir Um den alten Wert in name ='zhangsan' und id=1 zu ändern, werden diese in die Rückgängig-Protokolldatei geschrieben.

Für Schüler, die mit Datenbanken vertraut sind, verstehen sie alle das Konzept von Transaktionen. Vor der Übermittlung der Transaktion können alle Vorgänge zurückgesetzt werden, dh name = 'lisi' kann auf name = 'zhangsan' zurückgesetzt werden. Es wird also aktualisiert. Der vorherige Wert wird in die Rückgängig-Protokolldatei geschrieben.

3. Pufferpooldaten aktualisieren

Nachdem die Rückgängig-Protokolldatei geschrieben wurde, beginnen Sie mit der Aktualisierung dieser Daten im Speicher. Aktualisieren Sie name = 'zhangsan' mit id = 1 auf name = 'lisi'. Zu diesem Zeitpunkt wurden die Daten im Speicher aktualisiert, aber die Daten auf der Festplatte haben sich nicht geändert. Zu diesem Zeitpunkt werden inkonsistente fehlerhafte Daten angezeigt.

Zu diesem Zeitpunkt haben Sie möglicherweise eine Frage: Wenn die Transaktion übermittelt wird, der MySQL-Dienst jedoch ausgefallen ist und die Daten im Speicher nicht auf die Festplatte geschrieben wurden, führt dies zu Datenverlust und Inkonsistenz in den SQL-Ausführungsdaten?

4. Redo-Log-Puffer

In der InnoDB-Struktur gibt es einen Redo-Log-Puffer zum Speichern von Redo-Logs. Ändern Sie beispielsweise id=1, name='zhangsan' in name= 'lisi' Es ist ein Protokoll.

Aber zu diesem Zeitpunkt ist der Redo-Log-Puffer immer noch nur im Speicher vorhanden und eine Datenwiederherstellung nach einem MySQL-Ausfall ist nicht möglich.

5. Wird es Auswirkungen haben, wenn die Transaktion nicht übermittelt wird?

Tatsächlich hat es keine Auswirkungen auf die Transaktion, was bedeutet, dass die Ausführung nicht erfolgreich ist. Selbst wenn MySQL abstürzt oder ausfällt, bleiben die geänderten Daten im Pufferpool und im Redo-Log-Puffer erhalten verloren, und die Konsistenz der Daten wird dadurch nicht beeinträchtigt. Wenn die Transaktionsfestschreibung fehlschlägt, werden die Daten in der Datenbank nicht geändert.

6. Transaktion einreichen, Redo-Log-Konfigurationsstrategie

Beim Absenden der Transaktion schreibt das Redo-Tagebuch das Redo-Log entsprechend der Strategie aus dem Redo-Log-Puffer auf die Festplatte. Die Richtlinie wird über innoDB_flush_log_at_trx_commit konfiguriert.

1. Der Parameter von innoDB_flush_log_at_trx_commit ist 0. Auch nach dem Festschreiben der Transaktion wird das Redo-Protokoll nicht auf die Festplatte geschrieben. Nach einem MySQL-Absturz gehen die Daten im Speicher verloren.

1. Der Parameter von innoDB_flush_log_at_trx_commit ist 1. Nach der Übermittlung der Transaktion wird das Redo-Protokoll aus dem Speicher auf die Festplatte geleert. Solange die Transaktion erfolgreich übermittelt wird, ist das Redo-Protokoll definitiv vorhanden auf der Festplatte.

Auch wenn die Pufferpooldaten zu diesem Zeitpunkt nicht auf die Festplatte geleert werden, können Sie anhand des Redo-Protokolls erkennen, welche Daten geändert wurden. Nach dem Herunterfahren und Neustarten von MySQL können die geänderten Daten angezeigt werden aus dem Redo-Log wiederhergestellt werden.

1. Der Parameter von innoDB_flush_log_at_trx_commit ist 2. Nach der Übermittlung der Transaktion verbleibt das Redo-Log nur im Betriebssystem-Cache und wurde nicht auf die Festplatte geleert, falls der Dienst zu diesem Zeitpunkt ausgefallen ist. Dann gehen auch die Daten im Betriebssystem-Cache verloren. Auch wenn die Transaktion erfolgreich übermittelt wird, gehen Daten verloren.

Nachdem ich diese gelesen habe, glaube ich, dass Parameter 1 die beste Strategie ist, um die Datensicherheit zu gewährleisten.

7. Die endgültige Übermittlung der Transaktion, binlog

binlog, ist eigentlich eine Protokolldatei, die zu MySQL Server gehört, und wird hier erwähnt, weil sie eng mit dem Redo-Protokoll zusammenhängt.

1) Der Unterschied zwischen Biglog und Redo-Log

• Redo-Log: Es zeichnet ein Redo-Log mit teilweise physischer Natur auf, z. B. „Welcher Datensatz auf welcher Datenseite, welche Änderungen wurden vorgenommen“

• Binlog: Ein Log, das logischer ist, wie zum Beispiel: „Die Datenzeile mit der ID=10 in der Benutzertabelle wurde aktualisiert. Wie lautet der Wert nach der Aktualisierung?“

2) Schreiben Sie das Binlog unter gleichzeitig beim Senden der Transaktion

Während der Ausführung von Aktualisierungen interagiert innoDB ständig mit dem Executor, einschließlich des Ladens von Daten in den Pufferpool, des Schreibens von Undo-Log-Dateien, des Aktualisierens von Speicherdaten, des Schreibens von Redo-Logs und des Leerens auf die Festplatte usw. Das Schreiben in Binlog wird ebenfalls vom Executor durchgeführt.

Die Schritte 1, 2, 3 und 4 sind das, was Sie tun, wenn Sie die Aktualisierungsanweisung ausführen, und die Schritte 5 und 6 sind das, was Sie tun, wenn Sie die Transaktion festschreiben.

3) Analyse der Binlog-Protokoll-Flushing-Strategie

sync_binlog-Parameter steuert die Binlog-Flushing-Strategie

1. sync_ Der Standardwert von binlog ist 0. Nach dem Absenden der Transaktion wird das Binlog-Protokoll im Betriebssystem-Cache gespeichert verursacht Probleme, nachdem MySQL ausgefallen ist. Der Wert von „sync_binlog“ ist 1. Nach der Übermittlung der Transaktion wird das Binlog-Protokoll direkt auf die Festplatte geschrieben.

2. 4) Vollständige Transaktionsübermittlung basierend auf Binlog und Redo-Log

Nachdem das Binlog auf die Festplatte geschrieben wurde, werden der Speicherort und der Dateiname der Binlog-Protokolldatei gleichzeitig in die Redo-Log-Datei geschrieben Schreiben Sie in die Redo-Log-Datei eine Festschreibungsmarkierung.

5) Welche Bedeutung hat das Commit-Tag? Die

commit-Markierung bedeutet, dass das Redo-Log und die Binlog-Protokolle konsistent bleiben. Wenn die Transaktionsübermittlung in Schritt 5 oder Schritt 6 beginnt, MySQL ausgefallen ist und im Redo-Log keine Commit-Markierung vorhanden ist, gilt die Transaktionsübermittlung als fehlgeschlagen.

bedeutet, dass die Festschreibungsmarkierung bedeutet, dass die Transaktion schließlich erfolgreich übermittelt wurde.

8. Pufferpool Verschmutzte Daten werden auf die Festplatte geleert

Verschmutzte Daten werden zufällig vom Hintergrund-E/A-Thread auf die Festplatte geleert.

Zu diesem Zeitpunkt habe ich darüber nachgedacht, was ich tun soll, wenn MySQL ausfällt, bevor ich die Festplatte flashe? Zu diesem Zeitpunkt wurde die Transaktion erfolgreich übermittelt und es gibt eine Commit-Markierung im Redo-Log. Selbst wenn es nicht verfügbar ist, werden die Daten nach dem Neustart gemäß der Redo-Log-Datei im Speicher aktualisiert und warten auf die E/A Thread zum Spülen der Festplatte.

9. Zusammenfassung

Nachdem wir die Analyse über die Update-Anweisung ausgeführt haben, haben wir erfahren, dass die InnoDB-Speicher-Engine Pufferpool-Pufferpools, Redo-Log-Pufferpuffer und andere Cache-Daten, Undo-, Reod-Log- und andere Protokolldateien enthält sowie die MySQL-Server-Protokolldatei. Beim Ausführen der Update-Anweisung werden der Pufferpool, das Schreiben der Rückgängig-Protokolldatei, das Schreiben des Redo-Protokollpuffers und andere Vorgänge geändert. Wenn die Transaktion übermittelt wird, wird das Redo-Protokoll geleert, das Binlog wird geleert und die Binlog-Datei wird geleert Name und Speicherort werden geschrieben, Geben Sie die Festschreibungsmarkierung ein und warten Sie schließlich, bis der E / A-Thread die schmutzigen Daten zufällig im Pufferpool geleert hat.

Empfohlenes Lernen:

MySQL-Video-Tutorial

Das obige ist der detaillierte Inhalt vonBeherrschen Sie die MySQL-Prinzipien und das Architekturdesign der InnoDB-Speicher-Engine vollständig. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!