Lock:Relation - Amazon Aurora
Versi mesin yang didukungKonteksKemungkinan penyebab peningkatan peristiwa tungguTindakan

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

Lock:Relation

Peristiwa Lock:Relation terjadi saat kueri menunggu untuk memperoleh kunci pada tabel atau tampilan (relasi) yang saat ini dikunci oleh transaksi lain.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.

Konteks

Sebagian besar perintah PostgreSQL secara implisit menggunakan kunci untuk mengontrol akses konkuren ke data dalam tabel. Anda juga dapat menggunakan kunci ini secara eksplisit dalam kode aplikasi Anda dengan perintah LOCK. Banyak mode kunci yang tidak kompatibel satu sama lain, dan mode ini dapat memblokir transaksi saat mencoba mengakses objek yang sama. Apabila hal ini terjadi, Aurora PostgreSQL membuat peristiwa Lock:Relation. Berikut adalah beberapa contoh umum:

  • Kunci eksklusif seperti ACCESS EXCLUSIVE dapat memblokir semua akses konkuren. Operasi bahasa definisi data (DDL) seperti DROP TABLE, TRUNCATE, VACUUM FULL, dan CLUSTER memperoleh kunci ACCESS EXCLUSIVE secara implisit. ACCESS EXCLUSIVE juga merupakan mode kunci default untuk pernyataan LOCK TABLE yang tidak menentukan mode secara eksplisit.

  • Menggunakan CREATE INDEX (without CONCURRENT) pada tabel akan bertentangan dengan pernyataan bahasa manipulasi data (DML) UPDATE, DELETE, dan INSERT, yang memperoleh kunci ROW EXCLUSIVE.

Untuk informasi selengkapnya tentang kunci tingkat tabel dan mode kunci yang bertentangan, lihat Explicit Locking dalam dokumentasi PostgreSQL.

Kueri dan transaksi yang memblokir biasanya dapat dibuka blokirnya dengan salah satu cara berikut:

  • Kueri yang memblokir – Aplikasi dapat membatalkan kueri atau pengguna dapat mengakhiri proses. Mesin juga dapat memaksa kueri untuk berakhir karena batas waktu pernyataan sesi atau mekanisme deteksi deadlock.

  • Transaksi yang memblokir – Transaksi berhenti memblokir saat menjalankan pernyataan ROLLBACK atau COMMIT. Rollback juga terjadi secara otomatis saat sesi diputus oleh klien atau masalah jaringan, atau diakhiri. Sesi dapat berakhir saat mesin basis data dimatikan, sistem kehabisan memori, dan sebagainya.

Kemungkinan penyebab peningkatan peristiwa tunggu

Saat peristiwa Lock:Relation terjadi lebih sering dari biasanya, hal tersebut dapat menunjukkan masalah performa. Penyebab umumnya meliputi yang berikut:

Peningkatan sesi konkuren dengan kunci tabel yang bertentangan

Mungkin ada peningkatan jumlah sesi konkuren dengan kueri yang mengunci tabel yang sama dengan mode kunci yang bertentangan.

Operasi pemeliharaan

Operasi pemeliharaan kondisi seperti VACUUM dan ANALYZE dapat secara signifikan meningkatkan jumlah kunci yang bertentangan. VACUUM FULL memperoleh kunci ACCESS EXCLUSIVE, dan ANALYZE memperoleh kunci SHARE UPDATE EXCLUSIVE. Kedua jenis kunci tersebut dapat menyebabkan peristiwa tunggu Lock:Relation. Operasi pemeliharaan data aplikasi seperti menyegarkan tampilan terwujud juga dapat meningkatkan kueri dan transaksi yang diblokir.

Kunci pada instans pembaca

Mungkin ada pertentangan antara kunci relasi yang dipegang oleh penulis dan pembaca. Saat ini, hanya kunci relasi ACCESS EXCLUSIVE yang direplikasi ke instans pembaca. Namun, kunci relasi ACCESS EXCLUSIVE akan bertentangan dengan kunci relasi ACCESS SHARE yang dipegang oleh pembaca. Hal ini dapat menyebabkan peningkatan peristiwa tunggu relasi kunci pada pembaca.

Tindakan

Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.

Kurangi dampak pemblokiran pernyataan SQL

