Verstehen Sie die Prinzipien der MySQL-Persistenz und des Rollbacks in einem Artikel

Redo-Protokoll

Die Transaktionsunterstützung ist eines der wichtigen Merkmale, das Datenbanken von Dateisystemen unterscheidet. Transaktionen haben vier Hauptmerkmale:

• Atomarität: Alle Operationen werden entweder ausgeführt oder nicht ausgeführt und sind unteilbar.
• Konsistenz: Das Ergebnis einer Datenbankänderung von einem Zustand in einen anderen ist letztendlich konsistent. Wenn A beispielsweise 500 an B überträgt, hat A am Ende 500 weniger und B 500 mehr, aber der Wert von A+B ändert sich nie.
• Isolierung: Transaktionen sind voneinander isoliert und stören sich nicht gegenseitig.
• Persistenz: Sobald eine Transaktion festgeschrieben ist, sind die an den Daten vorgenommenen Änderungen dauerhaft.
  

In diesem Artikel geht es hauptsächlich um Erkenntnisse zum Thema Persistenz.

Wenn wir einen Datensatz in einer Transaktion aktualisieren, zum Beispiel:

Benutzer aktualisieren, Alter auf 11 setzen, wobei Benutzer-ID = 1 ist;

Der Ablauf sieht ungefähr so ​​aus:

• Stellen Sie zunächst fest, ob sich die Seite, auf der sich die user_id-Daten befinden, im Speicher befindet. Wenn nicht, lesen Sie sie zuerst aus der Datenbank und laden Sie sie dann in den Speicher
• Ändern Sie das Alter im Speicher auf 11
• Redo-Log schreiben, Redo-Log befindet sich im Vorbereitungszustand
• Schreiben ins Binärprotokoll
• Führen Sie ein Commit für die Transaktion durch. Das Redo-Log wechselt in den Commit-Status.

Hier gibt es mehrere wichtige Punkte: Was ist ein Redo-Protokoll? Warum brauchen wir Redo-Protokolle? Was ist das Redo-Protokoll im Vorbereitungszustand? Können wir nur zwischen Redo-Log und Binlog wählen? Lassen Sie uns mit dieser Reihe von Fragen das Redo-Log enthüllen.

Warum müssen wir zuerst die Speicherdaten aktualisieren, anstatt die Festplattendaten direkt zu aktualisieren?

Warum aktualisieren wir die entsprechenden Festplattendaten nicht bei jeder Datenaktualisierung direkt? Zunächst einmal wissen wir, dass die Festplatten-E/A langsam und die Speicher-E/A schnell sind und ihre Geschwindigkeiten nicht in der gleichen Größenordnung liegen. Für die langsame Festplatten-E/A erscheinen also Indizes. Durch Indizes können wir unsere Daten auf der Festplatte immer noch sehr schnell finden, selbst wenn es Hunderte Millionen Daten sind. Dies ist die Rolle von Indizes. Der Index muss jedoch auch gepflegt werden und ist nicht statisch. Wenn wir neue Daten A einfügen, müssen wir Daten B verschieben, um Platz für A zu schaffen, da diese Daten nach den vorhandenen Daten B eingefügt werden müssen, was einen gewissen Aufwand mit sich bringt. Schlimmer noch: Wenn die Seite, auf der die Daten eingefügt werden sollen, voll ist, muss eine neue Seite angefordert und einige Daten dorthin verschoben werden. Dies nennt man Seitenaufteilung, was noch teurer ist. Wenn unsere SQL-Änderung darin besteht, die Daten auf der Festplatte direkt zu ändern, und das obige Problem auftritt, ist die Effizienz zu diesem Zeitpunkt sehr gering und führt in schwerwiegenden Fällen zu einer Zeitüberschreitung. Aus diesem Grund lädt der obige Aktualisierungsprozess zuerst die entsprechende Datenseite in den Speicher und aktualisiert dann die Daten im Speicher. Bei MySQL müssen alle Änderungen zuerst die Daten im Pufferpool aktualisieren. Anschließend werden die schmutzigen Seiten im Pufferpool in einer bestimmten Häufigkeit auf die Festplatte übertragen ( CheckPoint- Mechanismus). Der Pufferpool wird verwendet, um die Lücke zwischen CPU und Festplatte zu optimieren, damit die Gesamtleistung nicht zu schnell abfällt.

