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\$1context: :cond\$1wait\$1status Dieses `synch/cond/sql/MDL_context::COND_wait_status`-Ereignis tritt ein, wenn Threads auf eine Tabellenmetadatensperre warten. **Topics** + [Unterstützte Engine-Versionen](#ams-waits.cond-wait-status.context.supported) + [Kontext](#ams-waits.cond-wait-status.context) + [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.cond-wait-status.causes) + [Aktionen](#ams-waits.cond-wait-status.actions) ## 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](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) in der MySQL-Dokumentation. 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) in der MySQL-Dokumentation. ## 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. **Topics** + [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.cond-wait-status.actions.identify) + [Nach vergangenen Ereignissen suchen](#ams-waits.cond-wait-status.actions.past-events) + [Führen Sie Anfragen für Aurora MySQL Version 2 aus](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57) + [Antworten Sie auf die Blockiersitzung](#ams-waits.cond-wait-status.actions.blocker) ### 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** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich **Performance-Insights** aus. 1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt. 1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**. 1. 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. Einen nützlichen Überblick über die Fehlerbehebung mit Performance Insights finden Sie im AWS Datenbank-Blogbeitrag [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-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.11.5 | +-----------+------------------+ 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](mysql-stored-proc-ending.md). Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter [Verwenden von InnoDB-Transaktions- und Sperrinformationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) in der MySQL-Dokumentation.