Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

synch/cond/sql/MDL_konteks:: COND _wait_status

Peristiwa synch/cond/sql/MDL_context::COND_wait_status terjadi saat terdapat thread yang menunggu pada kunci metadata tabel.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:

Konteks

Peristiwa synch/cond/sql/MDL_context::COND_wait_status menunjukkan bahwa terdapat thread yang menunggu pada kunci metadata tabel. Dalam kasus tertentu, satu sesi mempertahankan kunci metadata pada tabel, sementara sesi lainnya mencoba mendapatkan kunci yang sama pada tabel yang sama. Jika demikian, sesi kedua akan menunggu pada peristiwa tunggu synch/cond/sql/MDL_context::COND_wait_status.

Saya SQL menggunakan penguncian metadata untuk mengelola akses bersamaan ke objek database dan untuk memastikan konsistensi data. Penguncian metadata berlaku untuk tabel, skema, acara terjadwal, tablespace, dan penguncian pengguna yang diperoleh dengan fungsi get_lock, serta program yang disimpan. Program yang disimpan mencakup prosedur, fungsi, dan pemicu. Untuk informasi selengkapnya, lihat Penguncian metadata di dokumentasi SayaSQL.

Daftar SQL proses saya menunjukkan sesi ini di negara bagianwaiting for metadata lock. Dalam Wawasan Performa, jika Performance_schema diaktifkan, maka peristiwa synch/cond/sql/MDL_context::COND_wait_status akan muncul.

Batas waktu default untuk kueri yang menunggu pada penguncian metadata didasarkan pada nilai parameter lock_wait_timeout, dengan nilai default 31.536.000 detik (365 hari).

Untuk detail selengkapnya tentang berbagai kunci InnoDB dan jenis kunci yang dapat menyebabkan konflik, lihat Penguncian InnoDB di dokumentasi Saya. SQL

Kemungkinan penyebab peningkatan peristiwa tunggu

Saat peristiwa synch/cond/sql/MDL_context::COND_wait_status muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:

Tindakan

Kami merekomendasikan tindakan yang berbeda tergantung pada penyebab acara tunggu Anda dan pada versi cluster Aurora My SQL DB.

Mengidentifikasi sesi dan kueri penyebab peristiwa

Anda dapat menggunakan Wawasan Performa untuk menampilkan kueri yang diblokir oleh peristiwa tunggu synch/cond/sql/MDL_context::COND_wait_status. Namun, untuk mengidentifikasi sesi pemblokiran, buat kueri tabel metadata dari performance_schema dan information_schema di klaster DB.

Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.

Untuk ikhtisar berguna tentang pemecahan masalah menggunakan Performance Insights, lihat posting Blog Database Menganalisis AWS Beban Kerja SQL Saya Amazon Aurora dengan Performance Insights.

Memeriksa peristiwa masa lalu

Anda dapat memperoleh wawasan tentang peristiwa tunggu ini untuk memeriksa peristiwa di masa lalu. Untuk melakukannya, selesaikan tindakan berikut:

Informasi yang tersedia untuk memecahkan masalah peristiwa masa lalu terbatas. Melakukan pemeriksaan ini tidak menunjukkan objek yang menunggu informasi. Namun, Anda dapat mengidentifikasi tabel dengan beban berat saat peristiwa terjadi dan kumpulan baris yang sering dioperasikan yang menyebabkan konflik pada saat masalah terjadi. Anda kemudian dapat menggunakan informasi ini untuk mereproduksi masalah di lingkungan pengujian dan memberikan wawasan tentang penyebabnya.

Jalankan kueri di Aurora Versi saya 2 SQL

Di Aurora My SQL versi 2, Anda dapat mengidentifikasi sesi yang diblokir secara langsung dengan menanyakan performance_schema tabel atau sys tampilan skema. Sebuah contoh dapat mengilustrasikan cara membuat kueri tabel untuk mengidentifikasi kueri dan sesi pemblokiran.

Dalam output daftar proses berikut, ID koneksi 89 sedang menunggu pada kunci metadata, dan menjalankan perintah TRUNCATE TABLE. Dalam kueri pada tabel performance_schema atau tampilan skema sys, output menunjukkan bahwa sesi pemblokiran adalah 76.

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)

Selanjutnya, sebuah kueri pada tabel performance_schema atau tampilan skema sys menunjukkan bahwa sesi pemblokiran adalah 76.

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)

Merespons sesi pemblokiran

Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:

Untuk informasi selengkapnya tentang mengidentifikasi transaksi pemblokiran, lihat Menggunakan Transaksi InnoDB dan Mengunci Informasi dalam dokumentasi SayaSQL.