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

# Rekomendasi untuk fitur MySQL di Aurora MySQL
Rekomendasi untuk fitur 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.

**Topics**
+ [

## Menggunakan replikasi multithreaded di Aurora MySQL
](#AuroraMySQL.BestPractices.MTReplica)
+ [

## Memanggil AWS Lambda fungsi menggunakan fungsi MySQL asli
](#AuroraMySQL.BestPractices.Lambda)
+ [

## Menghindari transaksi XA dengan Amazon Aurora MySQL
](#AuroraMySQL.BestPractices.XA)
+ [

## Mempertahankan kunci asing tetap aktif selama pernyataan DML
](#Aurora.BestPractices.ForeignKeys)
+ [

## Mengonfigurasi seberapa sering buffer log di-flush
](#AuroraMySQL.BestPractices.Flush)
+ [

## Meminimalkan dan memecahkan masalah deadlock Aurora MySQL
](#AuroraMySQL.BestPractices.deadlocks)

## 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](Aurora.Replication.md). Untuk informasi selengkapnya tentang replikasi multithreaded di Aurora MySQL, lihat. [Replikasi log biner multithreaded](binlog-optimization.md#binlog-optimization-multithreading) 

## 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](AuroraMySQL.Integrating.Lambda.md).

## 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](https://dev.mysql.com/doc/refman/8.0/en/xa.html) 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:

1. Atur `foreign_key_checks` ke `0`.

1. Membuat perubahan bahasa manipulasi data (DML).

1. Pastikan bahwa perubahan yang telah Anda selesaikan tidak melanggar batasan kunci asing.

1. 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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_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\$1flush\$1log\$1at\$1trx\$1commit](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_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](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-correlated-failure/). 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](https://d1.awsstatic.com/events/reinvent/2020/Amazon_Aurora_storage_demystified_DAT401.pdf).

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](https://bugs.mysql.com/bug.php?id=98324) 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](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html) 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html) 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](https://bugs.mysql.com/bug.php?id=98324).

1. 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.

   1. Alih-alih menggunakan `REPLACE INTO`, tulis ulang pernyataan SQL sebagai transaksi multipernyataan seperti berikut ini:

      ```
      BEGIN;
      DELETE conflicting rows;
      INSERT new rows;
      COMMIT;
      ```

   1. 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;
      ```

1. 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.

1. 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.

1. Menambahkan indeks yang dipilih dengan cermat ke tabel Anda dapat meningkatkan selektivitas dan mengurangi kebutuhan untuk mengakses baris, sehingga mengurangi penguncian.

1. Jika Anda mengalami [penguncian celah](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-gap-locks), 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html) 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](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_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](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_deadlock_detection) 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](https://dev.mysql.com/doc/refman/5.7/en/show-engine.html) 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\$1print\$1all\$1deadlocks](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_print_all_deadlocks).

  Ketika parameter ini diaktifkan, informasi tentang semua deadlock dalam transaksi pengguna InnoDB dicatat dalam [log kesalahan](https://dev.mysql.com/doc/refman/8.0/en/error-log.html) 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](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+  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](https://aws.amazon.com/blogs/database/monitor-errors-in-amazon-aurora-mysql-and-amazon-rds-for-mysql-using-amazon-cloudwatch-and-send-notifications-using-amazon-sns/) 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](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.Aurora_MySQL.NonNative).