Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
synch/cond/sql/MDL_context::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:
-
Aurora MySQL versi 2 dan 3
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.
MySQL menggunakan penguncian metadata untuk mengelola akses bersamaan ke objek basis data dan 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
Daftar proses MySQL menunjukkan sesi ini dalam status waiting 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
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:
- Transaksi yang berjalan lama
-
Satu atau lebih transaksi mengubah data dalam jumlah besar data dan menahan kunci pada tabel untuk waktu yang sangat lama.
- Transaksi idle
-
Satu atau lebih transaksi tetap terbuka untuk waktu yang lama, tanpa di-commit atau di-roll back.
- Pernyataan DDL pada tabel besar
-
Satu atau lebih pernyataan definisi data (DDL), seperti perintah
ALTER TABLE, dijalankan pada tabel yang sangat besar. - Kunci tabel eksplisit
-
Terdapat kunci eksplisit pada tabel yang tidak dirilis tepat waktu. Misalnya, sebuah aplikasi mungkin menjalankan pernyataan
LOCK TABLEsecara salah.
Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda dan versi klaster DB Aurora MySQL.
Topik
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 menemukan kueri SQL yang bertanggung jawab atas beban tinggi:
Masuk ke AWS Management Console, lalu buka konsol Amazon RDS di https://console.aws.amazon.com/rds/
. -
Di panel navigasi, pilih Wawasan Performa.
-
Pilih instans DB. Dasbor Wawasan Performa untuk instans DB tersebut akan muncul.
-
Dalam bagan Beban basis data, pilih Potong berdasarkan masa tunggu.
-
Di bagian bawah halaman, pilih SQL Teratas.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan Blog Basis Data AWS, Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa
Memeriksa peristiwa masa lalu
Anda dapat memperoleh wawasan tentang peristiwa tunggu ini untuk memeriksa kejadian di masa lalu. Untuk melakukannya, selesaikan tindakan berikut:
-
Periksa bahasa manipulasi data (DML) dan throughput serta latensi DDL untuk mengetahui apakah terdapat perubahan pada beban kerja.
Anda dapat menggunakan Wawasan Performa untuk menemukan kueri yang menunggu pada peristiwa ini saat masalah terjadi. Anda juga dapat melihat inti sari kueri yang berjalan menjelang waktu masalah terjadi.
-
Jika log audit atau log umum diaktifkan untuk klaster DB, Anda dapat memeriksa semua kueri yang berjalan pada objek (schema.table) yang terlibat dalam transaksi tunggu. Anda juga dapat memeriksa kueri yang selesai berjalan sebelum transaksi.
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.
Menjalankan kueri pada Aurora MySQL versi 2
Di Aurora MySQL versi 2, Anda dapat mengidentifikasi sesi yang diblokir secara langsung dengan membuat kueri tabel performance_schema atau tampilan skema sys. 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.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)
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:
-
Menghubungi pemilik aplikasi atau pengguna.
-
Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat Mengakhiri sesi atau kueri.
Untuk informasi selengkapnya tentang cara mengidentifikasi transaksi pemblokiran, lihat Menggunakan Transaksi InnoDB dan Informasi Penguncian
