Lassen Sie uns über die globale MySQL-Sperre sprechen

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL, in dem hauptsächlich verwandte Probleme zu globalen Sperren vorgestellt werden. Globale Sperren sperren die gesamte Datenbank. Nachdem wir der Datenbank eine Lesesperre hinzugefügt haben, können keine anderen Anfragen eine Schreibsperre zur Datenbank hinzufügen. Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Lernen: MySQL-Video-Tutorial

Die ursprüngliche Absicht des Datenbankdesigns besteht darin, Probleme mit der Parallelität zu lösen. Da es sich um eine von mehreren Benutzern gemeinsam genutzte Ressource handelt, muss die Datenbank bei gleichzeitigem Zugriff die Zugriffsregeln angemessen steuern der Ressource. Die Sperre ist eine wichtige Datenstruktur, die zur Implementierung dieser Zugriffsregel verwendet wird.

Lassen Sie uns zunächst ein Diagramm der allgemeinen Klassifizierung von Sperren veröffentlichen

Entsprechend dem Umfang der Sperren können die Sperren in MySQL grob in globale Sperren, Tabellensperren und Zeilensperren unterteilt werden. Wir werden zunächst hauptsächlich diese Arten von Sperren kennenlernen. In diesem Artikel erfahren Sie mehr über globale Sperren.

Globale Sperre

Globale Sperre dient zum Sperren der gesamten Datenbank. Nachdem wir der Datenbank eine Lesesperre hinzugefügt haben, können keine anderen Anforderungen Schreibsperren zur Datenbank hinzufügen. Wenn wir der Datenbank eine Schreibsperre hinzufügen, können keine weiteren Anforderungen der Datenbank Lese- oder Schreibsperren hinzufügen.

FTWRL

MySQL bietet eine Methode zum Hinzufügen einer globalen Lesesperre und zum Leeren von Tabellen mit Lesesperre (FTWRL). Wenn wir die gesamte Bibliothek in einen schreibgeschützten Zustand versetzen müssen, können wir diesen Befehl verwenden. Dann werden die folgenden Anweisungen anderer Threads blockiert: Datenaktualisierungsanweisungen (Hinzufügen, Löschen, Ändern), Datendefinitionsanweisungen (einschließlich Erstellen von Tabellen). , Ändern von Tabellenstrukturen usw.) und aktualisieren Eine Commit-Anweisung für eine Klassentransaktion.

Verwendungsszenarien globaler Sperren

Verwendungsszenarien globaler Sperren: Erstellen Sie eine logische Sicherung der gesamten Datenbank. Logisches Backup bedeutet, jede Tabelle in der gesamten Datenbank auszuwählen und als Text zu speichern. Das heißt, die globale Sperre wird nur verwendet, wenn eine Master-Slave-Datensicherung durchgeführt oder Daten importiert und exportiert werden.

Warum brauchen Sie also eine globale Sperre?

Denn wenn wir Daten sichern oder Daten importieren und exportieren und in diesem Zeitraum gleichzeitig Daten hinzugefügt, gelöscht und geändert werden können, kommt es zu Dateninkonsistenzen.

In der Vergangenheit gab es eine Möglichkeit, die oben erwähnte FTWRL zu verwenden, um sicherzustellen, dass kein anderer Thread die Datenbank während des Backups aktualisiert. Hinweis: Während des Backup-Vorgangs ist die gesamte Bibliothek vollständig schreibgeschützt.

Da die globale Sperre auf diese Datenbank ausgerichtet ist, klingt das Hinzufügen einer globalen Sperre sehr gefährlich:

• Wenn wir ein Backup auf der Hauptdatenbank erstellen, können während des Backup-Zeitraums keine Aktualisierungen durchgeführt werden, was bedeutet, dass grundsätzlich alle Geschäfte ausgesetzt sind.
• Wenn wir auf der Slave-Datenbank sichern, kann das von der Master-Datenbank während des Sicherungszeitraums synchronisierte Binlog nicht ausgeführt werden, was zu Master-Slave-Verzögerungen und Dateninkonsistenzen führt.

Wie vermeide ich Sperren?

Können wir Sperren vermeiden, da das Hinzufügen einer globalen Sperre so große Auswirkungen hat?

Durch die obige Einführung wissen wir, dass das Sperren das Problem der Dateninkonsistenz lösen soll. Solange wir das Problem der Dateninkonsistenz lösen können, müssen wir keine globale Sperre hinzufügen. Es gibt eine solche Idee: Wenn wir zu Beginn der Datensicherung ein Betriebsprotokoll aufzeichnen, ist das Hinzufügen, Löschen, Ändern und Abfragen der Datenbank während des Sicherungsvorgangs ohne Sperre zulässig, und während des Sicherungsvorgangs werden die Vorgänge von Ergänzungen aufgezeichnet , Löschungen, Änderungen und Abfragen werden in einer Protokolldatei aufgezeichnet. Nachdem unsere Sicherung abgeschlossen ist, führen wir in diesem Zeitraum alle Vorgänge in der Protokolldatei aus. Dies stellt die Konsistenz der Daten vor und nach der Sicherung sicher.

