Menggunakan replikasi multithreaded di Aurora MySQL Memanggil AWS Lambda fungsi menggunakan fungsi MySQL asli Menghindari transaksi XA dengan Amazon Aurora MySQL Mempertahankan kunci asing tetap aktif selama pernyataan DML Mengonfigurasi seberapa sering buffer log di-flush Meminimalkan dan memecahkan masalah deadlock Aurora MySQL

Rekomendasi untuk fitur MySQL di Aurora MySQL

Fitur-fitur berikut tersedia di Aurora MySQL untuk kompatibilitas MySQL. Namun, fitur-fitur ini memiliki masalah performa, skalabilitas, stabilitas, atau kompatibilitas di lingkungan Aurora. Oleh karena itu, kami menyarankan Anda mengikuti pedoman tertentu dalam penggunaan fitur-fitur ini. Misalnya, kami sarankan Anda tidak menggunakan fitur tertentu untuk deployment Aurora produksi.

Topik

Menggunakan replikasi multithreaded di Aurora MySQL
Memanggil AWS Lambda fungsi menggunakan fungsi MySQL asli
Menghindari transaksi XA dengan Amazon Aurora MySQL
Mempertahankan kunci asing tetap aktif selama pernyataan DML
Mengonfigurasi seberapa sering buffer log di-flush
Meminimalkan dan memecahkan masalah deadlock Aurora MySQL

Menggunakan replikasi multithreaded di Aurora MySQL

Dengan replikasi log biner multi-thread, thread SQL membaca peristiwa dari log relai dan mengantrekannya agar thread pekerja SQL dapat diterapkan. Thread pekerja SQL dikelola oleh thread koordinator. Peristiwa log biner diterapkan secara paralel jika memungkinkan.

Replikasi multithreaded didukung di Aurora MySQL versi 3, dan di Aurora MySQL versi 2.12.1 dan lebih tinggi.

Untuk versi MySQL Aurora yang lebih rendah dari 3,04, Aurora menggunakan replikasi single-threaded secara default ketika cluster DB MySQL Aurora digunakan sebagai replika baca untuk replikasi log biner.

Versi sebelumnya dari Aurora MySQL versi 2 mewarisi beberapa masalah mengenai replikasi multithreaded dari MySQL Community Edition. Untuk versi tersebut, kami menyarankan Anda untuk tidak menggunakan replikasi multithreaded dalam produksi.

Jika Anda menggunakan replikasi multithreaded, kami sarankan Anda mengujinya secara menyeluruh.

Untuk informasi selengkapnya tentang replikasi di Amazon Aurora, lihat Replikasi dengan Amazon Aurora. Untuk informasi selengkapnya tentang replikasi multithreaded di Aurora MySQL, lihat. Replikasi log biner multithreaded

Memanggil AWS Lambda fungsi menggunakan fungsi MySQL asli

Sebaiknya gunakan fungsi MySQL native lambda_sync dan lambda_async untuk menginvokasi fungsi Lambda.

Jika Anda menggunakan prosedur mysql.lambda_async yang sudah dihentikan, kami sarankan agar Anda menggabungkan panggilan ke prosedur mysql.lambda_async dalam prosedur tersimpan. Anda dapat memanggil prosedur tersimpan ini dari berbagai sumber, seperti pemicu atau kode klien. Pendekatan ini dapat membantu menghindari masalah ketidakcocokan impedansi dan memudahkan pemrogram basis data Anda untuk menginvokasi fungsi Lambda.

Untuk informasi selengkapnya tentang menginvokasi fungsi Lambda dari Amazon Aurora, lihat Menginvokasi fungsi Lambda dari klaster DB Amazon Aurora MySQL.

Menghindari transaksi XA dengan Amazon Aurora MySQL

Sebaiknya jangan gunakan transaksi eXtended Architecture (XA) dengan Aurora MySQL karena dapat menyebabkan waktu pemulihan yang lama jika XA berada di status PREPARED. Jika Anda harus menggunakan transaksi XA dengan Aurora MySQL, ikuti praktik terbaik ini:

Jangan tinggalkan transaksi XA terbuka pada status PREPARED.
Pertahankan transaksi XA sekecil mungkin.

Untuk informasi selengkapnya tentang menggunakan transaksi XA dengan MySQL, lihat XA transactions dalam dokumentasi MySQL.

Mempertahankan kunci asing tetap aktif selama pernyataan DML

Kami sangat menyarankan agar Anda tidak menjalankan pernyataan bahasa definisi data (DDL) saat variabel foreign_key_checks diatur menjadi 0 (nonaktif).

Jika Anda perlu menyisipkan atau memperbarui baris yang memerlukan pelanggaran sementara terhadap kunci asing, ikuti langkah-langkah berikut:

Atur foreign_key_checks ke 0.
Membuat perubahan bahasa manipulasi data (DML).
Pastikan bahwa perubahan yang telah Anda selesaikan tidak melanggar batasan kunci asing.
Atur foreign_key_checks ke 1 (aktif).

Selain itu, ikuti praktik terbaik lainnya untuk batasan kunci asing:

Pastikan bahwa aplikasi klien tidak mengatur variabel foreign_key_checks ke 0 sebagai bagian dari variabel init_connect.
Jika pemulihan dari cadangan logis seperti mysqldump gagal atau tidak selesai, pastikan bahwa foreign_key_checks diatur ke 1 sebelum memulai operasi lain pada sesi yang sama. Cadangan logis mengatur foreign_key_checks ke 0 saat dimulai.

Mengonfigurasi seberapa sering buffer log di-flush

Di MySQL Community Edition, untuk membuat transaksi durabel, buffer log InnoDB harus di-flush ke penyimpanan yang durabel. Anda menggunakan parameter innodb_flush_log_at_trx_commit untuk mengonfigurasi seberapa sering buffer log di-flush ke disk.

Saat Anda mengatur parameter innodb_flush_log_at_trx_commit ke nilai default 1, buffer log akan di-flush pada setiap commit transaksi. Pengaturan ini membantu menjaga basis data memenuhi persyaratan ACID. Kami menyarankan Anda untuk tetap mempertahankan pengaturan default 1.

Mengubah innodb_flush_log_at_trx_commit ke nilai nondefault dapat membantu mengurangi latensi bahasa manipulasi data (DHTML), tetapi mengorbankan daya tahan catatan log. Kurangnya durabilitas ini membuat basis data tidak memenuhi persyaratan ACID. Kami menyarankan agar basis data Anda memenuhi persyaratan ACID untuk menghindari risiko data jika server diaktifkan ulang. Untuk informasi selengkapnya tentang parameter ini, lihat innodb_flush_log_at_trx_commit dalam dokumentasi MySQL.

Di Aurora MySQL, pemrosesan log redo dialihkan ke lapisan penyimpanan, jadi tidak ada flushing ke file log yang terjadi pada instans DB. Ketika sebuah penulisan dikeluarkan, log redo akan dikirim dari instans DB penulis langsung ke volume klaster Aurora. Satu-satunya penulisan yang melintasi jaringan adalah catatan log redo. Tidak ada halaman yang akan ditulis dari tingkat basis data.

Secara default, setiap thread yang melakukan transaksi menunggu konfirmasi dari volume cluster Aurora. Konfirmasi ini menunjukkan bahwa catatan ini dan semua catatan log redo sebelumnya telah ditulis dan mencapai kuorum. Mempersistensi catatan log dan mencapai kuorum akan membuat transaksi durabel, baik melalui commit otomatis maupun commit eksplisit. Untuk informasi selengkapnya tentang arsitektur penyimpanan Aurora, lihat Amazon Aurora storage demystified.