Warum brauchen wir Redo-Protokolle?

Der Pufferpool kann uns helfen, die Lücke zwischen der CPU und der Festplatte zu schließen, und der Prüfpunktmechanismus kann sicherstellen, dass die Daten schließlich auf die Festplatte geschrieben werden. Der Prüfpunkt wird jedoch nicht bei jeder Änderung ausgelöst, sondern in Intervallen vom Master-Thread verarbeitet. Daher besteht der schlimmste Fall darin, dass die Datenbank direkt nach dem Schreiben in den Pufferpool abstürzt und diese Daten verloren gehen und nicht wiederhergestellt werden können. In diesem Fall ist D in ACID nicht erfüllt. Um das Persistenzproblem in diesem Fall zu lösen, verwendet die Transaktion der InnoDB-Engine die WAL-Technologie (Write-Ahead Logging). Die Idee dieser Technologie besteht darin, zuerst das Protokoll zu schreiben und es dann auf die Festplatte zu schreiben. Erst wenn das Protokoll erfolgreich geschrieben wurde, gilt die Transaktion als erfolgreich festgeschrieben. Das Protokoll hier ist das Redo-Protokoll. Wenn ein Absturz auftritt und die Daten nicht auf die Festplatte geschrieben werden, können sie über das Redo-Log wiederhergestellt werden, um D in ACID sicherzustellen. Dies ist die Rolle des Redo-Logs.

Wie wird das Redo-Log implementiert?

Das Redo-Log wird nicht direkt auf die Festplatte geschrieben. Das Redo-Log hat auch einen Puffer, den sogenannten Redo-Log-Puffer. Die InnoDB-Engine schreibt beim Schreiben des Redo-Logs zuerst in den Redo-Log-Puffer und leert ihn dann in einer bestimmten Häufigkeit in das echte Redo-Log. Der Redo-Log-Puffer muss im Allgemeinen nicht sehr groß sein. Er ist nur ein temporärer Container. Der Master-Thread leert den Redo-Log-Puffer jede Sekunde in die Redo-Log-Datei. Daher müssen wir nur sicherstellen, dass der Redo-Log-Puffer die durch die Transaktion geänderte Datenmenge innerhalb von 1 Sekunde speichern kann. Am Beispiel von mysql5.7.23 beträgt der Standardwert 16 M.

mysql> Variablen wie „%innodb_log_buffer_size%“ anzeigen;
+------------------------+----------+
| Variablenname | Wert |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+

Für die meisten Anwendungen ist ein Puffer mit 16 MB ausreichend. Es gibt mehrere Strategien, um den Puffer mit dem Redo-Log zu synchronisieren:

• Der Master-Thread leert den Puffer jede Sekunde in das Redo-Log
• Wenn jede Transaktion festgeschrieben ist, wird der Puffer in das Redo-Protokoll geleert.
• Wenn der verbleibende Speicherplatz im Puffer weniger als 1/2 beträgt, wird er in das Redo-Protokoll geschrieben.

Es ist zu beachten, dass der Vorgang des Leerens des Redo-Log-Puffers in das Redo-Log nicht wirklich das Leeren auf die Festplatte, sondern nur das Leeren in den OS-Cache ist. Dies ist eine Optimierung moderner Betriebssysteme, um die Effizienz des Dateischreibens zu verbessern. Das tatsächliche Schreiben wird vom System selbst entschieden (z. B. wenn der OS-Cache groß genug ist). Dann gibt es ein Problem für InnoDB: Wenn fsync dem System überlassen wird und das System abstürzt, gehen auch die Daten verloren (obwohl die Wahrscheinlichkeit, dass das gesamte System abstürzt, immer noch relativ gering ist). Als Reaktion auf diese Situation bietet InnoDB die Strategie innodb_flush_log_at_trx_commit an, sodass Benutzer entscheiden können, welche sie verwenden möchten.