Untuk mengurangi dampak pemblokiran pernyataan SQL, ubah kode aplikasi Anda jika memungkinkan. Berikut adalah dua teknik umum untuk mengurangi pemblokiran:

  • Gunakan opsi NOWAIT – Beberapa perintah SQL, seperti pernyataan SELECT dan LOCK, mendukung opsi ini. Arahan NOWAIT membatalkan kueri permintaan kunci jika kunci tidak dapat segera diperoleh. Teknik ini dapat membantu mencegah sesi yang memblokir menyebabkan penumpukan sesi yang diblokir di belakangnya.

    Misalnya: Transaksi A sedang menunggu kunci yang dipegang oleh transaksi B. Jika B meminta kunci pada tabel yang dikunci oleh transaksi C, transaksi A mungkin diblokir hingga transaksi C selesai. Namun, jika transaksi B menggunakan NOWAIT saat meminta kunci pada C, transaksi ini dapat gagal cepat (fail fast) dan memastikan bahwa transaksi A tidak harus menunggu tanpa batas waktu.

  • Gunakan SET lock_timeout – Tetapkan nilai lock_timeout untuk membatasi waktu tunggu pernyataan SQL dalam memperoleh kunci pada relasi. Jika kunci tidak diperoleh dalam batas waktu yang ditentukan, transaksi yang meminta kunci dibatalkan. Tetapkan nilai ini pada tingkat sesi.

Minimalkan efek operasi pemeliharaan

Operasi pemeliharaan seperti VACUUM dan ANALYZE bersifat penting. Sebaiknya jangan dinonaktifkan karena peristiwa tunggu Lock:Relation berkaitan dengan operasi pemeliharaan ini. Pendekatan berikut dapat meminimalkan efek operasi ini:

  • Jalankan operasi pemeliharaan secara manual di luar jam sibuk.

  • Untuk mengurangi peristiwa tunggu Lock:Relation yang disebabkan oleh tugas autovacuum, lakukan penyetelan autovacuum yang diperlukan. Untuk informasi tentang menyetel autovacuum, lihat Bekerja dengan autovacuum PostgreSQL di Amazon RDS pada Panduan Pengguna Amazon RDS.

Periksa kunci pembaca

Anda dapat melihat bagaimana sesi bersamaan pada kunci yang mungkin dipegang oleh penulis dan pembaca yang memblokir satu sama lain. Salah satu cara untuk melakukannya adalah dengan menjalankan kueri yang mengembalikan jenis kunci dan relasi. Dalam tabel, Anda dapat menemukan urutan kueri untuk dua sesi bersamaan seperti itu, sesi penulis dan sesi pembaca.

Proses pemutaran ulang menunggu durasi max_standby_streaming_delay sebelum membatalkan kueri pembaca. Seperti yang ditunjukkan pada contoh, batas waktu kunci 100 md jauh di bawah default max_standby_streaming_delay 30 detik. Waktu kunci habis sebelum menjadi masalah.

Acara urutan Sesi Perintah atau Output

Menetapkan variabel lingkungan yang disebut READER dengan nilai yang ditentukan dan mencoba untuk terhubung ke instance DB dengan endpoint ini.

Sesi pembaca

Perintah CLI:

export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Output:

psql (15devel, server 10.14)
Type "help" for help.

Menetapkan variabel lingkungan yang disebut WRITER dan mencoba untuk terhubung ke instance DB dengan endpoint ini.

Sesi penulis

Perintah CLI:

export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Output:

psql (15devel, server 10.14) 
Type "help" for help.

Sesi penulis membuat tabel t1 pada instance penulis.

Sesi penulis

Kueri PostgreSQL:

postgres=> CREATE TABLE t1(b integer);
CREATE TABLE

Jika tidak ada pertanyaan yang bertentangan pada penulis, kunci ACCESS EXCLUSIVE diperoleh pada penulis segera.

Sesi penulis

ACCESS EXCLUSIVEkunci diaktifkan

Sesi pembaca menetapkan interval batas waktu kunci 100 milidetik.

Sesi pembaca

Kueri PostgreSQL:

postgres=> SET lock_timeout=100;
SET

Sesi pembaca mencoba membaca data dari tabel t1 pada instance pembaca.

Sesi pembaca

Kueri PostgreSQL:

postgres=> SELECT * FROM t1;

Contoh output:

b
---
(0 rows)

Sesi penulis turun t1.

Sesi penulis

Kueri PostgreSQL:

postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>

Waktu kueri habis dan dibatalkan pada pembaca.

Sesi pembaca

Kueri PostgreSQL:

postgres=> SELECT * FROM t1;

Contoh output:

ERROR:  canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
                      ^

Untuk menentukan penyebab kesalahan. kueri sesi pembaca dan pg_locks pg_stat_activity

Sesi pembaca

Kueri PostgreSQL:

postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;

Hasilnya menunjukkan bahwa aurora wal replay proses memegang ACCESS EXCLUSIVE kunci pada tabel t1.

Sesi pembaca

Hasil kueri:

 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)