Aurora MySQL tidak mem-flush log ke file data seperti yang dilakukan MySQL Community Edition. Namun, Anda dapat menggunakan parameter innodb_flush_log_at_trx_commit untuk melonggarkan batasan durabilitas saat menulis catatan log redo ke volume klaster Aurora.

Untuk Aurora MySQL versi 2:

innodb_flush_log_at_trx_commit= 0 atau 2 — Database tidak menunggu konfirmasi bahwa catatan log ulang ditulis ke volume cluster Aurora.
innodb_flush_log_at_trx_commit= 1 — Database menunggu konfirmasi bahwa catatan redo log ditulis ke volume cluster Aurora.

Untuk Aurora MySQL versi 3:

innodb_flush_log_at_trx_commit= 0 — Database tidak menunggu konfirmasi bahwa catatan redo log ditulis ke volume cluster Aurora.
innodb_flush_log_at_trx_commit= 1 atau 2 — Database menunggu konfirmasi bahwa catatan log ulang ditulis ke volume cluster Aurora.

Oleh karena itu, untuk mendapatkan perilaku nondefault yang sama di Aurora MySQL versi 3 yang Anda lakukan dengan nilai yang disetel ke 0 atau 2 di Aurora MySQL versi 2, atur parameter ke 0.

Meskipun dapat menurunkan latensi DML ke klien, pengaturan ini juga dapat mengakibatkan kehilangan data jika terjadi failover atau pengaktifan ulang. Oleh karena itu, sebaiknya pertahankan parameter innodb_flush_log_at_trx_commit yang diatur ke nilai default 1.

Meskipun kehilangan data dapat terjadi di MySQL Community Edition dan Aurora MySQL, perilaku di setiap basis data berbeda karena arsitekturnya yang berbeda. Perbedaan arsitektur ini dapat menyebabkan berbagai tingkat kehilangan data. Untuk memastikan bahwa basis data Anda memenuhi persyaratan ACID, selalu atur innodb_flush_log_at_trx_commit ke 1.

catatan

Di Aurora MySQL versi 3, sebelum Anda dapat mengubah innodb_flush_log_at_trx_commit ke nilai selain 1, Anda harus terlebih dahulu mengubah nilai innodb_trx_commit_allow_data_loss menjadi 1. Dengan melakukannya, berarti Anda memahami adanya risiko kehilangan data.

Meminimalkan dan memecahkan masalah deadlock Aurora MySQL

Pengguna yang menjalankan beban kerja yang secara rutin mengalami pelanggaran batasan pada indeks sekunder unik atau kunci asing, saat memodifikasi catatan pada halaman data yang sama secara konkuren, mungkin akan lebih sering mengalami deadlock dan kehabisan waktu tunggu kunci. Deadlock dan kehabisan waktu ini disebabkan oleh perbaikan bug MySQL Community Edition.

Perbaikan ini disertakan dalam MySQL Community Edition versi 5.7.26 dan lebih tinggi, serta di-backport ke Aurora MySQL versi 2.10.3 dan yang lebih tinggi. Perbaikan ini diperlukan untuk memberlakukan kemampuan serialisasi, dengan menerapkan penguncian tambahan untuk jenis operasi bahasa manipulasi data (DML) ini, pada perubahan yang dibuat terhadap catatan dalam tabel InnoDB. Masalah ini terungkap sebagai bagian dari penyelidikan masalah deadlock yang ditimbulkan oleh perbaikan bug MySQL Community Edition sebelumnya.

Perbaikan ini mengubah penanganan internal untuk rollback sebagian pembaruan tuple (baris) di mesin penyimpanan InnoDB. Operasi yang menghasilkan pelanggaran batasan pada kunci asing atau indeks sekunder unik menyebabkan rollback sebagian. Ini termasuk, tetapi tidak terbatas pada, pernyataan INSERT...ON DUPLICATE KEY UPDATE, REPLACE INTO, dan INSERT IGNORE konkuren (upsert).

