Detaillierte Erläuterung des MySQL-Thread-Status

Article Directory

• • 1 Thread-Status
  • 7. Master-Slave-Verbindungs-Thread-Status
  • 8. Ereignisplanungs-Thread-Status
  • Verwandte kostenlose Lernempfehlungen:

  • MySQL-Video-Tutorial

1. Show Prozessliste

Id: Verbindungsprozess-ID. Ist der von der Funktion CONNECTION_ID() zurückgegebene Wert. Benutzer: Der Name des MySQL-Benutzers, der die Anweisung ausgeführt hat. Wenn „Systembenutzer“ angezeigt wird, bezieht sich dies auf einen von MySQL generierten Nicht-Client-Thread, der interne Aufgaben ausführt. Zum Beispiel E/A- oder SQL-Threads, die in Slave-Bibliotheken bei der Primär-Standby-Replikation verwendet werden, oder Threads für verzögerte Zeilenhandler. „Nicht authentifizierter Benutzer“ bezieht sich auf den Thread, in dem der Client eine TCP/IP-Verbindung mit dem Server hergestellt hat, aber das Benutzerkennwort des Clients noch nicht authentifiziert hat. „event_scheduler“ bezieht sich auf den Thread, der geplante Aufgabenplanungsereignisse überwacht.

Host: Der Hostname des Clients, der die Anweisung ausführt, angezeigt in host_name: client_port (wenn der Parameter „skip_name_resolve“ aktiviert ist, wird er im Format ip: client_port angezeigt)

Db: Die vom Client verbundene Standarddatenbank (falls der Beim Verbinden wird der Bibliotheksname angegeben), andernfalls wird NULL angezeigt.

Befehl: Der Typ des Befehls, der vom Thread ausgeführt wird.

• Zeit: Die Zeit (in Sekunden), die sich der Thread im aktuellen Zustand befindet. Bei Slave-SQL-Threads ist dieser Wert die Anzahl der Sekunden zwischen dem Zeitpunkt des letzten Replikationsereignisses und der tatsächlichen Zeit des Slaves.
• Status: Fragt nach, welche Art von Vorgang, Ereignis oder Status der Thread ausführt.
  
Info: Die Anweisung, die vom Thread ausgeführt wird.
• 2. Befehlsbefehlstyp
• Binlog Dump: Der Hauptbibliotheksthread wird verwendet, um den Binärprotokollinhalt an die Slave-Bibliothek zu senden
• Benutzer ändern: Der Thread führt einen Benutzeränderungsvorgang aus
• Close stmt: Der Thread schließt eine voreingestellte kompilierte Anweisung

Connect: Der Thread der Slave-Bibliothek wurde mit der Hauptbibliothek verbundenConnect Out: Die Slave-Bibliothek stellt eine Verbindung mit der Hauptbibliothek her