Zusammenfassend lässt sich sagen, dass sich die Sicherungsdaten und die Hauptdaten ohne Sperrung nicht zu einem logischen Zeitpunkt befinden und diese Ansicht logisch inkonsistent ist. Wenn wir sicherstellen, dass die logischen Zeitpunkte konsistent sind, d konsistente Ansicht.

In InnoDB, der Standard-Engine von MySQL, gibt es einen Mechanismus, um die Datenkonsistenz sicherzustellen. Die InnoDB-Engine verfügt über eine Daten-Snapshot-Versionsfunktion. Diese Funktion wird als MVCC bezeichnet, da jeder Snapshot einer Transaktionsversionsnummer entspricht Beim Abrufen von Daten müssen Sie nur Daten mit einer kleineren Transaktionsversionsnummer als Ihrer eigenen lesen.

–Einzeltransaktions-Befehlssperre

Das offizielle logische Backup-Tool ist mysqldump. Wenn mysqldump den Parameter –single-transaction verwendet, wird vor dem Importieren von Daten eine Transaktion gestartet, um sicherzustellen, dass eine konsistente Ansicht erhalten wird. Aufgrund der Unterstützung von MVCC können die Daten während dieses Vorgangs normal aktualisiert werden.

--Die Rolle des Einzeltransaktionsparameters besteht darin, die Isolationsstufe der Transaktion auf wiederholbares Lesen, also REPEATABLE READ, festzulegen. Dadurch wird sichergestellt, dass alle gleichen Abfragen in einer Transaktion die gleichen Daten lesen, was dies in etwa garantiert Wenn andere InnoDB-Engine-Threads die Tabellendaten ändern und übermitteln, hat dies keine Auswirkungen auf die Daten des Dump-Threads.

Und stellen Sie WITH CONSISTENT SNAPSHOT auf Snapshot-Ebene ein. Stellen Sie sich vor, wenn es sich nur um wiederholbares Lesen handelt und die Daten nicht zu Beginn der Transaktion ausgegeben werden, andere Threads die Daten ändern und übermitteln, dann ist das Ergebnis der ersten Abfrage zu diesem Zeitpunkt das von anderen Threads übermittelte Ergebnis WITH CONSISTENT SNAPSHOT kann sicherstellen, dass beim Start einer Transaktion das Ergebnis der ersten Abfrage die Daten A zu Beginn der Transaktion sind. Auch wenn andere Threads zu diesem Zeitpunkt ihre Daten in B ändern, ist das Ergebnis der Abfrage immer noch A .

Die Einzeltransaktionsmethode gilt nur für Bibliotheken, die Transaktions-Engines für alle Tabellen verwenden. Im mysqldump-Prozess kann durch Hinzufügen von --single-transaction sichergestellt werden, dass die InnoDB-Daten vollständig konsistent sind. Bei Engines wie MyISAM, die keine Transaktionen unterstützen, können dann immer nur die neuesten Daten abgerufen werden Dadurch wird die Konsistenz des Backups zerstört. Zu diesem Zeitpunkt ist noch eine globale Sperre erforderlich, daher müssen wir weiterhin den Befehl FTWRL verwenden.

Schreibgeschützte Einstellung

Möglicherweise haben wir auch diese Frage: Da die gesamte Bibliothek schreibgeschützt sein muss, warum verwenden wir nicht set global readonly = true?

Es ist wahr, dass die readonly-Methode auch die gesamte Bibliothek in einen schreibgeschützten Zustand versetzen kann, es wird jedoch dennoch empfohlen, die FTWRL-Methode zu verwenden, hauptsächlich aus zwei Gründen:

• In einigen Systemen wird der readonly-Wert sein Wird für andere Logik verwendet, z. B. Bestimmen, ob eine Datenbank die Primär- oder Standby-Datenbank ist. Daher hat die Änderung globaler Variablen eine größere Auswirkung.
• Es gibt Unterschiede in den Ausnahmebehandlungsmechanismen. Wenn der Client nach der Ausführung des FTWRL-Befehls die Verbindung abnormal trennt, gibt MySQL automatisch die globale Sperre frei und die gesamte Bibliothek kehrt in einen Zustand zurück, in dem sie normal aktualisiert werden kann.

Nachdem die gesamte Bibliothek auf schreibgeschützt gesetzt wurde und auf dem Client eine Ausnahme auftritt, bleibt die Datenbank im schreibgeschützten Zustand, was dazu führt, dass sich die gesamte Bibliothek für lange Zeit in einem nicht beschreibbaren Zustand befindet und ein hohes Risiko darstellt.

Empfohlenes Lernen: MySQL-Video-Tutorial

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die globale MySQL-Sperre sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!