Dalam konteks ini, rollback sebagian tidak mengacu pada rollback transaksi tingkat aplikasi, melainkan rollback InnoDB internal terhadap perubahan ke indeks berklaster ketika pelanggaran batasan ditemui. Misalnya, nilai kunci duplikat ditemukan selama operasi upsert.

Dalam operasi penyisipan normal, InnoDB secara atomis membuat entri indeks berklaster dan sekunder untuk setiap indeks. Jika InnoDB mendeteksi nilai duplikat pada indeks sekunder unik selama operasi upsert, entri yang disisipkan dalam indeks berklaster harus dikembalikan (rollback sebagian), dan pembaruan kemudian harus diterapkan ke baris duplikat yang ada. Selama langkah rollback sebagian internal ini, InnoDB harus mengunci setiap catatan yang dilihat sebagai bagian dari operasi. Perbaikan ini memastikan kemampuan serialisasi transaksi dengan menerapkan penguncian tambahan setelah rollback sebagian.

Meminimalkan deadlock InnoDB

Anda dapat mengambil pendekatan berikut untuk mengurangi frekuensi deadlock dalam instans basis data Anda. Contoh lainnya dapat ditemukan dalam dokumentasi MySQL.

Untuk mengurangi kemungkinan deadlock, lakukan transaksi segera setelah melakukan serangkaian perubahan terkait. Anda dapat melakukannya dengan memecah transaksi besar (beberapa pembaruan baris di antara commit) menjadi lebih kecil. Jika Anda memasukkan baris secara batch, cobalah untuk mengurangi ukuran penyisipan batch, terutama saat menggunakan operasi upsert yang disebutkan sebelumnya.

Untuk mengurangi jumlah kemungkinan rollback sebagian, Anda dapat mencoba beberapa pendekatan berikut:
1. Ganti operasi penyisipan batch dengan memasukkan satu baris pada satu waktu. Hal ini dapat mengurangi jumlah waktu saat kunci ditahan oleh transaksi yang mungkin memiliki konflik.
2. Alih-alih menggunakan REPLACE INTO, tulis ulang pernyataan SQL sebagai transaksi multipernyataan seperti berikut ini:
```
BEGIN;
DELETE conflicting rows;
INSERT new rows;
COMMIT;
```
3. Alih-alih menggunakan INSERT...ON DUPLICATE KEY UPDATE, tulis ulang pernyataan SQL sebagai transaksi multipernyataan seperti berikut ini:
```
BEGIN;
SELECT rows that conflict on secondary indexes;
UPDATE conflicting rows;
INSERT new rows;
COMMIT;
```
Hindari transaksi yang berjalan lama, aktif atau idle, yang mungkin menahan kunci. Hal ini termasuk sesi klien MySQL interaktif yang mungkin terbuka untuk waktu yang lama dengan transaksi yang tidak di-commit. Saat mengoptimalkan ukuran transaksi atau ukuran batch, dampaknya dapat bervariasi tergantung pada sejumlah faktor seperti konkurensi, jumlah duplikat, dan struktur tabel. Setiap perubahan harus diterapkan dan diuji berdasarkan beban kerja Anda.
Dalam beberapa situasi, deadlock dapat terjadi ketika dua transaksi mencoba mengakses set data yang sama, baik dalam satu maupun beberapa tabel, dalam urutan yang berbeda-beda. Untuk mencegah hal ini, Anda dapat memodifikasi transaksi untuk mengakses data dalam urutan yang sama, sehingga menserialisasi akses. Misalnya, buat antrean transaksi yang akan diselesaikan. Pendekatan ini dapat membantu menghindari deadlock ketika beberapa transaksi terjadi secara bersamaan.
Menambahkan indeks yang dipilih dengan cermat ke tabel Anda dapat meningkatkan selektivitas dan mengurangi kebutuhan untuk mengakses baris, sehingga mengurangi penguncian.
Jika Anda mengalami penguncian celah, Anda dapat memodifikasi tingkat isolasi transaksi menjadi READ COMMITTED untuk sesi atau transaksi agar mencegahnya. Untuk informasi selengkapnya tentang tingkat isolasi InnoDB dan perilakunya, lihat Transaction isolation levels dalam dokumentasi MySQL.