mysql> Variablen wie „innodb_flush_log_at_trx_commit“ anzeigen;
+--------------------------------+----------+
| Variablenname | Wert |
+--------------------------------+----------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+----------+

• 0: Nachdem die Transaktion festgeschrieben wurde, wird kein Fsync ausgeführt, aber der Master führt jede Sekunde ein Fsync des Redo-Protokolls durch.
• 1: Standardwert, fsync wird synchron ausgeführt, wenn eine Transaktion festgeschrieben wird
• 2: Nach dem Schreiben in den OS-Cache das Betriebssystem entscheiden lassen, wann fsync

Von den drei Einbürstenstrategien:

2 ist definitiv die effizienteste, aber wenn das Betriebssystem abstürzt, gehen die Daten im OS-Cache verloren und in diesem Fall ist die ACID D

Wenn der Wert 0 ist, handelt es sich um einen Kompromiss. Die IO-Effizienz ist theoretisch höher als 1 und niedriger als 2. Die Datensicherheit ist theoretisch niedriger als 1 und höher als 2. Diese Strategie birgt auch das Risiko eines Datenverlusts und kann D nicht garantieren.

1 ist der Standardwert, der garantiert, dass D und Daten niemals verloren gehen, aber die Effizienz ist am schlechtesten. Ich persönlich empfehle, den Standardwert zu verwenden. Obwohl die Wahrscheinlichkeit eines Betriebssystemabsturzes theoretisch geringer ist als die Wahrscheinlichkeit eines Datenbankabsturzes, sollte die Datensicherheit relativ wichtiger sein, da Transaktionen verwendet werden.

Das Redo-Log ist eine physische Änderung der Seite. Die x-te Position der Seite x wird in xx geändert , zum Beispiel:

Seite (2,4), Offset 64, Wert 2

In der InnoDB-Engine werden Redo-Logs in Einheiten von 512 Byte gespeichert. Jede Speichereinheit wird als Redo-Log-Block bezeichnet. Wenn die Menge der auf einer Seite gespeicherten Logs größer als 512 Byte ist, muss sie zur Speicherung logisch in mehrere Blöcke aufgeteilt werden.

Ein Redo-Log-Block besteht aus einem Log-Header, einem Log-Body und einem Log-Tail. Der Protokollkopf umfasst 12 Bytes und das Protokollende 8 Bytes. In einem Block können also tatsächlich 512-12-8=492 Bytes Daten gespeichert werden.

Unser Redo-Log besteht aus mehreren Redo-Log-Blöcken.

Die Standardgröße jedes Redo-Protokolls beträgt 48 MB:

mysql> Variablen wie „innodb_log_file_size“ anzeigen;
+----------------------+----------+
| Variablenname | Wert |
+----------------------+----------+
| innodb_log_dateigröße | 50331648 |
+----------------------+----------+

Standardmäßig verwendet InnoDB zwei Redo-Protokolle, um eine Protokollgruppe zu bilden, und diese Protokollgruppe ist diejenige, die die tatsächliche Arbeit erledigt.

mysql> Variablen wie „innodb_log_files_in_group“ anzeigen;
+-----------------------------------------+----------+
| Variablenname | Wert |
+-----------------------------------------+----------+
| innodb_log_files_in_group | 2 |
+-----------------------------------------+----------+
#ib_logfile0
#ib_logfile1

Wenn ib_logfile0 fertig ist, wird ib_logfile1 geschrieben. Wenn ib_logfile1 fertig ist, wird ib_logfile0 erneut geschrieben ... und der Zyklus wird fortgesetzt.

