Analyse von MySQL-Latenzproblemen und Datenlöschungsstrategieprozess

1. MySQL-Replikationsprozess

Der offizielle Dokumentenprozess läuft wie folgt ab:

MySQL-Latenzprobleme und Datenlöschungsstrategien

1. Absolute Verzögerung, relative Synchronisation

2. Bei reinen Schreibvorgängen ist bei der Online-Standardkonfiguration der Druck auf die Slave-Datenbank größer als auf die Master-Datenbank. Zumindest wird in die Slave-Datenbank ein Relaylog geschrieben.

2. Analyse von MySQL-Verzögerungsproblemen

1. Häufige DML-Anfragen an die Hauptdatenbank

Ursache: Die Masterdatenbank schreibt Daten gleichzeitig, während die Slavedatenbank Protokolle in einem einzelnen Thread anwendet, was leicht zu einer Ansammlung von Relaylogs und zu Verzögerungen führen kann.

Lösung: Sharding wird verwendet, um Schreibanforderungen aufzuteilen. Erwägen Sie ein Upgrade auf MySQL 5.7+ und die Aktivierung der parallelen Replikation basierend auf logischen Uhren.

2. Die Hauptdatenbank führt große Transaktionen aus

Ursache: Beispielsweise dauert es sehr lange, bis die Master-Datenbank eine große Tabelle aktualisiert. Wenn die Master- und Slave-Datenbanken ähnliche Konfigurationen aufweisen, benötigt die Slave-Datenbank fast genauso viel Zeit, um die große Tabelle zu aktualisieren. Zu diesem Zeitpunkt beginnen sich die Verzögerungen der Slave-Datenbank anzuhäufen, und nachfolgende Ereignisse können nicht aktualisiert werden.

Lösung: Große Transaktionen aufteilen und rechtzeitig übermitteln.

3. Die Hauptdatenbank führt DDL-Anweisungen auf der großen Tabelle aus

Ursache: Die Ausführung des DDL wurde nicht gestartet und ist blockiert. Es wird überprüft, dass die Position unverändert bleibt. Der DDL wird ausgeführt und die Singlethread-Anwendung verursacht eine erhöhte Latenz und die Position bleibt unverändert.

Lösung: Suchen Sie die Abfrage, die den DDL- oder Schreibvorgang blockiert, beenden Sie die Abfrage und lassen Sie die normale Ausführung von DDL auf der Slave-Datenbank zu. Führen Sie die Abfrage außerhalb der Geschäftszeiten aus und versuchen Sie, eine höhere MySQL-Version zu verwenden, die OnlineDDL unterstützt.

4. Inkonsistente Konfiguration von Master- und Slave-Instanzen

Gründe: Hardware: Der Master-Instanz-Server verwendet SSD, während der Slave-Instanz-Server eine normale SAS-Festplatte verwendet, die CPU-Hauptfrequenz ist inkonsistent usw. Konfiguration: beispielsweise inkonsistente Schreibstrategie der RAID-Karte, inkonsistente Einstellungen der Betriebssystem-Kernelparameter, inkonsistente Schreibstrategie der MySQL-Festplatte (innodb_flush_log_at_trx_commit und sync_binlog usw.) usw.

Lösung: Versuchen Sie, die Konfiguration der DB-Maschinen (einschließlich Hardware- und Optionsparameter) zu vereinheitlichen. Selbst bei einigen OLAP-Unternehmen ist die Hardwarekonfiguration der Slave-Datenbankinstanz höher als die der Master-Datenbank.

5. Die Sklavenbibliothek selbst steht unter zu großem Druck

Ursache: Die Slave-Datenbank führt eine große Anzahl von Auswahlanforderungen aus, oder die meisten Auswahlanforderungen des Unternehmens werden an die Slave-Datenbankinstanz weitergeleitet, oder sogar eine große Anzahl von OLAP-Unternehmen, oder die Slave-Datenbank wird gesichert usw. Zu diesem Zeitpunkt ist die CPU-Auslastung möglicherweise zu hoch, die IO-Auslastungsrate möglicherweise zu hoch usw., was dazu führt, dass die SQLThread-Anwendung zu langsam ist.