catatan

Meskipun Anda dapat mengambil tindakan pencegahan untuk mengurangi kemungkinan deadlock terjadi, deadlock adalah perilaku basis data yang sudah diperkirakan dan tetap dapat terjadi. Aplikasi harus memiliki logika yang diperlukan untuk menangani deadlock ketika terjadi. Misalnya, terapkan logika percobaan ulang dan backing-off dalam aplikasi. Yang terbaik adalah mengatasi akar penyebab masalahnya, tetapi jika deadlock memang terjadi, aplikasi memiliki opsi untuk menunggu dan mencoba lagi.

Memantau deadlock InnoDB

Deadlock dapat terjadi di MySQL ketika transaksi aplikasi mencoba mengambil kunci tingkat tabel dan tingkat baris dengan cara yang menghasilkan peristiwa tunggu sirkular. Deadlock InnoDB yang sesekali tidak selalu menjadi masalah karena mesin penyimpanan InnoDB mendeteksi kondisi ini dengan segera dan melakukan rollback terhadap salah satu transaksi secara otomatis. Jika Anda sering mengalami deadlock, kami sarankan untuk meninjau dan memodifikasi aplikasi Anda untuk mengurangi masalah performa dan menghindari deadlock. Ketika deteksi deadlock diaktifkan (default), InnoDB secara otomatis mendeteksi deadlock transaksi dan melakukan rollback transaksi untuk mengatasi deadlock. InnoDB mencoba memilih transaksi kecil untuk di-rollback. Ukuran transaksi akan ditentukan berdasarkan jumlah baris yang disisipkan, diperbarui, atau dihapus.

Pernyataan SHOW ENGINE – Pernyataan SHOW ENGINE INNODB STATUS \G berisi detail deadlock terbaru yang ditemui pada basis data sejak pengaktifan ulang terakhir.
Log kesalahan MySQL – Jika Anda sering mengalami deadlock dengan output pernyataan SHOW ENGINE yang tidak memadai, Anda dapat mengaktifkan parameter klaster DB innodb_print_all_deadlocks.

Ketika parameter ini diaktifkan, informasi tentang semua deadlock dalam transaksi pengguna InnoDB dicatat dalam log kesalahan Aurora MySQL.
CloudWatch Metrik Amazon — Kami juga menyarankan Anda memantau kebuntuan secara proaktif menggunakan metrik. CloudWatch Deadlocks Untuk informasi selengkapnya, lihat Metrik tingkat instans untuk Amazon Aurora.
CloudWatch Log Amazon — Dengan CloudWatch Log, Anda dapat melihat metrik, menganalisis data log, dan membuat alarm waktu nyata. Untuk informasi selengkapnya, lihat Memantau kesalahan di Amazon Aurora MySQL dan Amazon RDS for MySQL menggunakan Amazon dan mengirim notifikasi menggunakan Amazon SNS. CloudWatch

Menggunakan CloudWatch Log dengan innodb_print_all_deadlocks dihidupkan, Anda dapat mengonfigurasi alarm untuk memberi tahu Anda ketika jumlah kebuntuan melebihi ambang batas yang diberikan. Untuk menentukan ambang batas, kami sarankan Anda mengamati tren Anda dan menggunakan nilai berdasarkan beban kerja normal Anda.
Wawasan Performa – Saat menggunakan Wawasan Performa, Anda dapat memantau metrik innodb_deadlocks dan innodb_lock_wait_timeout. Untuk informasi selengkapnya tentang metrik ini, lihat Penghitung non-native untuk Aurora MySQL.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Praktik terbaik untuk ketersediaan tinggi

Mengevaluasi penggunaan instans DB untuk Aurora MySQL dengan metrik Amazon CloudWatch