Warum muss ein Block 512 Byte groß sein?

Dies hängt mit den Sektoren der Festplatte zusammen. Der Standardsektor einer mechanischen Festplatte beträgt 512 Byte. Wenn die Daten, die Sie schreiben möchten, größer als 512 Byte sind, müssen Sie mehr als einen Sektor zum Schreiben haben. Zu diesem Zeitpunkt muss die Festplatte rotieren, um den nächsten Sektor zu finden. Angenommen, Sie müssen jetzt zwei Sektoren A und B schreiben. Wenn Sektor A erfolgreich geschrieben wird und Sektor B nicht geschrieben werden kann, erfolgt ein nichtatomarer Schreibvorgang. Wenn Sie nur 512 Byte schreiben, die gleiche Größe wie der Sektor, ist jeder Schreibvorgang atomar.

Warum zweistufige Einreichung?

Aus dem Obigen wissen wir, dass bei der Transaktionsübermittlung zuerst das Redo-Protokoll geschrieben (Vorbereitung), dann das Binärprotokoll geschrieben und schließlich ein Commit durchgeführt werden muss (Commit). Warum gibt es hier eine Vorbereitungsaktion? Kann ich nicht einfach das Redo-Protokoll committen? Angenommen, das Redo-Protokoll wird direkt übermittelt und beim Schreiben des Binlogs tritt ein Absturz auf. Dann verfügt das Binlog nicht über die entsprechenden Daten. Dann verfügen alle Slaves, die sich zum Wiederherstellen von Daten auf das Binlog verlassen, nicht über die entsprechenden Daten, was zu Inkonsistenzen zwischen Master und Slave führt. Daher ist eine zweiphasige (2pc) Übermittlung erforderlich, um die Konsistenz von Redo-Log und Binlog sicherzustellen. Die spezifischen Schritte sind wie folgt: Das Redo-Protokoll im Vorbereitungszustand zeichnet die XID von 2PC auf, und das Binärprotokoll zeichnet nach dem Schreiben auch die XID von 2PC auf, und die Commit-Markierung wird im Redo-Protokoll markiert.

Ist es möglich, dass ich nur eines vom Redo-Protokoll und vom Binärprotokoll benötige?

Kippen. Die Größe des Redo-Logs selbst ist festgelegt. Wenn es voll ist, wird es von vorne beginnen und die alten Daten überschreiben. Da das Redo-Log nicht alle Daten speichern kann, ist es im Master-Slave-Modus nicht möglich, Daten über das Redo-Log mit der Slave-Bibliothek zu synchronisieren. Dann wird Binlog unbedingt benötigt. Binlog wird von der Serverschicht von MySQL generiert und hat nichts mit der Speicher-Engine zu tun. Binglog wird auch Archivprotokoll genannt. Wenn eine Binlog-Datei voll ist, wird sie in eine neue Binlog-Datei geschrieben. Brauchen wir also nur Binlog? Ist es möglich, kein Redo-Protokoll zu benötigen? Natürlich nicht. Die Rolle des Redo-Logs besteht darin, Absturzsicherheit zu gewährleisten. Zunächst wird bei einer Datenänderung die Datenseite im Pufferpool geändert. Zu diesem Zeitpunkt werden die geänderten Daten nicht tatsächlich auf die Festplatte geschrieben. Dies liegt hauptsächlich daran, dass die diskrete Lese- und Schreibleistung der Festplatte gering ist. Die Arbeit des tatsächlichen Schreibens von Daten auf die Festplatte wird regelmäßig vom Master-Thread übernommen. Der Vorteil besteht darin, dass der Master mehrere Änderungen gleichzeitig auf die Festplatte schreiben kann. Dann gibt es ein Problem. Nachdem die Transaktion festgeschrieben wurde, befinden sich die Daten auf der schmutzigen Seite des Puffers und wurden nicht rechtzeitig auf die Festplatte geleert. Zu diesem Zeitpunkt stürzt die Datenbank ab. Dann können die festgeschriebenen Daten auch nach der Wiederherstellung der Datenbank nicht wiederhergestellt werden und sie können das D in ACID nicht erfüllen. Dann gibt es das Redo-Protokoll. Aus prozesstechnischer Sicht muss das Senden einer Transaktion das erfolgreiche Schreiben des Redo-Protokolls sicherstellen. Nur wenn das Redo-Protokoll erfolgreich geschrieben wurde, kann die Transaktion als erfolgreich gesendet betrachtet werden. In den meisten Fällen wird das Redo-Protokoll sequenziell auf die Festplatte geschrieben, sodass seine Effizienz viel höher ist. Wenn nach dem Commit ein Absturz auftritt, können wir die Daten über das Redo-Log wiederherstellen. Deshalb ist ein Redo-Log erforderlich. Für die Übermittlung der Transaktion ist jedoch auch das erfolgreiche Schreiben des Binärprotokolls erforderlich. Warum können die Daten, die nicht auf die Festplatte geschrieben wurden, nicht über das Binärprotokoll wiederhergestellt werden? Dies liegt daran, dass Binlog nicht weiß, welche Daten auf die Festplatte geschrieben wurden und daher nicht weiß, welche Daten wiederhergestellt werden müssen. Beim Redo-Log werden die Daten im entsprechenden Redo-Log gelöscht, nachdem die Daten auf die Festplatte geschrieben wurden. Daher müssen Sie nach dem Neustart der Datenbank nur die verbleibenden Daten im Redo-Log wiederherstellen.