Lösung: Erstellen Sie weitere Xi'an-Datenbank-Trainings-Slaves, um Lese-Aufträge zu verteilen und den Druck auf vorhandene Slave-Instanzen zu reduzieren.

Sie können auch die Datenträgerleerungsparameter innodb_flush_log_at_trx_commit=0 und sync_binlog=0 anpassen, um den IO-Druck zu verringern und die Master-Slave-Verzögerung zu reduzieren.

3. CPU-Überlastungsproblem während des Aktionszeitraums

Phänomen:

Eine hohe Parallelität führt zu einer übermäßigen CPU-Auslastung, die die Anforderungsverarbeitungszeit verlängert und allmählich zu einem Rückstau führt, was letztendlich dazu führt, dass der Dienst nicht mehr verfügbar ist. Eine große Anzahl langsamer SQL-Anweisungen führt zu einer übermäßigen CPU-Auslastung.

Lösung:

Grundsätzlich ist das Umschalten zwischen Master und Slave der Datenbank verboten oder wird sorgfältig überlegt. Dies kann das grundlegende Problem nicht lösen und erfordert eine F&E-Kooperation, um das SQL-Problem zu beheben. Ein Downgrade des Dienstes ist ebenfalls möglich. Für Container kann die CPU-Kapazität dynamisch erweitert werden. Verhandeln Sie mit dem Unternehmen, um pt-kill zu starten, um schreibgeschütztes langsames SQL zu beenden. Prüfen Sie, ob das Problem des langsamen SQL durch Hinzufügen allgemeiner oder gemeinsamer Indizes gelöst werden kann. Zu diesem Zeitpunkt müssen jedoch die Auswirkungen von DDL auf die Datenbank berücksichtigt werden.

4. InnoDB-Flushing-Strategie

Der MySQL-Parameter innodb_flush_method steuert den Öffnungs- und Leerungsmodus von InnoDB-Datendateien und Redolog. Das Dokument beschreibt diesen Parameter wie folgt:

Es gibt drei Werte: fdatasync (Standard), O_DSYNC, O_DIRECT

Der Standardwert ist fdatasync. Durch Aufruf von fsync() werden die Datendatei und der Redolog-Puffer geleert.

Wenn O_DSYNC verwendet wird, verwendet InnoDB O_SYNC zum Öffnen und Leeren von Redolog und fsync() zum Leeren von Datendateien.

Wenn O_DIRECT verwendet wird, verwendet InnoDB O_DIRECT zum Öffnen der Datendatei und fsync() zum Leeren der Datendatei und zum erneuten Protokollieren.

Erstens umfasst der Dateischreibvorgang drei Schritte: Öffnen, Schreiben, Leeren

Die oben am häufigsten erwähnte Funktion fsync(intfd) wird verwendet, um den Puffer, der sich auf die Datei bezieht, auf die der Dateideskriptor fd zeigt, während des Leerens auf die Festplatte zu leeren, und das Leeren gilt erst dann als erfolgreich, wenn die Metadateninformationen (wie Änderungsdatum, Erstellungsdatum usw.) geleert wurden.

Die Verwendung der O_DSYNC-Methode zum Öffnen der Redo-Datei bedeutet, dass beim Schreiben des Protokolls die Daten auf die Festplatte geschrieben werden und die Metadaten auch aktualisiert werden müssen, bevor eine Erfolgsmeldung zurückgegeben wird.

O_DIRECT bedeutet, dass unser Schreibvorgang direkt aus dem MySQL-InnoDB-Puffer auf die Festplatte geschrieben wird.

Die spezifischen Datenschreibmethoden dieser drei Modi sind wie folgt:

fdatasync-Modus: Beim Schreiben von Daten muss der Schreibschritt nicht wirklich auf die Festplatte geschrieben werden, um abgeschlossen zu sein (er kann als abgeschlossen zurückgegeben werden, wenn er in den Betriebssystempuffer geschrieben wird). Der eigentliche Abschluss ist der Leerungsvorgang, der Puffer wird zum Leeren an das Betriebssystem übergeben, und die Dateimetadateninformationen müssen auch auf der Festplatte aktualisiert werden.

O_DSYNC-Modus: Das Schreiben des Protokolls erfolgt im Schreibschritt, während das Schreiben der Datendatei im Flush-Schritt durch fsync erfolgt

O_DIRECT-Modus: Die Datendatei wird direkt von mysqlinnodbbuffer auf die Festplatte geschrieben, ohne den Betriebssystempuffer zu durchlaufen, und die eigentliche Fertigstellung erfolgt im Flush-Schritt. Das Protokoll muss noch den Betriebssystempuffer durchlaufen.

MySQL-Latenzprobleme und Datenlöschungsstrategien

1. In Unix-ähnlichen Betriebssystemen minimiert das Öffnen einer Datei im O_DIRECT-Modus die Auswirkungen der Pufferung auf die E/A. Die E/A der Datei wird direkt im Puffer im Benutzerbereich ausgeführt, und die E/A-Operation ist synchron. Daher wird garantiert, dass die Daten von der Festplatte gelesen werden, unabhängig davon, ob es sich um einen Systemaufruf read() oder write() handelt. Daher ist der E/A-Druck minimal, der CPU-Verarbeitungsdruck ist minimal und die physische Speichernutzung ist minimal. Aufgrund des fehlenden Puffers des Betriebssystems wird jedoch die Geschwindigkeit beim Schreiben von Daten auf die Festplatte erheblich reduziert (was sich in einer längeren Schreibantwortzeit äußert), das gesamte SQL-Anforderungsvolumen wird jedoch nicht erheblich reduziert (dies hängt von einer ausreichend großen innodb_buffer_pool_size ab).

2. Der O_DSYNC-Modus bedeutet, dass die Datei im synchronen IO-Modus geöffnet wird. Jeder Schreibvorgang wird blockiert, bis die Daten auf die physische Festplatte geschrieben sind. Dies führt zu längeren CPU-Wartezeiten, einem geringeren SQL-Anforderungsdurchsatz und längeren Einfügezeiten.

3. Die Funktion fsync(intfiledes) funktioniert nur mit einer einzelnen Datei, die durch den Dateideskriptor fileses angegeben ist, wartet, bis der Schreibvorgang auf die Festplatte abgeschlossen ist, und kehrt dann zurück. Die Funktion fdatasync(int files) ähnelt fsync, wirkt sich jedoch nur auf den Datenteil der Datei aus. Zusätzlich zu den Daten aktualisiert fsync auch synchron die Metadaten der Datei auf der Festplatte.

O_DSYNC belastet die CPU am meisten, gefolgt von datasync, und O_DIRECT belastet sie am wenigsten. In Bezug auf die Gesamtleistung bei der Verarbeitung von SQL-Anweisungen und die Reaktionszeit ist O_DSYNC schlecht. O_DIRECT hat einen besseren SQL-Durchsatz (nur der datasync-Modus ist besser), hat aber die längste Reaktionszeit.

Der standardmäßige Datasync-Modus bietet insgesamt eine bessere Leistung, da er die Verarbeitungsleistung des Betriebssystempuffers und des Innodb_Buffer_Pools voll ausnutzt. Der negative Effekt besteht jedoch darin, dass der freie Speicher zu schnell abnimmt, was letztendlich zu häufigen Seitenwechseln und hohem Festplatten-E/A-Druck führt, was wiederum die Stabilität großer gleichzeitiger Datenschreibvorgänge ernsthaft beeinträchtigt.

Zusammenfassen

Oben finden Sie die vom Herausgeber vorgestellte Analyse der MySQL-Latenzprobleme und des Datenlöschstrategieprozesses. Ich hoffe, sie wird allen helfen!