Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menyesuaikan Aurora MySQL dengan wawasan proaktif Amazon DevOps Guru
Wawasan proaktif DevOps Guru mendeteksi kondisi bermasalah yang diketahui pada klaster DB Aurora MySQL sebelum masalah tersebut terjadi. DevOps Guru dapat melakukan hal berikut:
+ Mencegah banyak masalah umum pada basis data dengan memeriksa silang konfigurasi basis data terhadap pengaturan umum yang direkomendasikan.
+ Memberi tahu Anda tentang masalah kritis dalam armada yang, jika dibiarkan tanpa diperiksa, dapat menyebabkan masalah yang lebih besar di kemudian hari.
+ Memberi tahu Anda tentang masalah yang baru ditemukan.
Setiap wawasan proaktif berisi analisis penyebab masalah dan rekomendasi untuk tindakan korektif.
**Topics**
+ [Panjang daftar riwayat InnoDB meningkat secara signifikan](proactive-insights.history-list.md)
+ [Basis data membuat tabel sementara pada disk](proactive-insights.temp-tables.md)
# Panjang daftar riwayat InnoDB meningkat secara signifikan
Mulai dari*date*, daftar riwayat Anda untuk perubahan baris meningkat secara signifikan, hingga *length* aktif*db-instance*. Peningkatan ini memengaruhi performa penonaktifan kueri dan basis data.
**Topics**
+ [Versi mesin yang didukung](#proactive-insights.history-list.context.supported)
+ [Konteks](#proactive-insights.history-list.context)
+ [Kemungkinan penyebab masalah ini](#proactive-insights.history-list.causes)
+ [Tindakan](#proactive-insights.history-list.actions)
+ [Metrik terkait](#proactive-insights.history-list.metrics)
## Versi mesin yang didukung
Informasi wawasan ini didukung untuk semua versi Aurora MySQL.
## Konteks
Sistem transaksi InnoDB mempertahankan kontrol konkurensi multiversi (MVCC). Ketika baris diubah, versi pra-modifikasi dari data yang diubah disimpan sebagai catatan undo dalam log undo. Setiap data undo memiliki referensi ke data redo sebelumnya, yang membentuk daftar tertaut.
Daftar riwayat InnoDB adalah daftar global log undo untuk transaksi yang dilakukan. MySQL menggunakan daftar riwayat untuk membersihkan data dan halaman log saat transaksi tidak lagi memerlukan riwayat. Panjang daftar riwayat adalah jumlah total log undo yang berisi perubahan dalam daftar riwayat. Setiap log berisi satu atau beberapa modifikasi. Jika panjang daftar riwayat InnoDB bertambah terlalu besar, yang menunjukkan sejumlah besar versi baris lama, kueri dan penonaktifan basis data menjadi lebih lambat.
## Kemungkinan penyebab masalah ini
Penyebab umum dari daftar riwayat panjang meliputi:
+ Transaksi yang berjalan lama, baik baca atau tulis
+ Beban tulis yang berat
## Tindakan
Kami merekomendasikan tindakan yang berbeda bergantung pada penyebab wawasan Anda.
**Topics**
+ [Jangan memulai operasi apa pun yang melibatkan penonaktifan basis data hingga daftar riwayat InnoDB berkurang](#proactive-insights.history-list.actions.no-shutdown)
+ [Mengidentifikasi dan mengakhiri transaksi yang berjalan lama](#proactive-insights.history-list.actions.long-txn)
+ [Mengidentifikasi host teratas dan pengguna teratas dengan menggunakan Wawasan Performa.](#proactive-insights.history-list.actions.top-PI)
### Jangan memulai operasi apa pun yang melibatkan penonaktifan basis data hingga daftar riwayat InnoDB berkurang
Karena daftar riwayat InnoDB yang panjang memperlambat penonaktifan basis data, kurangi ukuran daftar sebelum memulai operasi yang melibatkan penonaktifan basis data. Operasi ini meliputi peningkatan basis data versi utama.
### Mengidentifikasi dan mengakhiri transaksi yang berjalan lama
Anda dapat menemukan transaksi yang berjalan lama dengan mengueri `information_schema.innodb_trx`.
**catatan**
Pastikan juga untuk mencari transaksi jangka panjang pada replika baca.
**Untuk mengidentifikasi dan mengakhiri transaksi yang berjalan lama**
1. Di klien SQL Anda, jalankan kueri berikut:
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Akhiri setiap transaksi yang berjalan lama dengan prosedur [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) yang disimpan.
### Mengidentifikasi host teratas dan pengguna teratas dengan menggunakan Wawasan Performa.
Optimalkan transaksi agar sejumlah besar baris yang dimodifikasi segera dilakukan.
## Metrik terkait
Metrik berikut terkait dengan wawasan ini:
+ `trx_rseg_history_len`— Metrik penghitung ini dapat dilihat di Performance Insights, serta tabel. `INFORMATION_SCHEMA.INNODB_METRICS` Untuk informasi selengkapnya, lihat tabel [metrik InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) dalam dokumentasi MySQL.
+ `RollbackSegmentHistoryListLength`— CloudWatch Metrik Amazon ini mengukur log pembatalan yang mencatat transaksi yang dilakukan dengan catatan yang ditandai hapus. Catatan ini dijadwalkan untuk diproses oleh operasi purge InnoDB. Metrik `trx_rseg_history_len` memiliki nilai yang sama dengan`RollbackSegmentHistoryListLength`.
+ `PurgeBoundary`— Nomor transaksi yang memungkinkan pembersihan InnoDB. Jika CloudWatch metrik ini tidak maju untuk jangka waktu yang lama, ini merupakan indikasi yang baik bahwa pembersihan InnoDB diblokir oleh transaksi yang berjalan lama. Untuk menyelidiki, periksa transaksi aktif pada cluster DB MySQL Aurora Anda. Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
+ `PurgeFinishedPoint`— Nomor transaksi hingga pembersihan InnoDB dilakukan. CloudWatch Metrik ini dapat membantu Anda memeriksa seberapa cepat proses pembersihan InnoDB. Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
+ `TransactionAgeMaximum`— Usia transaksi berjalan aktif tertua. CloudWatch Metrik ini hanya tersedia untuk Aurora MySQL versi 3.08 dan lebih tinggi.
+ `TruncateFinishedPoint`— Nomor transaksi hingga pemotongan undo dilakukan. CloudWatch Metrik ini hanya tersedia untuk Aurora MySQL versi 2.11 dan lebih tinggi, dan versi 3.08 dan lebih tinggi.
Untuk informasi selengkapnya tentang CloudWatch metrik, lihat[Metrik tingkat instans untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
# Basis data membuat tabel sementara pada disk
Penggunaan tabel sementara on-disk Anda baru-baru ini meningkat secara signifikan, hingga*percentage*. Database membuat sekitar tabel *number* sementara per detik. Ini dapat memengaruhi kinerja dan meningkatkan operasi disk*db-instance*.
**Topics**
+ [Versi mesin yang didukung](#proactive-insights.temp-tables.context.supported)
+ [Konteks](#proactive-insights.temp-tables.context)
+ [Kemungkinan penyebab masalah ini](#proactive-insights.temp-tables.causes)
+ [Tindakan](#proactive-insights.temp-tables.actions)
+ [Metrik terkait](#proactive-insights.temp-tables.metrics)
## Versi mesin yang didukung
Informasi wawasan ini didukung untuk semua versi Aurora MySQL.
## Konteks
Terkadang server MySQL perlu membuat tabel sementara internal saat memproses kueri. Aurora MySQL dapat menyimpan tabel sementara internal dalam memori, di mana ia dapat diproses TempTable oleh atau mesin penyimpanan MEMORY, atau disimpan pada disk oleh InnoDB. Untuk informasi selengkapnya, lihat [Penggunaan Tabel Sementara Internal di MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) di *Panduan Referensi MySQL*.
## Kemungkinan penyebab masalah ini
Peningkatan tabel sementara pada disk menunjukkan penggunaan kueri yang kompleks. Jika memori yang dikonfigurasi tidak cukup untuk menyimpan tabel sementara dalam memori, Aurora MySQL akan membuat tabel pada disk. Hal ini dapat memengaruhi performa dan meningkatkan operasi disk.
## Tindakan
Kami merekomendasikan tindakan yang berbeda bergantung pada penyebab wawasan Anda.
+ Untuk Aurora MySQL versi 3, kami sarankan Anda menggunakan mesin penyimpanan. TempTable
+ Optimalkan kueri Anda untuk menampilkan lebih sedikit data dengan memilih kolom yang diperlukan saja.
Jika Anda mengaktifkan Skema Performa dengan semua `statement` instrumen diaktifkan dan waktunya diatur, Anda dapat mengueri `SYS.statements_with_temp_tables` untuk mengambil daftar kueri yang menggunakan tabel sementara. Untuk informasi selengkapnya, lihat [Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) dalam dokumentasi MySQL.
+ Pertimbangkan untuk mengindeks kolom yang digunakan dalam operasi pengurutan dan pengelompokan.
+ Tulis ulang kueri Anda untuk menghindari kolom `BLOB` dan `TEXT`. Kolom ini selalu menggunakan disk.
+ Setel parameter basis data berikut: `tmp_table_size` dan`max_heap_table_size`.
Nilai default untuk parameter ini adalah 16 MiB. Saat menggunakan mesin penyimpanan MEMORY untuk tabel sementara dalam memori, ukuran maksimumnya ditentukan oleh nilai `tmp_table_size` atau `max_heap_table_size`, mana yang lebih kecil. Jika ukuran maksimum ini tercapai, MySQL secara otomatis mengubah tabel sementara internal dalam memori ke tabel sementara internal pada disk InnoDB. Untuk informasi selengkapnya, lihat [Menggunakan mesin TempTable penyimpanan di Amazon RDS for MySQL dan Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**catatan**
Jika tabel MEMORY dibuat secara eksplisit dengan CREATE TABLE, hanya variabel `max_heap_table_size` yang menentukan seberapa besar tabel bisa berkembang. Konversi ke format pada disk juga tidak terjadi.
## Metrik terkait
Metrik Wawasan Performa berikut terkait dengan wawasan ini:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Untuk informasi selengkapnya, lihat [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) dalam dokumentasi MySQL.