Wie kann ich mich nach einem Absturz erholen?

Durch das zweistufige Commit wissen wir, dass das Redo-Log und das Binlog in jeder Phase mit „Prepare“ oder „Commit“ gekennzeichnet werden und die Transaktions-XID ebenfalls aufgezeichnet wird. Mit diesen Daten werden beim Neustart der Datenbank zunächst alle Transaktionen im Redo-Log überprüft. Wenn sich die Transaktion im Redo-Log im Commit-Status befindet, bedeutet dies, dass nach dem Commit ein Absturz aufgetreten ist. Stellen Sie zu diesem Zeitpunkt einfach die Daten im Redo-Log wieder her. Wenn sich das Redo-Log im Vorbereitungsstatus befindet, bedeutet dies, dass vor dem Commit ein Absturz aufgetreten ist. Zu diesem Zeitpunkt bestimmt der Status des Binlogs den Status der aktuellen Transaktion. Wenn das Binlog eine entsprechende XID enthält, bedeutet dies, dass das Binlog erfolgreich geschrieben wurde, aber nicht rechtzeitig festgeschrieben wurde. Führen Sie zu diesem Zeitpunkt einfach das Commit erneut aus. Wenn die entsprechende XID nicht im Binlog gefunden werden kann, bedeutet dies, dass das Binlog abgestürzt ist, bevor es erfolgreich geschrieben wurde. Daher sollte zu diesem Zeitpunkt ein Rollback ausgeführt werden.

Undo-Protokoll

Das Redo-Log garantiert die Transaktionspersistenz und das Undo-Log garantiert die Transaktionsatomarität. Die Voroperation zum Aktualisieren von Daten in einer Transaktion besteht eigentlich darin, diese zunächst in ein Rückgängig-Protokoll zu schreiben. Der Ablauf sieht also ungefähr wie folgt aus:

Unter welchen Umständen wird ein Undo-Protokoll erstellt?