Create DB: Der Thread führt einen Datenbankerstellungsvorgang durch
• Daemon: Dies ist der interne Thread des Servers, kein Client-Verbindungsthread.
• Debug: Der Thread generiert Debugging-Informationen.
• Verzögerte Einfügung: Es handelt sich um einen Thread, der den Einfügungshandler verzögert Datenbanklöschvorgang
• Execute: Der Thread führt eine vorkompilierte gute Anweisung aus
• Fetch: Der Thread führt die Anweisung aus und ruft die Ergebnismenge daraus ab
• Feldliste: Der Thread ruft die Informationen der Tabellenspalten ab
• Init DB: Der Thread wählt die Standarddatenbank aus
• Kill: Der Thread beendet andere Threads
• Long Data: Der Thread führt die Anweisung aus und ruft daraus die Datenergebnismenge vom Typ „Long Field“ (großes Feld) ab und gibt sie zurück
• Ping : Der Thread verarbeitet die Server-Ping-Anfrage.
• Vorbereiten: Der Thread führt aus, um eine Anweisung vorzukompilieren.
• Prozessliste: Der Thread generiert Informationen über den Server-Thread.
• Abfrage: Der Thread führt die Abfrageanweisung aus.
• Beenden: Die Thread wird beendet
• Aktualisieren: Der Thread aktualisiert die Tabelle, das Protokoll oder den Cache oder setzt Statusvariablen zurück oder kopiert Serverinformationen
• Register Slave: Thread Registrieren der Slave-Bibliothek in der Hauptbibliothek
• Reset stmt: Der Thread setzt die zurück vorkompilierte Anweisung
• Set-Option: Der Thread setzt die Client-Anweisungsausführungsoption oder setzt sie zurück
• Shutdown: Der Thread führt das Herunterfahren des Servers aus
• Sleep: Der Thread wartet darauf, dass der Client eine neue Anweisungsanforderung an ihn sendet
• Statistiken : Der Thread generiert Serverstatusinformationen
• Table Dump: Der Thread sendet den Tabelleninhalt an die Slave-Bibliothek
• 3. Benutzer-Thread-Status
• • Nach dem Erstellen: Dieser Zustand tritt auf, wenn der Thread die Erstellung einer Tabelle (einschließlich interner temporärer Tabellen) abschließt.
    Dieser Status tritt auch dann auf, wenn das Erstellen der Tabelle aufgrund eines Fehlers mit einem Fehler endet.
  • Analysieren: Thread ist ANALYZE TABLE.
  • Berechtigungen prüfen: Es wird auf dem Server überprüft, ob der Thread über die erforderlichen Berechtigungen zum Ausführen der Anweisung verfügt.
  • Tabelle wird überprüft : Thread-Tabellenüberprüfungsvorgang wird ausgeführt
  • Aufräumen: Der Thread hat die Ausführung eines Befehls abgeschlossen und bereitet sich darauf vor, den belegten Speicher freizugeben und einige Statusvariablen zurückzusetzen.
  • Tabellen schließen: Der Thread schreibt die geänderten Daten der Tabelle auf die Festplatte und die Oberfläche schließen.
  • HEAP in MyISAM konvertieren: Thread konvertiert interne temporäre Tabelle von MEMORY-Engine-Tabelle in temporäre Tabelle auf der Festplatte MyISAM-Engine
  • In tmp-Tabelle kopieren: Thread führt ALTER TABLE-Anweisung aus. Dieser Zustand tritt auf, nachdem die Tabelle mit der neuen Struktur erstellt wurde und bevor die alten Tabellendaten in die neue Tabelle kopiert werden. Kopieren in die Gruppentabelle: Wenn die Anweisung unterschiedliche ORDER BY- und GROUP BY-Bedingungsspalten verwendet, wird das Group-by-Paar verwendet . Diese Datenzeilen werden sortiert und die sortierten Ergebnisse werden in die temporäre Tabelle kopiert
  • Kopieren in die tmp-Tabelle: Der Server kopiert die Daten in die temporäre Speichertabelle
  • Änderungstabelle: Der Server führt den Prozess der Eingabe aus. place ALTER TABLE
  • Kopieren in die tmp-Tabelle auf der Festplatte: Der Server kopiert Daten in eine temporäre Tabelle auf der Festplatte. Da die temporäre Ergebnismenge zu groß ist, konvertiert der Thread die speicherinterne temporäre Tabelle in eine festplattenbasierte temporäre Tabelle, um Speicher zu sparen
  • Index wird erstellt: Der Thread führt eine ALTER TABLE ... ENABLE KEYS-Anweisung aus
  • Erstellung Sortierindex: Der Thread führt SELECT aus und verwendet die interne temporäre Tabelle
  • Tabelle erstellen: Der Thread erstellt die Tabelle. Dieser Status wird auch beim Erstellen temporärer Tabellen verwendet.
  • Tmp-Tabelle erstellen: Der Thread erstellt eine temporäre Tabelle im Speicher oder auf der Festplatte. Wenn die Tabelle im Speicher erstellt, aber später auf die Festplatte konvertiert wurde, lautet der Status während dieses Vorgangs „Kopieren in die tmp-Tabelle auf der Festplatte“.
  • Änderungstabelle wird an die Speicher-Engine übergeben: Der Server hat eine ALTER-Operation durchgeführt, die den In-Place-Algorithmus TABLE vervollständigte Anweisung, Senden
  • Löschen aus der Haupttabelle: Der Server führt den ersten Teil der Multi-Table-Delete-Anweisung aus. Wenn Sie diesen
  -Status sehen, bedeutet dies, dass er aus der ersten Tabelle gelöscht wird und Spaltendaten und Offsets für die spätere Löschung anderer Tabellen gespeichert werden
  • 
    Löschen aus Referenztabellen: Der Server führt den zweiten Teil der Multi-Table-Delete-Anweisung von „Delete“ aus übereinstimmende Zeilen in anderen Tabellen
  • discard_or_import_tablespace: Thread führt die Anweisung ALTER TABLE … DISCARD TABLESPACE oder ALTER TABLE … IMPORT TABLESPACE aus
  • end: Dies geschieht am Ende der Anweisungsausführung, aber nach dem Löschen von ALTER TABLE, CREATE VIEW, DELETE, INSERT , Dieser Zustand tritt vor einer SELECT- oder UPDATE-Anweisung ein.
  • Ausführen: Der Thread führt eine Anweisung aus.
  • Ausführung von init_command: Der Thread führt eine Anweisung aus, die Systemvariablen initialisiert. Elemente freigeben: Der Thread hat die Ausführung eines Befehls abgeschlossen. Geben Sie einige Elemente im Zusammenhang mit dem Abfrage-Cache-Status frei
  . Auf diesen Status folgt normalerweise der Aufräumstatus.
  • FULLTEXT-Initialisierung: Der Server bereitet die Durchführung einer Volltextsuche in natürlicher Sprache vor.
  • 
    init: Dieser Status tritt auf, bevor die Anweisung ALTER TABLE, DELETE, INSERT, SELECT oder UPDATE initialisiert wird . Zu den vom Server in diesem Zustand ausgeführten Vorgängen gehören das Aktualisieren des Binärprotokolls, des InnoDB-Protokolls und einige Vorgänge zum Bereinigen des Abfragecaches. Am Ende dieses Zustands kann es zu folgenden Vorgängen kommen:
  Abfrage-Cache-Einträge löschen, wenn sich die Daten in der Tabelle ändern
  • Ereignisse in das Binärprotokoll schreiben
  Geben Sie Speicherpuffer frei, einschließlich Blobs
  • Getötet: Initiieren Sie einen Kill-Vorgang für den Thread, und der Thread sollte den Beendigungsvorgang ausführen. Das Kill-Flag eines Threads wird in jeder Hauptschleife in MySQL überprüft, aber in manchen Fällen dauert es möglicherweise nur kurze Zeit, den Thread zu beenden. Wenn der zu tötende Thread jedoch von anderen Threads gesperrt ist, müssen Sie warten, bis andere Threads die Sperre aufheben, bevor der Kill-Befehl wirksam wird und ausgeführt wird.
  • langsame Abfrage protokollieren: Der Thread schreibt eine Anweisung in das langsame Abfrageprotokoll
  • Anmeldung: Der Anfangsstatus des Verbindungsthreads bis zur erfolgreichen Authentifizierung des Clients
  • Schlüssel verwalten: Der Server aktiviert oder deaktiviert Tabellenindizes
  • NULL: Dieser Status wird für die SHOW PROCESSLIST-Anweisung verwendet.
  • Tabellen öffnen: Der Thread versucht, eine Tabelle zu öffnen. Offene Tischoperationen sollten sehr schnell sein, es sei denn, die offene Operation ist blockiert. Beispielsweise verhindert eine ALTER TABLE- oder LOCK TABLE-Anweisung, dass die Tabelle geöffnet wird, bis die Anweisung abgeschlossen ist. Darüber hinaus kann es sein, dass table_open_cache nicht groß genug ist und die Tabelle nicht geöffnet werden kann.
  • Optimieren: Der Server führt eine anfängliche Optimierung der Abfrage durch.
  • Vorbereiten: Dieser Status tritt während der Abfrageoptimierung auf.
  • Löschen alter Relay-Protokolle: Der Thread löscht unnötige Relay-Protokolldateien.
  • Abfrageende: Dieser Status tritt beim Ausführen der Abfrage auf Nach der Anweisung, aber vor der Freigabe der Statuselemente im Zusammenhang mit der Abfrageanweisung
  • Lesen aus dem Netz: Der Server liest Datenpakete aus dem Netzwerk. Nach MySQL 5.7.8 heißt dieser Zustand „Receiving from client“ – Empfangen vom Client: Der Server liest Pakete vom Client. In MySQL 5.7.8 heißt es „Lesen aus dem Netz“
  • Duplikate entfernen: Wenn die Abfrage die SELECT DISTINCT-Anweisung verwendet, kann MySQL den eindeutigen Vorgang in der frühen Phase nicht optimieren. Daher benötigt MySQL einen zusätzlichen Schritt, um alle doppelten Zeilen zu entfernen und dann die Ergebnisse an den Client zu senden.
  • Tmp-Tabelle entfernen: Der Thread löscht die interne temporäre Tabelle, nachdem die Ausführung der SELECT-Anweisung abgeschlossen ist. Wenn die SELECT-Anweisung keine temporäre Tabelle erstellt, tritt dieser Status nicht auf.
  • rename: Der Thread führt die Rename-Anweisung aus, um die Tabelle umzubenennen Tabelle. Die neue Tabelle wurde erstellt und wird verarbeitet. Ersetzen Sie den alten Tabellennamen durch die neue Tabelle.
  • Tabellen erneut öffnen: Der Thread hat die Tabellensperre erhalten, aber nach Erhalt der Sperre wurde festgestellt, dass die zugrunde liegende Tabellenstruktur vorhanden war geändert.
  Lösen Sie also die Tabellensperre, schließen Sie die Tabelle und versuchen Sie, die Tabelle erneut zu öffnen.
  • 
    Reparieren durch Sortieren: Der Reparaturcode verwendet Sortieren, um den Index zu erstellen.
  • Vorbereitung für Alter Table: Der Server bereitet die Ausführung der ALTER TABLE-Anweisung vor des In-Place-Algorithmus – Reparatur abgeschlossen: Dieser Thread hat die Multithread-Reparatur der MyISAM-Tabelle abgeschlossen
  • Reparatur mit Schlüsselcache: Der Reparaturcode verwendet die Methode, Schlüssel einzeln über den Schlüsselcache zu erstellen, um den Index zu reparieren . Dies ist viel langsamer als die Methode „Reparatur nach sortiertem Index“.
  • Rollback: Der Thread führt ein Rollback der Transaktion durch.
  • Status speichern: Bei MyISAM-Tabellenoperationen (z. B. Reparatur oder Analyse) speichert der Thread den neuen Tabellenstatus im .MYI-Dateiheader. Der Status umfasst: Informationen wie die Anzahl der Tabellendatenzeilen, den AUTO_INCREMENT-Zähler und die Schlüsselverteilung.
  • Zeilen zur Aktualisierung suchen: Der Thread führt die erste Phase durch, um alle übereinstimmenden Zeilen zu finden, bevor er sie aktualisiert. Wenn UPDATE den Index ändert, der zum Suchen der beteiligten Zeilen verwendet wird, müssen zuerst die Zeilen gefunden werden, die mit der Aktualisierung übereinstimmen. Daten senden: Der Thread liest und verarbeitet die von der SELECT-Anweisung generierten Datenzeilen und sendet die Daten an den Client. Da während dieses Zustands ausgeführte Vorgänge erhebliche Festplattenzugriffe (Lesevorgänge) generieren können, handelt es sich in der Regel um den am längsten laufenden Zustand während der Lebensdauer einer bestimmten Abfrage.
    
  An Client senden: Der Server schreibt ein Paket an den Client. Vor MySQL 5.7.8 hieß es „Ins Netz schreiben“
  • Setup: Der Thread führt eine ALTER TABLE-Operation aus
  • Sortierung nach Gruppe: Der Thread führt eine GROUP BY-Sortieroperation aus
  • Sortierung nach Reihenfolge: Der Thread ist Durchführen einer ORDER BY-Sortieroperation
  • Sortierindex: Der Thread sortiert Indexseiten für einen effizienteren Zugriff während MyISAM-Tabellenoptimierungsoperationen
  • Sortierergebnis: Für SELECT-Anweisungen entspricht dies dem Status „Sortierindex erstellen“, jedoch nicht temporär Tabellen
  • Statistik: Der Server berechnet Statistiken, um Abfrageausführungspläne zu optimieren. Wenn sich ein Thread längere Zeit in diesem Zustand befindet, führt der Server möglicherweise andere Arbeiten auf der Festplatte aus und blockiert den Betrieb statistischer Informationen, oder es kann zu einer Sperrwartezeit kommen.
  • Systemsperre: Der Thread namens mysql_lock_tables() und der Thread-Status wurden nie aktualisiert. Dies ist ein sehr häufiger Zustand und kann aus vielen Gründen auftreten. Beispielsweise fordert ein Thread eine interne oder externe Systemsperre für eine Tabelle an oder wartet darauf. Dies kann auftreten, wenn InnoDB während LOCK TABLES auf Sperren auf Tabellenebene wartet. Wenn dieser Zustand durch eine externe Sperranforderung verursacht wird, können Sie die Option –skip-external-locking verwenden, um die externe Systemsperre zu deaktivieren, wenn Sie nicht mehrere mysqld-Server verwenden, um auf dieselbe MyISAM-Tabelle zuzugreifen. Allerdings ist die externe Sperre standardmäßig deaktiviert, sodass diese Option möglicherweise keine Auswirkung hat.
  • Für SHOW PROFILE zeigt dieser Status an, dass der Thread eine Sperre anfordert.
  • Update: Der Thread bereitet sich darauf vor, mit der Aktualisierung der Tabelle zu beginnen.
  • Aktualisierung: Der Thread sucht und aktualisiert Datenzeilen.
  • Haupttabelle wird aktualisiert: Der Server führt die aus erster Teil der Multi-Table-Update-Anweisung. Dieser Status zeigt an, dass die erste Tabelle aktualisiert wird und Spaltenwerte und Offsets zum Aktualisieren anderer (Referenz-)Tabellen gespeichert werden
    
  Referenztabellen aktualisieren: Der Server führt den zweiten Teil der Multi-Table-Update-Anweisung aus und aktualisiert andere Tabellen
  • Passende Zeilen für
    
  Benutzersperre: Der Thread fordert die vorgeschlagene Sperre an oder wartet darauf, die über einen GET_LOCK()-Aufruf angefordert wird. Für SHOW PROFILE zeigt dieser Status an, dass der Thread die Sperre anfordert (kein Warten erforderlich).
  • Benutzerschlaf: Der Thread hat SLEEP() aufgerufen.
  • Warten auf Festschreibungssperre: Die FLUSH TABLES WITH READ LOCK-Anweisung erhält die Festschreibung Sperre
  • Warten auf globale Lesesperre: FLUSH TABLES WITH READ LOCK Warten auf den Erwerb einer globalen Lesesperre oder einer globalen read_only-Systemvariableneinstellung
  • Warten auf Tabellen: Der Thread erhält eine Benachrichtigung, dass sich die zugrunde liegende Struktur der Tabelle geändert hat und benötigt um die Tabelle erneut zu öffnen und eine neue Struktur zu erhalten. Um die Tabelle jedoch erneut zu öffnen, muss gewartet werden, bis alle anderen Threads den Zugriff auf die Tabelle für die alte Datenstruktur geschlossen haben. Diese Benachrichtigung tritt auf, wenn ein anderer Faden Spültabellen oder eine der folgenden Anweisungen in der Tabelle verwendet hat:
  • 
    
  flush -Tabellen TBL_NAME
  • UMERTE TABELLE
  Warten auf Tabellenlöschung: Der Thread führt FLUSH TABLES aus und wartet darauf, dass alle Threads die Tabellen schließen, auf die zugegriffen wird, oder der Thread erhält eine Benachrichtigung, dass sich die zugrunde liegende Struktur der Tabelle geändert hat und er die Tabelle erneut öffnen muss, um die neue zu erhalten Struktur. Um die Tabelle jedoch erneut zu öffnen, muss gewartet werden, bis alle anderen Threads den Zugriff auf die alte Tabellenstruktur geschlossen haben. Diese Benachrichtigung erfolgt, wenn ein anderer Thread FLUSH TABLES oder eine der folgenden Anweisungen für die Tabelle verwendet hat:
  • FLUSH TABLES tbl_name
  • ALTER TABLE
  • RENAME TABLE
  REPAIR TABLE
  • ANALYZE TABLE
  OPTIMIZE TABLE
  • Warten auf lock_type-Sperre: Der Server wartet darauf, eine THR_LOCK-Sperre oder eine MDL-Sperre vom Metadaten-Sperrsubsystem zu erhalten, wobei lock_type den Typ der MDL-Sperre angibt, auf die er wartet, und THR_LOCK nur einen Typ hat (Warten auf Sperre auf Tabellenebene), MDL-Sperren lauten wie folgt:
  • Warten auf Ereignismetadatensperre
  • Warten auf globale Lesesperre
  • Warten auf Schemametadatensperre
  Warten auf Metadatensperre für gespeicherte Funktionen
  • Warten auf Metadatensperre für gespeicherte Prozeduren
  Warten auf Tabellenmetadatensperre
  • Warten auf Triggermetadatensperre
  • Warten auf Bedingung: Ein häufiger Zustand, in dem der Thread darauf wartet, dass die Bedingung wahr wird. Keine spezifischen Statusinformationen verfügbar
  • Ins Netz schreiben: Der Server schreibt Pakete in das Netzwerk. Ab MySQL 5.7.8 heißt es „Senden an Client“
  • 4. Dump-Thread-Status
  Lesen eines Binlogs abgeschlossen; Wechsel zum nächsten Binlog: Der Thread hat das Lesen der Binlog-Datei abgeschlossen und ist zum nächsten gewechselt Eine Binlog-Datei
  • Der Master hat alle Binlog-Dateien an den Slave gesendet. Er wartet auf weitere Aktualisierungen: Der Thread hat alle verbleibenden Aktualisierungsprotokolle aus dem Binärprotokoll gelesen und an die Slave-Bibliothek gesendet. Der Thread ist derzeit inaktiv und wartet darauf, dass neue aktualisierte Datenereignisse in das Binärprotokoll geschrieben werden
  • Binlog-Ereignis an Slave senden: Der Thread hat ein Ereignis aus dem Binärprotokoll gelesen und sendet es nun an die Slave-Bibliothek (das Binärprotokoll). wird gesendet von: Ein Ereignis besteht normalerweise aus aktualisierten Daten und einigen anderen Informationen .IO-Thread-Status
  • Überprüfen der Master-Version: Ein sehr kurzer Zustand nach dem Herstellen einer Verbindung mit der Master-Bibliothek, der anzeigt, dass die Versionsnummer der Master-Bibliothek überprüft wird.
  • Verbindung zum Master herstellen: Der Thread versucht, eine Verbindung zur Master-Bibliothek herzustellen.
  • Master wird in die Warteschlange gestellt Ereignis im Relay-Protokoll: Thread Ein Ereignis wurde gelesen und zur Wiedergabe durch den SQL-Thread in das Relay-Protokoll kopiert.
  • Erneute Verbindung nach einer fehlgeschlagenen Binlog-Dump-Anfrage: Thread versucht, sich erneut mit dem Master zu verbinden.
  • Wiederverbindung nach einem fehlgeschlagenen Master-Ereignis Lesen Sie: Thread versucht, die Verbindung zur Master-Bibliothek wiederherzustellen. Wenn die erneute Verbindung erfolgreich ist, ändert sich der Status in „Warten auf das Senden eines Ereignisses durch den Master“ – Registrierung des Slaves auf dem Master: ein sehr kurzer Zustand nach erfolgreicher Verbindung mit der Master-Bibliothek, der darauf hinweist Der Slave sendet ein Ereignis an die Master-Bibliothek (z. B. die IP- und Portinformationen der Slave-Bibliothek usw.).
  • Binlog-Dump anfordern: ein sehr kurzer Status nach der Verbindung mit der Hauptbibliothek Die Bibliothek wurde erfolgreich eingerichtet. Verwenden Sie die aktuelle E/A-Thread-Position, um die Hauptbibliothek anzufordern. Warten auf das Senden eines Ereignisses durch den Master: Der Thread ist bereits mit der Hauptbibliothek verbunden und wartet auf ein neues binäres
    -Protokollereignis, das möglicherweise eine Zeit lang andauert lange Zeit, wenn die Hauptbibliothek inaktiv ist. Wenn das Warten länger als „slave_net_timeout“ Sekunden andauert, tritt beim Slave-E/A-Thread eine Zeitüberschreitung auf. Zu diesem Zeitpunkt geht der E/A-Thread der Slave-Bibliothek davon aus, dass die Verbindung zur Master-Bibliothek getrennt ist, und versucht, die Verbindung zur Master-Bibliothek wiederherzustellen.
  • Warten auf Master-Update: Der Anfangszustand vor dem Herstellen einer Verbindung zur Master-Bibliothek für Slave-Mutex beim Beenden: wenn der Thread stoppt. Ein Zustand, der kurz auftritt und anzeigt, dass die relevanten sich gegenseitig ausschließenden Ressourcen des E/A-Threads recycelt werden
    
  Warten darauf, dass der Slave-SQL-Thread genügend Relay-Log-Speicherplatz freigibt: Wenn das Relay_log_space_limit Der Wert der Variableneinstellung ist nicht 0. Wenn die Gesamtgröße des Relay-Protokolls diesen Wert überschreitet, wird dieser Wert erreicht. Der E/A-Thread wartet, bis der SQL-Thread den vom Relay-Protokoll belegten Speicherplatz freigibt, indem er den Inhalt des Relay-Protokolls wiedergibt und das wiedergegebene Relay-Protokoll löscht, sodass die Größe des Relay-Protokolls nicht größer als der Wert der Variable „relay_log_space_limit“ ist . kann der E/A-Thread weiterhin Relay-Protokollvorgänge schreiben.
  • 
    Warten auf erneute Verbindung nach einer fehlgeschlagenen Binlog-Dump-Anfrage: Wenn die Binär-Log-Dump-Anfrage fehlschlägt (aufgrund einer Verbindungsunterbrechung), wechselt der Thread zu diesem Zeitpunkt in den Ruhezustand und der E/A-Thread versucht es regelmäßig Stellen Sie erneut eine Verbindung zur Hauptbibliothek her. Das Intervall zwischen den Wiederholungsversuchen kann mit der Option MASTER_CONNECT_RETRY der Anweisung CHANGE MASTER TO angegeben werden
  • Es ist zu beachten, dass der E/A-Thread der Slave-Bibliothek über einen Heartbeat-Mechanismus verfügt, um eine Verbindung zur Hauptbibliothek herzustellen Überschreitet diese Heartbeat-Zeit, werden keine neuen Daten gesendet. Wenn das Ereignis auf dem Slave eintrifft, initiiert der E/A-Thread eine Heartbeat-Anfrage an die Hauptbibliothek Sendet ein neues Ereignis an den Slave, wird auch die Heartbeat-Zeit zurückgesetzt. Heartbeat-Zeit Wird durch die Option MASTER_HEARTBEAT_PERIOD der Change-Master-Anweisung festgelegt (in Sekunden), Bereich 0 bis 4294967 Sekunden, Auflösung (Millisekunden). Der Mindestwert ungleich Null beträgt 0,001, was 1 Millisekunde entspricht. Wenn Sie das Intervall auf 0 setzen, werden Heartbeats deaktiviert. Der Standardwert ist die Hälfte des Konfigurationsparameters „slave_net_timeout“. Theoretisch wird es also keine Situation geben, in der der E/A-Thread der Slave-Bibliothek getrennt wird, da die Master-Bibliothek keine Daten schreibt, wenn die Master-Slave-Datenbank normal ist.
  • Warten auf erneute Verbindung nach einem fehlgeschlagenen Lesen eines Master-Ereignisses: Beim Lesen des Binlogs der Hauptbibliothek ist ein Fehler aufgetreten (aufgrund einer Verbindungsunterbrechung). Bevor der E/A-Thread versucht, die Verbindung zur Hauptbibliothek wiederherzustellen, schläft der Thread für die Anzahl von Sekunden, die durch die Option MASTER_CONNECT_RETRY (Standard ist 60) der CHANGE MASTER TO-Anweisung festgelegt wurde (diese Zeit ist das Wiederholungsintervall nach einer fehlgeschlagenen erneuten Verbindung). )
  • 6. SQL-Thread-Status
  • Slave töten: Der Thread verarbeitet die STOP SLAVE-Anweisung.
  • Erstellen einer temporären Datei (anhängen) vor der Wiedergabe von LOAD DATA INFILE: Der Thread führt die LOAD DATA INFILE-Anweisung aus und fügt die aus der Bibliothek zu lesenden Daten der temporären Datei hinzu
  • Temporäre Datei erstellen (erstellen) vor der Wiedergabe von LOAD DATA INFILE: Der Thread führt die LOAD DATA INFILE-Anweisung aus und erstellt eine temporäre Datei. Die temporäre Datei enthält die Zeilendaten, die aus der Bibliothek gelesen werden sollen. Hinweis: Dieser Zustand kann nur auftreten, wenn die Hauptbibliothek die ursprüngliche LOAD DATA INFILE-Anweisung in Versionen vor MySQL 5.0.3 aufzeichnet
  • Ereignis aus dem Relay-Protokoll lesen: Der Thread liest Ereignisse aus dem Relay-Protokoll zur Verarbeitung von Replay
  • Slave hat das gesamte Relay-Protokoll gelesen; wartet auf weitere Aktualisierungen: Der Thread hat alle Ereignisse in allen Relay-Protokolldateien wiederholt und wartet darauf, dass der E/A-Thread neue Ereignisse in das Relay-Protokoll schreibt. Warten auf ein Ereignis vom Koordinator: Wann Die Slave-Bibliothek verwendet Multithread-Replikation (slave_parallel_workers ist größer als 1). Dieser Status zeigt an, dass ein Slave-Arbeitsthread darauf wartet, dass der Koordinator-Thread (Koordinator-Thread) Protokollereignisse verteilt. Warten auf Slave-Mutex beim Beenden: Der Thread stoppt Ein sehr kurzlebiger Zustand, der auftritt, wenn
  • Warten darauf, dass Slave-Worker ausstehende Ereignisse freigeben: Wenn die Gesamtzahl der vom Workers-Thread verarbeiteten Ereignisse die Größe der Systemvariablen „slave_pending_jobs_size_max“ überschreitet, findet ein Wartevorgang statt (der Koordinator-Thread nicht). Ereignisse dem Worker-Thread zuweisen). Der Koordinator nimmt die Planung wieder auf, wenn die Gesamtzahl der von Workers-Threads verarbeiteten Ereignisse unter den Grenzwert „slave_pending_jobs_size_max“ fällt. Dieser Zustand tritt nur auf, wenn „slave_parallel_workers“ auf größer als 0 gesetzt ist.
  • Warten auf das nächste Ereignis im Relay-Protokoll: Anfangszustand vor dem Status „Ereignis aus dem Relay-Protokoll lesen“.
  • Warten bis MASTER_DELAY Sekunden nach dem vom Master ausgeführten Ereignis: SQL Der Thread hat Das Ereignis wurde gelesen, aber nicht angewendet. Stattdessen wird darauf gewartet, dass die von der Slave-Bibliothek festgelegte verzögerte Kopierzeit abläuft. Diese Verzögerungszeit wird mit der Option MASTER_DELAY von CHANGE MASTER TO
  ⚫ eingestellt. In der Info-Spalte des SQL-Threads kann auch der Text der Anweisung angezeigt werden. Dies bedeutet, dass der Thread ein Ereignis aus dem Relay-Protokoll gelesen, die SQL-Anweisung daraus extrahiert hat und derzeit möglicherweise das dieser Anweisung entsprechende Ereignis ausführt. 7. Thread-Status der Master-Slave-Verbindung tritt auf, wenn die Master-Bibliothek nach der Dump-Tabelle erstellt wird
  • Daten der Master-Dump-Tabelle lesen: Der Status, der nach dem Status „Master-Dump-Tabelle wird geöffnet“ angezeigt wird, zeigt an, dass Daten aus der Dump-Tabelle der Hauptdatenbank gelesen werden
  • 
    Neuerstellung des Indexes am Master-Dump-Tabelle: „Daten der Master-Dump-Tabelle werden gelesen“ Der Status, der nach dem Status angezeigt wird, zeigt an, dass der Hauptbibliotheks-Dump-Tabellenindex neu erstellt wird

  8. Ereignisplanungs-Thread-Status

  • Löschen: Der Scheduler-Thread wird gestoppt um Ereignisse auszuführen
  • Initialisiert: Der Scheduler-Thread wurde initialisiert und wird ausgeführt. Ereignisse planen
  • Warten auf die nächste Aktivierung: Wenn der Scheduler eine nicht leere Ereigniswarteschlange hat, wartet er darauf, dass ein Ereignis in der Aktivierungswarteschlange geplant wird und irgendwann in der Zukunft ausgeführt.
  • Warten, bis der Scheduler stoppt: Der Thread gibt SET GLOBAL event_scheduler = OFF aus und wartet, bis der Scheduler stoppt.
  • Warten auf leere Warteschlange: Die Ereigniswarteschlange des Schedulers ist leer, also auch der Scheduler Schlafen

  Verwandte kostenlose Lernempfehlungen:

  • MySQL-Datenbank
  • (Video)

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des MySQL-Thread-Status. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!