Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
synch/cond/sql/MDL_context::COND_wait_status
Dieses synch/cond/sql/MDL_context::COND_wait_status-Ereignis tritt ein, wenn Threads auf eine Tabellenmetadatensperre warten.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
-
Aurora-MySQL-Versionen 2 und 3
Kontext
Das synch/cond/sql/MDL_context::COND_wait_status-Ereignis zeigt an, dass Threads auf eine Tabellenmetadatensperre warten. In einigen Fällen hält eine Sitzung eine Metadatensperre für eine Tabelle und eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erhalten. In einem solchen Fall wartet die zweite Sitzung auf das synch/cond/sql/MDL_context::COND_wait_status-Warteereignis.
MySQL verwendet die Sperre von Metadaten, um den gleichzeitigen Zugriff auf Datenbankobjekte zu verwalten und die Datenkonsistenz sicherzustellen. Das Sperren von Metadaten gilt für Tabellen, Schemata, geplante Ereignisse, Tablespaces und Benutzersperren, die mit der get_lock-Funktion erworben wurden, und gespeicherte Programme. Gespeicherte Programme umfassen Prozeduren, Funktionen und Auslöser. Weitere Informationen finden Sie unter Metadata Locking
Die MySQL-Prozessliste zeigt diese Sitzung im Zustand waiting for metadata
lock. Wenn in Performance Insights Performance_schema aktiviert ist, wird das Ereignis synch/cond/sql/MDL_context::COND_wait_status angezeigt.
Das Standardtimeout für eine Abfrage, die auf eine Metadatensperre wartet, basiert auf dem Wert des lock_wait_timeout-Parameters, der standardmäßig 31.536.000 Sekunden (365 Tage) beträgt.
Weitere Informationen zu verschiedenen InnoDB-Sperren und den Arten von Sperren, die Konflikte verursachen können, finden Sie unter InnoDB-Sperren
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das synch/cond/sql/MDL_context::COND_wait_status-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
- Langlebige Transaktionen
-
Eine oder mehrere Transaktionen ändern eine große Datenmenge und halten Tabellen für eine sehr lange Zeit gesperrt.
- Leerlauf-Transaktionen
-
Eine oder mehrere Transaktionen bleiben lange offen, ohne festgeschrieben oder rückgängig gemacht zu werden.
- DDL-Anweisungen zu großen Tabellen
-
Für sehr große Tabellen wurden eine oder mehrere DDL-Anweisungen (Data Definition Statements) ausgeführt, z. B.
ALTER TABLE-Befehle. - Explizite Tabellensperren
-
Es gibt explizite Sperren für Tabellen, die nicht zeitnah freigegeben werden. Beispielsweise kann eine Anwendung
LOCK TABLE-Anweisungen nicht ordnungsgemäß ausführen.
Aktionen
Wir empfehlen verschiedene Aktionen, abhängig von den Ursachen Ihres Warteereignisses und von der Version des Aurora-MySQL-DB-Clusters.
Themen
Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Sie können Performance Insights verwenden, um Abfragen anzuzeigen, die durch das synch/cond/sql/MDL_context::COND_wait_status-Warteereignis gesperrt wurden Um jedoch die blockierende Sitzung zu identifizieren, fragen Sie Metadatentabellen von performance_schema und information_schema im DB-Cluster ab.
Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Performance-Insights aus.
-
Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
-
Wählen Sie im Diagramm zur Datenbanklast die Option Nach Wartezeit aufteilen.
-
Wählen Sie unten auf der Seite Top-SQL aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im AWS-Database Blog-Beitrag Analysieren von Amazon-Aurora-MySQL-Workloads mit Performance Insights
Nach vergangenen Ereignissen suchen
Sie können einen Einblick in dieses Warteereignis erhalten, um nach früheren Vorkommen zu suchen. Führen Sie dazu die folgenden Aktionen aus:
-
Überprüfen Sie die Datenmanipulationssprache (DML) und den DDL-Durchsatz und die Latenz, um festzustellen, ob sich die Workload geändert hat.
Sie können Performance Insights verwenden, um Abfragen zu finden, die zum Zeitpunkt des Problems auf dieses Ereignis warten. Sie können auch den Digest der Abfragen anzeigen, die nahe dem Zeitpunkt des Problems ausgeführt werden.
-
Wenn Überwachungsprotokolle oder allgemeine Protokolle für den DB-Cluster aktiviert sind, können Sie nach allen Abfragen suchen, die für die Objekte (schema.table) ausgeführt werden, die an der Wartetransaktion beteiligt sind. Sie können auch nach den Abfragen suchen, die vor der Transaktion ausgeführt wurden.
Die Informationen, die zur Fehlerbehebung vergangener Ereignisse zur Verfügung stehen, sind begrenzt. Durch das Ausführen dieser Prüfungen wird nicht angezeigt, welches Objekt auf Informationen wartet. Sie können jedoch Tabellen mit hoher Last zum Zeitpunkt des Ereignisses und die Menge häufig operierter Zeilen identifizieren, die zum Zeitpunkt des Problems Konflikte verursachen. Sie können diese Informationen dann verwenden, um das Problem in einer Testumgebung zu reproduzieren und Einblicke in seine Ursache zu geben.
Führen Sie Anfragen für Aurora MySQL Version 2 aus
In Aurora MySQL Version 2 können Sie die blockierte Sitzung direkt identifizieren, indem Sie performance_schema-Tabellen oder sys-Schemaansichten abfragen. Ein Beispiel kann veranschaulichen, wie Tabellen abfragen, um blockierende Abfragen und Sitzungen zu identifizieren.
In der folgenden Prozesslistenausgabe wartet die Verbindungs-ID 89 auf eine Metadatensperre und führt einen TRUNCATE TABLE-Befehl aus. In einer Abfrage der performance_schema-Tabellen oder sys-Schemaansichten zeigt die Ausgabe, dass die blockierende Sitzung 76 ist.
MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.09.0 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec)
Als Nächstes zeigt eine Abfrage der performance_schema-Tabellen oder sys-Schemaansichten, dass die blockierende Sitzung 76 ist.
MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec)
Antworten Sie auf die Blockiersitzung
Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:
-
Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.
-
Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter Beenden einer Sitzung oder Abfrage.
Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter Verwenden von InnoDB-Transaktions- und Sperrinformationen