Die Funktion des Undo-Protokolls ist MVCC (Multi-Version Control) und Rollback. Hier sprechen wir hauptsächlich über Rollback. Wenn wir bestimmte Daten in einer Transaktion einfügen, aktualisieren oder löschen, wird ein entsprechendes Undo-Protokoll generiert. Wenn wir ein Rollback durchführen, können wir über das Undo-Protokoll zum Anfang der Transaktion zurückkehren. Es ist zu beachten, dass beim Rollback die physische Seite nicht geändert wird, sondern die Logik in ihren ursprünglichen Zustand zurückversetzt wird. Beispielsweise werden Daten A in einer Transaktion in B geändert, aber eine andere Transaktion hat sie bereits in C geändert. Wenn beim Rollback die Datenseite direkt geändert wird und die Daten in A geändert werden, wird C überschrieben.

Für die InnoDB-Engine verfügt jeder Zeilendatensatz zusätzlich zu den Daten des Datensatzes selbst über mehrere versteckte Spalten:

• DB_ROW_ID : Wenn für die Tabelle kein expliziter Primärschlüssel und kein eindeutiger Index in der Tabelle definiert ist, fügt InnoDB der Tabelle automatisch eine versteckte Spalte „row_id“ als Primärschlüssel hinzu.
• DB_TRX_ID : Jeder Transaktion wird eine Transaktions-ID zugewiesen. Bei einer Datensatzänderung wird die Transaktions-ID dieser Transaktion in trx_id geschrieben.
• DB_ROLL_PTR : Rollback-Zeiger, im Wesentlichen ein Zeiger auf das Undo-Protokoll.

Wenn wir ein INSERT durchführen:

beginnen;
INSERT INTO Benutzer (Name) VALUES ("Tom")

Für alle eingefügten Daten wird ein Rückgängig-Protokoll für das Einfügen generiert und der Rollback-Zeiger der Daten zeigt darauf. Das Rückgängig-Protokoll zeichnet die Sequenznummer des Rückgängig-Protokolls, die in den Primärschlüssel eingefügten Spalten und Werte usw. auf, sodass Sie beim Zurücksetzen die entsprechenden Daten direkt über den Primärschlüssel löschen können.

Bei Aktualisierungsvorgängen wird ein Aktualisierungs-Rückgängig-Protokoll erstellt und in solche unterteilt, die den Primärschlüssel aktualisieren, und solche, die den Primärschlüssel nicht aktualisieren. Angenommen, Sie führen jetzt den folgenden Befehl aus:

UPDATE Benutzer SET Name="Sun" WHERE id=1; 

Zu diesem Zeitpunkt wird der alte Datensatz in das neue Undo-Protokoll geschrieben, und der Rollback-Zeiger zeigt auf das neue Undo-Protokoll, dessen Undo-Nummer 1 ist, und das neue Undo-Protokoll zeigt auf das alte Undo-Protokoll (Undo-Nummer = 0).

Angenommen, Sie führen jetzt Folgendes aus:

UPDATE Benutzer SET ID=2 WHERE ID=1; 

Für den Vorgang zum Aktualisieren des Primärschlüssels wird zuerst das Löschkennzeichen der Originaldaten aktiviert. Zu diesem Zeitpunkt werden die Daten nicht wirklich gelöscht. Die tatsächliche Löschung wird vom Bereinigungsthread beurteilt, und dann werden dahinter neue Daten eingefügt. Die neuen Daten generieren auch ein Undo-Protokoll, und die Sequenznummer des Undo-Protokolls wird erhöht.

Es lässt sich feststellen, dass jede Änderung der Daten ein Undo-Protokoll generiert. Wenn ein Datensatz mehrmals geändert wird, werden mehrere Undo-Protokolle generiert. Das Undo-Protokoll zeichnet das Protokoll vor der Änderung auf, und die Sequenznummer jedes Undo-Protokolls ist inkrementell. Wenn Sie also ein Rollback durchführen möchten, können Sie unsere Originaldaten finden, indem Sie entsprechend der Sequenznummer vorwärts blättern.

Wie wird das Undo-Protokoll zurückgesetzt?

Nehmen wir das obige Beispiel und gehen davon aus, dass ein Rollback ausgeführt wird. Der entsprechende Prozess sollte dann wie folgt aussehen:

• Löschen Sie die Daten mit der ID=2 über das Protokoll mit Undo-Nr.=3
• Stellen Sie das Löschzeichen der Daten mit id=1 auf 0 wieder her, indem Sie das Protokoll mit no=2 rückgängig machen
• Stellen Sie den Namen der Daten mit id=1 für Tom wieder her, indem Sie das Protokoll mit no=1 rückgängig machen.
• Löschen Sie die Daten mit id=1, indem Sie das Protokoll mit no=0 rückgängig machen

Wo befindet sich das Undo-Protokoll?

InnoDB verwaltet Undo-Logs in Segmenten, also Rollback-Segmenten. Jedes Rollback-Segment zeichnet 1024 Undo-Log-Segmente auf. Die InnoDB-Engine unterstützt standardmäßig 128 Rollback-Segmente.

mysql> Variablen wie „innodb_undo_logs“ anzeigen;
+------------------+--------+
| Variablenname | Wert |
+------------------+--------+
| innodb_undo_logs | 128 |
+------------------+--------+

Dann beträgt die maximale Anzahl gleichzeitiger Transaktionen, die unterstützt werden können, 128*1024. Jedes Undo-Log-Segment ist wie die Verwaltung eines Arrays mit 1024 Elementen.

Wenn wir eine Transaktion starten und ein Undo-Protokoll schreiben müssen, müssen wir zuerst eine freie Position im Undo-Protokollsegment finden. Wenn eine freie Position vorhanden ist, beantragen wir eine Undo-Seite und schreiben schließlich das Undo-Protokoll auf diese beantragte Undo-Seite. Wir wissen, dass die Standardseitengröße von MySQL 16 KB beträgt.

mysql> Variablen wie „%innodb_page_size%“ anzeigen;
+------------------+--------+
| Variablenname | Wert |
+------------------+--------+
| innodb_seitengröße | 16384 |
+------------------+--------+

Daher ist es eigentlich sehr verschwenderisch, einer Transaktion eine Seite zuzuweisen (es sei denn, Ihre Transaktion ist sehr lang). Angenommen, die TPS Ihrer Anwendung beträgt 1000, dann werden 1000 Seiten pro Sekunde benötigt, was etwa 16 MB Speicher erfordert, und für 1 Minute wird etwa 1 GB Speicher benötigt ... Wenn Sie so weitermachen, wird der Speicherplatz mit der Zeit sehr schnell wachsen, es sei denn, MySQL wird sehr sorgfältig bereinigt, und es wird viel Speicherplatz verschwendet. Daher ist die Rückgängig-Seite für die Wiederverwendung konzipiert. Wenn eine Transaktion festgeschrieben wird, wird die Rückgängig-Seite nicht sofort gelöscht. Aufgrund der Wiederverwendung ist die Rückgängig-Seite möglicherweise nicht sauber, sodass die Rückgängig-Seite mit dem Rückgängig-Protokoll anderer Transaktionen vermischt werden kann. Nachdem das Rückgängig-Protokoll festgeschrieben wurde, wird es in eine verknüpfte Liste eingefügt und anschließend ermittelt, ob der von der Rückgängig-Seite verwendete Speicherplatz weniger als 3/4 beträgt. Wenn es weniger als 3/4 ist, bedeutet dies, dass die aktuelle Rückgängig-Seite wiederverwendet werden kann, sodass sie nicht recycelt wird und das Rückgängig-Protokoll anderer Transaktionen hinter der aktuellen Rückgängig-Seite aufgezeichnet werden kann. Da das Undo-Protokoll diskret ist, ist die Effizienz der Bereinigung des entsprechenden Speicherplatzes nicht so hoch.

Dies ist das Ende dieses Artikels zum Verständnis der Prinzipien von MySQL-Persistenz und -Rollback. Weitere relevante Inhalte zu MySQL-Persistenz und -Rollback finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!