Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon Aurora Referensi saya SQL
Referensi ini mencakup informasi tentang SQL parameter Aurora My, variabel status, dan SQL ekstensi umum atau perbedaan dari komunitas My SQL database engine.
**Topics**
+ [Parameter konfigurasi Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md)
+ [Variabel status global Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Peristiwa tunggu Aurora MySQL](AuroraMySQL.Reference.Waitevents.md)
+ [Aurora Utas saya menyatakan SQL](AuroraMySQL.Reference.thread-states.md)
+ [Tingkat isolasi Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md)
+ [Aurora Petunjuk saya SQL](AuroraMySQL.Reference.Hints.md)
+ [Aurora Referensi prosedur SQL tersimpan saya](AuroraMySQL.Reference.StoredProcs.md)
+ [Aurora My SQL —tabel information\$1schema spesifik](AuroraMySQL.Reference.ISTables.md)
# Parameter konfigurasi Aurora MySQL
Anda mengelola klaster DB Amazon Aurora MySQL Anda dengan cara yang sama seperti Anda mengelola instans DB Amazon RDS lain, dengan menggunakan parameter dalam grup parameter DB. Amazon Aurora berbeda dari mesin DB lainnya karena Anda memiliki klaster DB yang berisi beberapa instans DB. Akibatnya, beberapa parameter yang Anda gunakan untuk mengelola klaster DB Aurora MySQL berlaku untuk seluruh klaster. Parameter lain hanya berlaku untuk instans DB tertentu dalam klaster DB.
Untuk mengelola parameter tingkat klaster, gunakan grup parameter klaster DB. Untuk mengelola parameter tingkat instans, gunakan grup parameter DB. Setiap instans DB di klaster DB Aurora MySQL kompatibel dengan mesin basis data MySQL. Namun, Anda menerapkan beberapa parameter mesin basis data MySQL di tingkat klaster, dan Anda mengelola parameter ini menggunakan grup parameter klaster DB. Anda tidak dapat menemukan parameter tingkat klaster dalam grup parameter DB untuk instans dalam klaster Aurora DB. Daftar parameter tingkat klaster akan muncul nanti dalam topik ini.
Anda dapat mengelola parameter tingkat cluster dan tingkat instans menggunakan, API, AWS CLI atau Amazon Konsol Manajemen AWS RDS. Anda menggunakan perintah terpisah untuk mengelola parameter tingkat klaster dan parameter tingkat instans. Misalnya, Anda dapat menggunakan perintah [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) CLI untuk mengelola parameter tingkat cluster dalam grup parameter cluster DB. Anda dapat menggunakan perintah [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)CLI untuk mengelola parameter tingkat instance dalam grup parameter DB untuk instance DB di cluster DB.
Anda dapat melihat parameter tingkat klaster dan tingkat instans di konsol, atau dengan menggunakan CLI atau API RDS. Misalnya, Anda dapat menggunakan [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) AWS CLI perintah untuk melihat parameter tingkat cluster dalam grup parameter cluster DB. Anda dapat menggunakan perintah [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html)CLI untuk melihat parameter tingkat instance dalam grup parameter DB untuk instance DB di cluster DB.
**catatan**
Setiap [grup parameter default](USER_WorkingWithParamGroups.md) berisi nilai default untuk semua parameter di grup parameter. Jika parameter memiliki "mesin default" untuk nilai ini, lihat dokumentasi MySQL atau PostgreSQL khusus versi untuk nilai default sebenarnya.
Kecuali jika dinyatakan lain, parameter yang tercantum dalam tabel berikut berlaku untuk Aurora MySQL versi 2 dan 3.
Untuk informasi selengkapnya tentang grup parameter DB, lihat [](USER_WorkingWithParamGroups.md). Untuk aturan dan batasan klaster Aurora Serverless v1, lihat [Grup parameter untuk Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
**Topics**
+ [Parameter tingkat klaster](#AuroraMySQL.Reference.Parameters.Cluster)
+ [Parameter tingkat instans](#AuroraMySQL.Reference.Parameters.Instance)
+ [Parameter MySQL yang tidak berlaku untuk Aurora MySQL](#AuroraMySQL.Reference.Parameters.Inapplicable)
## Parameter tingkat klaster
Tabel berikut menunjukkan semua parameter yang berlaku untuk seluruh klaster DB Aurora MySQL.
| Nama parameter | Dapat diubah | Catatan |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | Ya | Hanya memengaruhi klaster yang menggunakan replikasi biner log (binlog). Untuk informasi tentang replikasi binlog, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Dihapus dari Aurora MySQL versi 3. |
| `aurora_binlog_replication_max_yield_seconds` | Ya | Hanya memengaruhi klaster yang menggunakan replikasi biner log (binlog). Untuk informasi tentang replikasi binlog, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). |
| `aurora_binlog_replication_sec_index_parallel_workers` | Ya | Menetapkan jumlah thread paralel yang tersedia untuk menerapkan perubahan indeks sekunder saat mereplikasi transaksi untuk tabel besar dengan lebih dari satu indeks sekunder. Parameter diatur ke `0` (dinonaktifkan) secara default. Parameter ini tersedia di Aurora MySQL versi 306 dan lebih tinggi. Untuk informasi selengkapnya, lihat [Mengoptimalkan replikasi log biner untuk Aurora MySQL](binlog-optimization.md). |
| `aurora_binlog_use_large_read_buffer` | Ya | Hanya memengaruhi klaster yang menggunakan replikasi biner log (binlog). Untuk informasi tentang replikasi binlog, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). Dihapus dari Aurora MySQL versi 3. |
| `aurora_disable_hash_join` | Ya | Atur parameter ini ke `ON` untuk menonaktifkan pengoptimalan hash join di Aurora MySQL versi 2.09 atau lebih tinggi. Parameter ini tidak didukung untuk versi 3. Untuk informasi selengkapnya, lihat [Kueri paralel untuk Amazon Aurora My SQL](aurora-mysql-parallel-query.md). |
| `aurora_enable_replica_log_compression` | Ya | Untuk informasi selengkapnya, lihat [Pertimbangan performa untuk replikasi Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Tidak berlaku untuk klaster yang merupakan bagian dari basis data global Aurora. Dihapus dari Aurora MySQL versi 3. |
| `aurora_enable_repl_bin_log_filtering` | Ya | Untuk informasi selengkapnya, lihat [Pertimbangan performa untuk replikasi Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Tidak berlaku untuk klaster yang merupakan bagian dari basis data global Aurora. Dihapus dari Aurora MySQL versi 3. |
| `aurora_enable_staggered_replica_restart` | Ya | Pengaturan ini tersedia di Aurora MySQL versi 3, tetapi tidak digunakan. |
| `aurora_enable_zdr` | Ya | Pengaturan ini diaktifkan secara default di Aurora MySQL 2.10 dan yang lebih tinggi. |
| `aurora_in_memory_relaylog` | Ya | Mengatur mode log relai memori dalam. Anda dapat menggunakan fitur ini pada replika binlog untuk meningkatkan kinerja replikasi log biner. Untuk mematikan fitur ini, atur parameter ke OFF. Untuk mengaktifkan fitur ini, atur parameter ke ON. |
| `aurora_enhanced_binlog` | Ya | Tetapkan nilai parameter ini ke 1 untuk mengaktifkan binlog yang ditingkatkan di Aurora MySQL versi 3.03.1 dan yang lebih tinggi. Untuk informasi selengkapnya, lihat [Menyiapkan binlog yang disempurnakan untuk Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `aurora_full_double_precision_in_json` | Ya | Tetapkan nilai parameter ini untuk mengaktifkan penguraian nomor floating point dalam dokumen JSON dengan presisi penuh. |
| `aurora_jemalloc_background_thread` | Ya | Gunakan parameter ini untuk mengaktifkan thread latar belakang untuk melakukan operasi pemeliharaan memori. Nilai yang diizinkan adalah `0` (dinonaktifkan) dan `1` (diaktifkan). Nilai default-nya adalah `0`. Parameter ini berlaku untuk Aurora MySQL versi 3.05 dan lebih tinggi. |
| `aurora_jemalloc_dirty_decay_ms` | Ya | Gunakan parameter ini untuk mempertahankan memori yang dibebaskan untuk jangka waktu tertentu (dalam milidetik). Mempertahankan memori memungkinkan penggunaan kembali lebih cepat. Nilai yang diizinkan adalah `0`–`18446744073709551615`. Nilai defaultnya adalah `10000` (10 detik). Anda dapat menggunakan penundaan yang lebih pendek untuk membantu menghindari out-of-memory masalah, dengan mengorbankan kinerja yang lebih lambat. Parameter ini berlaku untuk Aurora MySQL versi 3.05 dan lebih tinggi. |
| `aurora_jemalloc_tcache_enabled` | Ya | Gunakan parameter ini untuk melayani permintaan memori kecil (hingga 32 KiB) dalam cache lokal thread, melewati arena memori. Nilai yang diizinkan adalah `0` (dinonaktifkan) dan `1` (diaktifkan). Nilai default-nya adalah `1`. Parameter ini berlaku untuk Aurora MySQL versi 3.05 dan lebih tinggi. |
| `aurora_load_from_s3_role` | Ya | Untuk informasi selengkapnya, lihat [Memuat data ke klaster DB Amazon Aurora MySQL dari file teks di bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). Saat ini tidak tersedia di Aurora MySQL versi 3. Gunakan `aws_default_s3_role`. |
| `aurora_mask_password_hashes_type` | Ya | Pengaturan ini diaktifkan secara default di Aurora MySQL 2.11 dan yang lebih tinggi. Gunakan pengaturan ini untuk me-masking hash kata sandi MySQL Aurora di log kueri dan audit yang lambat. Nilai yang diizinkan adalah `0` dan `1` (default). Saat diatur ke `1`, kata sandi dicatat sebagai ``. Saat diatur ke `0`, kata sandi dicatat sebagai nilai hash (`#`). |
| `aurora_select_into_s3_role` | Ya | Untuk informasi selengkapnya, lihat [Menyimpan data dari klaster DB Amazon Aurora MySQL ke dalam file teks di bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). Saat ini tidak tersedia di Aurora MySQL versi 3. Gunakan `aws_default_s3_role`. |
| `authentication_kerberos_caseins_cmp` | Ya | Mengontrol perbandingan nama pengguna yang tidak peka huruf besar/kecil untuk plugin `authentication_kerberos`. Atur ke `true` untuk perbandingan yang tidak peka huruf besar/kecil. Secara default, perbandingan peka huruf besar/kecil digunakan (`false`). Untuk informasi selengkapnya, lihat [Menggunakan otentikasi Kerberos untuk Aurora My SQL](aurora-mysql-kerberos.md). Parameter ini tersedia di Aurora MySQL versi 3.03 dan lebih tinggi. |
| `auto_increment_increment` | Ya | Tidak ada |
| `auto_increment_offset` | Ya | Tidak ada |
| `aws_default_lambda_role` | Ya | Untuk informasi selengkapnya, lihat [Menginvokasi fungsi Lambda dari klaster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). |
| `aws_default_s3_role` | Ya | Digunakan saat menginvokasi pernyataan `LOAD DATA FROM S3`, `LOAD XML FROM S3`, atau `SELECT INTO OUTFILE S3` dari klaster DB Anda. Di Aurora MySQL versi 2, peran IAM yang ditentukan dalam parameter ini akan digunakan jika peran IAM tidak ditentukan untuk `aurora_load_from_s3_role` atau `aurora_select_into_s3_role` untuk pernyataan yang sesuai. Di Aurora MySQL versi 3, peran IAM yang ditentukan untuk parameter ini selalu digunakan. Untuk informasi selengkapnya, lihat [Mengaitkan peran IAM dengan klaster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). |
| `binlog_backup` | Ya | Tetapkan nilai parameter ini ke 0 untuk mengaktifkan binlog yang ditingkatkan di Aurora MySQL versi 3.03.1 dan yang lebih tinggi. Anda dapat menonaktifkan parameter ini hanya ketika Anda menggunakan binlog yang ditingkatkan. Untuk informasi selengkapnya, lihat [Menyiapkan binlog yang disempurnakan untuk Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_checksum` | Ya | API AWS CLI dan RDS melaporkan nilai `None` jika parameter ini tidak disetel. Dalam hal ini, Aurora MySQL menggunakan nilai default mesin, yaitu `CRC32`. Ini berbeda dari pengaturan eksplisit `NONE`, yang menonaktifkan checksum. |
| `binlog-do-db` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_format` | Ya | Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). |
| `binlog_group_commit_sync_delay` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_group_commit_sync_no_delay_count` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog-ignore-db` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_replication_globaldb` | Ya | Tetapkan nilai parameter ini ke 0 untuk mengaktifkan binlog yang ditingkatkan di Aurora MySQL versi 3.03.1 dan yang lebih tinggi. Anda dapat menonaktifkan parameter ini hanya ketika Anda menggunakan binlog yang ditingkatkan. Untuk informasi selengkapnya, lihat [Menyiapkan binlog yang disempurnakan untuk Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_row_image` | Tidak | Tidak ada |
| `binlog_row_metadata` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_row_value_options` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_rows_query_log_events` | Ya | Tidak ada |
| `binlog_transaction_compression` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_transaction_compression_level_zstd` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_transaction_dependency_history_size` | Ya | Parameter ini menetapkan batas atas jumlah hash baris yang dipertahankan dalam memori dan digunakan untuk mencari transaksi yang terakhir memodifikasi baris tertentu. Setelah jumlah hash ini tercapai, riwayatnya dibersihkan. Parameter ini berlaku untuk Aurora MySQL versi 2.12 dan lebih tinggi, serta versi 3. |
| `binlog_transaction_dependency_tracking` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `character-set-client-handshake` | Ya | Tidak ada |
| `character_set_client` | Ya | Tidak ada |
| `character_set_connection` | Ya | Tidak ada |
| `character_set_database` | Ya | Set karakter yang digunakan oleh database default. Nilai default-nya adalah `utf8mb4`. |
| `character_set_filesystem` | Ya | Tidak ada |
| `character_set_results` | Ya | Tidak ada |
| `character_set_server` | Ya | Tidak ada |
| `collation_connection` | Ya | Tidak ada |
| `collation_server` | Ya | Tidak ada |
| `completion_type` | Ya | Tidak ada |
| `default_storage_engine` | Tidak | Klaster Aurora MySQL menggunakan mesin penyimpanan InnoDB untuk semua data Anda. |
| `enforce_gtid_consistency` | Terkadang | Dapat dimodifikasi di Aurora MySQL versi 2 dan lebih tinggi. |
| `event_scheduler` | Ya | Menunjukkan status Penjadwal Peristiwa. Dapat dimodifikasi hanya pada tingkat klaster di Aurora MySQL versi 3. |
| `gtid-mode` | Terkadang | Dapat dimodifikasi di Aurora MySQL versi 2 dan lebih tinggi. |
| `information_schema_stats_expiry` | Ya | Jumlah detik setelah server basis data MySQL mengambil data dari mesin penyimpanan dan mengganti data dalam cache. Nilai yang diizinkan adalah `0`–`31536000`. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `init_connect` | Ya | Perintah yang akan dijalankan oleh server untuk setiap klien yang terhubung. Gunakan tanda kutip ganda (“) untuk pengaturan agar menghindari kegagalan koneksi, misalnya: SET optimizer_switch="hash_join=off"
Di Aurora MySQL versi 3, parameter ini tidak berlaku untuk pengguna yang memiliki hak akses `CONNECTION_ADMIN`. Ini termasuk pengguna master Aurora. Untuk informasi selengkapnya, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `innodb_adaptive_hash_index` | Ya | Anda dapat memodifikasi parameter ini pada tingkat klaster DB di Aurora MySQL versi 2 dan 3. Indeks Hash Adaptif tidak didukung pada instans DB pembaca. |
| `innodb_aurora_instant_alter_column_allowed` | Ya | Mengontrol apakah algoritma `INSTANT` dapat digunakan untuk operasi `ALTER COLUMN` di tingkat global. Nilai yang diizinkan adalah sebagai berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Untuk informasi selengkapnya, lihat [Column Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) dalam dokumentasi MySQL. Parameter ini berlaku untuk Aurora MySQL versi 3.05 dan lebih tinggi. |
| `innodb_autoinc_lock_mode` | Ya | Tidak ada |
| `innodb_checksums` | Tidak | Dihapus dari Aurora MySQL versi 3. |
| `innodb_cmp_per_index_enabled` | Ya | Tidak ada |
| `innodb_commit_concurrency` | Ya | Tidak ada |
| `innodb_data_home_dir` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `innodb_deadlock_detect` | Ya | Opsi ini digunakan untuk menonaktifkan deteksi deadlock di Aurora MySQL versi 2.11 dan lebih tinggi serta versi 3. Pada sistem konkurensi tinggi, deteksi deadlock dapat menyebabkan perlambatan ketika banyak thread menunggu kunci yang sama. Baca dokumentasi MySQL untuk informasi selengkapnya tentang parameter ini. |
| `innodb_default_row_format` | Ya | Parameter ini mendefinisikan format baris default untuk tabel InnoDB (termasuk tabel sementara InnoDB yang dibuat pengguna). Ini berlaku untuk Aurora MySQL versi 2 dan 3. Nilainya bisa `DYNAMIC`, `COMPACT`, atau `REDUNDANT.` |
| `innodb_file_per_table` | Ya | Parameter ini memengaruhi cara penyimpanan tabel disusun. Untuk informasi selengkapnya, lihat [Penskalaan penyimpanan](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). |
| `innodb_flush_log_at_trx_commit` | Ya | Kami sangat menyarankan agar Anda menggunakan nilai default `1`. Di Aurora MySQL versi 3, sebelum Anda dapat mengatur parameter ini ke nilai selain `1`, Anda harus menetapkan nilai `innodb_trx_commit_allow_data_loss` ke `1`. Untuk informasi selengkapnya, lihat [Mengonfigurasi seberapa sering buffer log di-flush](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_ft_max_token_size` | Ya | Tidak ada |
| `innodb_ft_min_token_size` | Ya | Tidak ada |
| `innodb_ft_num_word_optimize` | Ya | Tidak ada |
| `innodb_ft_sort_pll_degree` | Ya | Tidak ada |
| `innodb_online_alter_log_max_size` | Ya | Tidak ada |
| `innodb_optimize_fulltext_only` | Ya | Tidak ada |
| `innodb_page_size` | Tidak | Tidak ada |
| `innodb_print_all_deadlocks` | Ya | Saat diaktifkan, mencatat informasi tentang semua deadlock InnoDB di log kesalahan Aurora MySQL. Untuk informasi selengkapnya, lihat [Meminimalkan dan memecahkan masalah deadlock Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_purge_batch_size` | Ya | Tidak ada |
| `innodb_purge_threads` | Ya | Tidak ada |
| `innodb_rollback_on_timeout` | Ya | Tidak ada |
| `innodb_rollback_segments` | Ya | Tidak ada |
| `innodb_spin_wait_delay` | Ya | Tidak ada |
| `innodb_strict_mode` | Ya | Tidak ada |
| `innodb_support_xa` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `innodb_sync_array_size` | Ya | Tidak ada |
| `innodb_sync_spin_loops` | Ya | Tidak ada |
| `innodb_stats_include_delete_marked` | Ya | Ketika parameter ini diaktifkan, InnoDB menyertakan catatan yang ditandai hapus saat menghitung statistik pengoptimisasi persisten. Parameter ini berlaku untuk Aurora MySQL versi 2.12 dan lebih tinggi, serta versi 3. |
| `innodb_table_locks` | Ya | Tidak ada |
| `innodb_trx_commit_allow_data_loss` | Ya | Di Aurora MySQL versi 3, atur nilai parameter ini ke `1` sehingga Anda dapat mengubah nilai `innodb_flush_log_at_trx_commit`. Nilai default `innodb_trx_commit_allow_data_loss` adalah `0`. Untuk informasi selengkapnya, lihat [Mengonfigurasi seberapa sering buffer log di-flush](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_undo_directory` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `internal_tmp_disk_storage_engine` | Ya | Mengontrol mesin penyimpanan dalam memori mana yang digunakan untuk tabel sementara internal. Nilai yang diizinkan adalah `INNODB` dan `MYISAM`. Parameter ini berlaku untuk Aurora MySQL versi 2. |
| `internal_tmp_mem_storage_engine` | Ya | Mengontrol mesin penyimpanan dalam memori mana yang digunakan untuk tabel sementara internal. Nilai yang diizinkan adalah `MEMORY` dan `TempTable`. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `key_buffer_size` | Ya | Cache kunci untuk tabel MyISAM. Untuk informasi selengkapnya, lihat [mutex keycache->cache\$1lock](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `lc_time_names` | Ya | Tidak ada |
| `log_error_suppression_list` | Ya | Menentukan daftar kode kesalahan yang tidak login di log kesalahan MySQL. Ini memungkinkan Anda untuk mengabaikan kondisi kesalahan nonkritis tertentu untuk membantu menjaga log kesalahan Anda tetap bersih. Untuk informasi selengkapnya, lihat [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) di dokumentasi MySQL. Parameter ini berlaku untuk Aurora MySQL versi 3.03 dan lebih tinggi. |
| `low_priority_updates` | Ya | Operasi `INSERT`, `UPDATE`, `DELETE`, dan `LOCK TABLE WRITE` menunggu sampai tidak ada operasi `SELECT` yang tertunda. Parameter ini hanya memengaruhi mesin penyimpanan yang hanya menggunakan penguncian tingkat tabel (MyISAM, MEMORY, MERGE). Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `lower_case_table_names` | Ya (Aurora MySQL versi 2) Hanya pada waktu pembuatan klaster (Aurora MySQL versi 3) | Di Aurora MySQL versi 2.10 dan versi 2.x yang lebih tinggi, pastikan untuk mem-boot ulang semua instans pembaca setelah mengubah pengaturan ini dan mem-boot ulang instans penulis. Untuk detailnya, lihat [Mem-boot ulang klaster Aurora dengan ketersediaan baca](aurora-mysql-survivable-replicas.md). Di Aurora MySQL versi 3, nilai parameter ini diatur secara permanen pada saat klaster dibuat. Jika Anda menggunakan nilai nondefault untuk opsi ini, siapkan grup parameter kustom Aurora MySQL versi 3 Anda sebelum meningkatkan, dan tentukan grup parameter selama operasi pemulihan snapshot yang membuat klaster versi 3. Dengan basis data global Aurora berdasarkan Aurora MySQL, Anda tidak dapat melakukan peningkatan di tempat dari Aurora MySQL versi 2 ke versi 3 jika parameter `lower_case_table_names` diaktifkan. Untuk informasi selengkapnya tentang metode yang dapat Anda gunakan, lihat [Peningkatan versi utama](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). |
| `master-info-repository` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `master_verify_checksum` | Ya | Aurora MySQL versi 2. Gunakan `source_verify_checksum` di Aurora MySQL versi 3. |
| `max_delayed_threads` | Ya | Mengatur jumlah maksimum thread untuk menangani pernyataan `INSERT DELAYED`. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `max_error_count` | Ya | Jumlah maksimum pesan kesalahan, peringatan, dan catatan yang akan disimpan untuk ditampilkan. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `max_execution_time` | Ya | Batas waktu untuk menjalankan pernyataan `SELECT`, dalam milidetik. Nilainya bisa berkisar `0`–`18446744073709551615`. Ketika diatur ke`0`, tidak ada batas waktu. Untuk informasi selengkapnya, lihat [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) dalam dokumentasi MySQL. |
| `min_examined_row_limit` | Ya | Gunakan parameter ini agar kueri yang memeriksa lebih sedikit jumlah baris dari yang ditentukan tidak dicatat. |
| `partial_revokes` | Tidak | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `preload_buffer_size` | Ya | Ukuran buffer yang dialokasikan saat melakukan pra-pemuatan indeks. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `query_cache_type` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `read_only` | Ya | Ketika parameter ini diaktifkan, server tidak mengizinkan pembaruan kecuali dari yang dilakukan oleh thread replika. Untuk Aurora MySQL versi 2, nilai yang valid adalah sebagai berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Untuk Aurora MySQL versi 3, nilai yang valid adalah sebagai berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Di Aurora MySQL versi 3, parameter ini tidak berlaku untuk pengguna yang memiliki hak akses `CONNECTION_ADMIN`. Ini termasuk pengguna master Aurora. Untuk informasi selengkapnya, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `relay-log-space-limit` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replica_parallel_type` | Ya | Parameter ini memungkinkan eksekusi paralel pada replika dari semua thread yang tidak di-commit yang sudah ada dalam fase persiapan, tanpa melanggar konsistensi. Parameter ini berlaku untuk Aurora MySQL versi 3. Di Aurora MySQL versi 3.03.\$1 dan lebih rendah, nilai default-nya adalah DATABASE. Di Aurora MySQL versi 3.04 dan lebih tinggi, nilai default-nya adalah LOGICAL\$1CLOCK. |
| `replica_preserve_commit_order` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replica_transaction_retries` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replica_type_conversions` | Ya | Parameter ini menentukan jenis konversi yang digunakan pada replika. Nilai yang diizinkan adalah: `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED`, dan `ALL_UNSIGNED`. Untuk informasi selengkapnya, lihat [Replication with differing table definitions on source and replica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) dalam dokumentasi MySQL. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-do-db` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-do-table` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-ignore-db` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-ignore-table` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-wild-do-table` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `replicate-wild-ignore-table` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `require_secure_transport` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 2 dan 3. Untuk informasi selengkapnya, lihat [Koneksi TLS ke cluster DB MySQL Aurora](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). |
| `rpl_read_size` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `server_audit_cw_upload` | Tidak | Parameter ini telah usang di Aurora MySQL. Gunakan `server_audit_logs_upload`. Untuk informasi selengkapnya, lihat [Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_events` | Ya | Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md). |
| `server_audit_excl_users` | Ya | Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md). |
| `server_audit_incl_users` | Ya | Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md). |
| `server_audit_logging` | Ya | Untuk petunjuk tentang mengunggah log ke Amazon CloudWatch Logs, lihat[Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_logs_upload` | Ya | Anda dapat memublikasikan log audit ke CloudWatch Log dengan mengaktifkan Audit Lanjutan dan menyetel parameter ini. `1` Default untuk parameter `server_audit_logs_upload` adalah `0`. Untuk informasi selengkapnya, lihat [Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_id` | Tidak | Tidak ada |
| `skip-character-set-client-handshake` | Ya | Tidak ada |
| `skip_name_resolve` | Tidak | Tidak ada |
| `slave-skip-errors` | Ya | Hanya berlaku untuk klaster Aurora MySQL versi 2, dengan kompatibilitas MySQL 5.7. |
| `source_verify_checksum` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `sync_frm` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `thread_cache_size` | Ya | Jumlah thread yang akan di-cache. Parameter ini berlaku untuk Aurora MySQL versi 2 dan 3. |
| `time_zone` | Ya | Secara default, zona waktu untuk cluster Aurora DB adalah Universal Time Coordinated (UTC). Anda dapat mengatur zona waktu untuk instans di klaster DB ke zona waktu lokal untuk aplikasi Anda. Untuk informasi selengkapnya, lihat [Zona waktu lokal untuk klaster DB Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). |
| `tls_version` | Ya | Untuk informasi selengkapnya, lihat [Versi TLS untuk Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). |
## Parameter tingkat instans
Tabel berikut menunjukkan semua parameter yang berlaku untuk instans DB tertentu di klaster DB Aurora MySQL.
| Nama parameter | Dapat diubah | Catatan |
| --- | --- | --- |
| `activate_all_roles_on_login` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `allow-suspicious-udfs` | Tidak | Tidak ada |
| `aurora_disable_hash_join` | Ya | Atur parameter ini ke `ON` untuk menonaktifkan pengoptimalan hash join di Aurora MySQL versi 2.09 atau lebih tinggi. Parameter ini tidak didukung untuk versi 3. Untuk informasi selengkapnya, lihat [Kueri paralel untuk Amazon Aurora My SQL](aurora-mysql-parallel-query.md). |
| `aurora_lab_mode` | Ya | Untuk informasi selengkapnya, lihat [Mode lab Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md). Dihapus dari Aurora MySQL versi 3. |
| `aurora_oom_response` | Ya | Parameter ini didukung untuk Aurora MySQL versi 2 dan 3. Untuk informasi selengkapnya, lihat [Memecahkan out-of-memory masalah untuk database Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_parallel_query` | Ya | Atur ke `ON` untuk mengaktifkan kueri paralel di Aurora MySQL versi 2.09 atau lebih tinggi. Parameter `aurora_pq` lama tidak digunakan dalam versi ini. Untuk informasi selengkapnya, lihat [Kueri paralel untuk Amazon Aurora My SQL](aurora-mysql-parallel-query.md). |
| `aurora_pq` | Ya | Atur ke `OFF` untuk menonaktifkan kueri paralel untuk instans DB tertentu di versi Aurora MySQL sebelum 2.09. Di versi 2.09 atau lebih tinggi, aktifkan dan nonaktifkan kueri paralel dengan `aurora_parallel_query`. Untuk informasi selengkapnya, lihat [Kueri paralel untuk Amazon Aurora My SQL](aurora-mysql-parallel-query.md). |
| `aurora_read_replica_read_committed` | Ya | Mengaktifkan tingkat isolasi `READ COMMITTED` untuk Replika Aurora dan mengubah perilaku isolasi untuk mengurangi lag pembersihan selama kueri yang berjalan lama. Aktifkan pengaturan ini hanya jika Anda memahami perubahan perilaku dan pengaruhnya terhadap hasil kueri. Misalnya, pengaturan ini menggunakan isolasi yang kurang ketat daripada default MySQL. Ketika diaktifkan, kueri yang berjalan lama mungkin mengamati lebih dari satu salinan dari baris yang sama karena Aurora menyusun ulang data tabel saat kueri sedang berjalan. Untuk informasi selengkapnya, lihat [Tingkat isolasi Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md). |
| `aurora_tmptable_enable_per_table_limit` | Ya | Menentukan apakah parameter `tmp_table_size` mengontrol ukuran maksimum tabel sementara dalam memori yang dibuat oleh mesin penyimpanan `TempTable` di Aurora MySQL versi 3.04 dan lebih tinggi. Untuk informasi selengkapnya, lihat [Membatasi ukuran tabel sementara internal dalam memori](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `aurora_use_vector_instructions` | Ya | Ketika parameter ini diaktifkan, Aurora MySQL menggunakan instruksi pemrosesan vektor yang dioptimalkan yang disediakan oleh modern CPUs untuk meningkatkan kinerja pada beban kerja intensif I/O. Pengaturan ini diaktifkan secara default di Aurora MySQL versi 3.05 dan lebih tinggi. |
| `autocommit` | Ya | Tidak ada |
| `automatic_sp_privileges` | Ya | Tidak ada |
| `back_log` | Ya | Tidak ada |
| `basedir` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `binlog_cache_size` | Ya | Tidak ada |
| `binlog_max_flush_queue_time` | Ya | Tidak ada |
| `binlog_order_commits` | Ya | Tidak ada |
| `binlog_stmt_cache_size` | Ya | Tidak ada |
| `binlog_transaction_compression` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `binlog_transaction_compression_level_zstd` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `bulk_insert_buffer_size` | Ya | Tidak ada |
| `concurrent_insert` | Ya | Tidak ada |
| `connect_timeout` | Ya | Tidak ada |
| `core-file` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `datadir` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `default_authentication_plugin` | Tidak | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `default_time_zone` | Tidak | Tidak ada |
| `default_tmp_storage_engine` | Ya | Mesin penyimpanan default untuk tabel sementara. |
| `default_week_format` | Ya | Tidak ada |
| `delay_key_write` | Ya | Tidak ada |
| `delayed_insert_limit` | Ya | Tidak ada |
| `delayed_insert_timeout` | Ya | Tidak ada |
| `delayed_queue_size` | Ya | Tidak ada |
| `div_precision_increment` | Ya | Tidak ada |
| `end_markers_in_json` | Ya | Tidak ada |
| `eq_range_index_dive_limit` | Ya | Tidak ada |
| `event_scheduler` | Terkadang | Menunjukkan status Penjadwal Peristiwa. Dapat dimodifikasi hanya pada tingkat klaster di Aurora MySQL versi 3. |
| `explicit_defaults_for_timestamp` | Ya | Tidak ada |
| `flush` | Tidak | Tidak ada |
| `flush_time` | Ya | Tidak ada |
| `ft_boolean_syntax` | Tidak | Tidak ada |
| `ft_max_word_len` | Ya | Tidak ada |
| `ft_min_word_len` | Ya | Tidak ada |
| `ft_query_expansion_limit` | Ya | Tidak ada |
| `ft_stopword_file` | Ya | Tidak ada |
| `general_log` | Ya | Untuk petunjuk tentang mengunggah log ke CloudWatch Log, lihat[Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). |
| `general_log_file` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `group_concat_max_len` | Ya | Tidak ada |
| `host_cache_size` | Ya | Tidak ada |
| `init_connect` | Ya | Perintah yang akan dijalankan oleh server untuk setiap klien yang terhubung. Gunakan tanda kutip ganda (“) untuk pengaturan agar menghindari kegagalan koneksi, misalnya: SET optimizer_switch="hash_join=off"
Di Aurora MySQL versi 3, parameter ini tidak berlaku untuk pengguna yang memiliki hak akses `CONNECTION_ADMIN`, termasuk pengguna master Aurora. Untuk informasi selengkapnya, lihat [Model hak akses berbasis peran](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `innodb_adaptive_hash_index` | Ya | Anda dapat memodifikasi parameter ini di tingkat instans DB di Aurora MySQL versi 2. Ini hanya dapat dimodifikasi pada tingkat klaster DB di Aurora MySQL versi 3. Indeks Hash Adaptif tidak didukung pada instans DB pembaca. |
| `innodb_adaptive_max_sleep_delay` | Ya | Memodifikasi parameter ini tidak berdampak karena `innodb_thread_concurrency` selalu 0 untuk Aurora. |
| `innodb_aurora_max_partitions_for_range` | Ya | Dalam beberapa kasus saat statistik tetap tidak tersedia, Anda dapat menggunakan parameter ini untuk meningkatkan performa estimasi jumlah baris pada tabel yang dipartisi. Anda dapat mengaturnya ke nilai dalam rentang 0–8192, yang menentukan jumlah partisi yang akan diperiksa selama estimasi jumlah baris. Nilai default adalah 0, yang menentukan estimasi menggunakan semua partisi, sesuai dengan perilaku MySQL default. Parameter ini tersedia untuk Aurora MySQL versi 3.03.1 dan lebih tinggi. |
| `innodb_autoextend_increment` | Ya | Tidak ada |
| `innodb_buffer_pool_dump_at_shutdown` | Tidak | Tidak ada |
| `innodb_buffer_pool_dump_now` | Tidak | Tidak ada |
| `innodb_buffer_pool_filename` | Tidak | Tidak ada |
| `innodb_buffer_pool_load_abort` | Tidak | Tidak ada |
| `innodb_buffer_pool_load_at_startup` | Tidak | Tidak ada |
| `innodb_buffer_pool_load_now` | Tidak | Tidak ada |
| `innodb_buffer_pool_size` | Ya | Nilai default-nya direpresentasikan dengan rumus. Untuk detail tentang cara nilai `DBInstanceClassMemory` dalam rumus dihitung, lihat [Variabel formula parameter DB](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `innodb_change_buffer_max_size` | Tidak | Aurora MySQL tidak menggunakan buffer perubahan InnoDB sama sekali. |
| `innodb_compression_failure_threshold_pct` | Ya | Tidak ada |
| `innodb_compression_level` | Ya | Tidak ada |
| `innodb_compression_pad_pct_max` | Ya | Tidak ada |
| `innodb_concurrency_tickets` | Ya | Memodifikasi parameter ini tidak berdampak karena `innodb_thread_concurrency` selalu 0 untuk Aurora. |
| `innodb_deadlock_detect` | Ya | Opsi ini digunakan untuk menonaktifkan deteksi deadlock di Aurora MySQL versi 2.11 dan lebih tinggi serta versi 3. Pada sistem konkurensi tinggi, deteksi deadlock dapat menyebabkan perlambatan ketika banyak thread menunggu kunci yang sama. Baca dokumentasi MySQL untuk informasi selengkapnya tentang parameter ini. |
| `innodb_file_format` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `innodb_flushing_avg_loops` | Tidak | Tidak ada |
| `innodb_force_load_corrupted` | Tidak | Tidak ada |
| `innodb_ft_aux_table` | Ya | Tidak ada |
| `innodb_ft_cache_size` | Ya | Tidak ada |
| `innodb_ft_enable_stopword` | Ya | Tidak ada |
| `innodb_ft_server_stopword_table` | Ya | Tidak ada |
| `innodb_ft_user_stopword_table` | Ya | Tidak ada |
| `innodb_large_prefix` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `innodb_lock_wait_timeout` | Ya | Tidak ada |
| `innodb_log_compressed_pages` | Tidak | Tidak ada |
| `innodb_lru_scan_depth` | Ya | Tidak ada |
| `innodb_max_purge_lag` | Ya | Tidak ada |
| `innodb_max_purge_lag_delay` | Ya | Tidak ada |
| `innodb_monitor_disable` | Ya | Tidak ada |
| `innodb_monitor_enable` | Ya | Tidak ada |
| `innodb_monitor_reset` | Ya | Tidak ada |
| `innodb_monitor_reset_all` | Ya | Tidak ada |
| `innodb_old_blocks_pct` | Ya | Tidak ada |
| `innodb_old_blocks_time` | Ya | Tidak ada |
| `innodb_open_files` | Ya | Tidak ada |
| `innodb_print_all_deadlocks` | Ya | Saat diaktifkan, mencatat informasi tentang semua deadlock InnoDB di log kesalahan Aurora MySQL. Untuk informasi selengkapnya, lihat [Meminimalkan dan memecahkan masalah deadlock Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_random_read_ahead` | Ya | Tidak ada |
| `innodb_read_ahead_threshold` | Ya | Tidak ada |
| `innodb_read_io_threads` | Tidak | Tidak ada |
| `innodb_read_only` | Tidak | Aurora MySQL mengelola read-only dan read/write state instance DB berdasarkan jenis cluster. Misalnya, klaster yang disediakan memiliki satu instans read/write DB (instance *utama) dan instance* lain di cluster adalah hanya-baca (Replika Aurora). |
| `innodb_replication_delay` | Ya | Tidak ada |
| `innodb_sort_buffer_size` | Ya | Tidak ada |
| `innodb_stats_auto_recalc` | Ya | Tidak ada |
| `innodb_stats_method` | Ya | Tidak ada |
| `innodb_stats_on_metadata` | Ya | Tidak ada |
| `innodb_stats_persistent` | Ya | Tidak ada |
| `innodb_stats_persistent_sample_pages` | Ya | Tidak ada |
| `innodb_stats_transient_sample_pages` | Ya | Tidak ada |
| `innodb_thread_concurrency` | Tidak | Tidak ada |
| `innodb_thread_sleep_delay` | Ya | Memodifikasi parameter ini tidak berdampak karena `innodb_thread_concurrency` selalu 0 untuk Aurora. |
| `interactive_timeout` | Ya | Aurora mengevaluasi nilai minimum `interactive_timeout` dan `wait_timeout`. Kemudian, layanan ini menggunakan nilai minimum tersebut sebagai batas waktu untuk mengakhiri semua sesi idle, interaktif, dan non-interaktif. |
| `internal_tmp_disk_storage_engine` | Ya | Mengontrol mesin penyimpanan dalam memori mana yang digunakan untuk tabel sementara internal. Nilai yang diizinkan adalah `INNODB` dan `MYISAM`. Parameter ini berlaku untuk Aurora MySQL versi 2. |
| `internal_tmp_mem_storage_engine` | Terkadang | Mengontrol mesin penyimpanan dalam memori mana yang digunakan untuk tabel sementara internal. Nilai yang diizinkan untuk instance DB penulis adalah `MEMORY` dan`TempTable`. Untuk instance DB pembaca, parameter ini diatur ke `TempTable` dan tidak dapat dimodifikasi. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `join_buffer_size` | Ya | Tidak ada |
| `keep_files_on_create` | Ya | Tidak ada |
| `key_buffer_size` | Ya | Cache kunci untuk tabel MyISAM. Untuk informasi selengkapnya, lihat [mutex keycache->cache\$1lock](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `key_cache_age_threshold` | Ya | Tidak ada |
| `key_cache_block_size` | Ya | Tidak ada |
| `key_cache_division_limit` | Ya | Tidak ada |
| `local_infile` | Ya | Tidak ada |
| `lock_wait_timeout` | Ya | Tidak ada |
| `log-bin` | Tidak | Mengatur `binlog_format` ke `STATEMENT`, `MIXED`, atau `ROW` akan secara otomatis mengatur `log-bin` ke `ON`. Mengatur `binlog_format` ke `OFF` akan secara otomatis mengatur `log-bin` ke `OFF`. Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md). |
| `log_bin_trust_function_creators` | Ya | Tidak ada |
| `log_bin_use_v1_row_events` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `log_error` | Tidak | Tidak ada |
| `log_error_suppression_list` | Ya | Menentukan daftar kode kesalahan yang tidak login di log kesalahan MySQL. Ini memungkinkan Anda untuk mengabaikan kondisi kesalahan nonkritis tertentu untuk membantu menjaga log kesalahan Anda tetap bersih. Untuk informasi selengkapnya, lihat [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) di dokumentasi MySQL. Parameter ini berlaku untuk Aurora MySQL versi 3.03 dan lebih tinggi. |
| `log_output` | Ya | Tidak ada |
| `log_queries_not_using_indexes` | Ya | Tidak ada |
| `log_slave_updates` | Tidak | Aurora MySQL versi 2. Gunakan `log_replica_updates` di Aurora MySQL versi 3. |
| `log_replica_updates` | Tidak | Aurora MySQL versi 3 |
| `log_throttle_queries_not_using_indexes` | Ya | Tidak ada |
| `log_warnings` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `long_query_time` | Ya | Tidak ada |
| `low_priority_updates` | Ya | Operasi `INSERT`, `UPDATE`, `DELETE`, dan `LOCK TABLE WRITE` menunggu sampai tidak ada operasi `SELECT` yang tertunda. Parameter ini hanya memengaruhi mesin penyimpanan yang hanya menggunakan penguncian tingkat tabel (MyISAM, MEMORY, MERGE). Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `max_allowed_packet` | Ya | Tidak ada |
| `max_binlog_cache_size` | Ya | Tidak ada |
| `max_binlog_size` | Tidak | Tidak ada |
| `max_binlog_stmt_cache_size` | Ya | Tidak ada |
| `max_connect_errors` | Ya | Tidak ada |
| `max_connections` | Ya | Nilai default-nya direpresentasikan dengan rumus. Untuk detail tentang cara nilai `DBInstanceClassMemory` dalam rumus dihitung, lihat [Variabel formula parameter DB](USER_ParamValuesRef.md#USER_FormulaVariables). Untuk nilai default yang tergantung pada kelas instans, lihat [Koneksi maksimum ke instans DB Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). |
| `max_delayed_threads` | Ya | Mengatur jumlah maksimum thread untuk menangani pernyataan `INSERT DELAYED`. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `max_error_count` | Ya | Jumlah maksimum pesan kesalahan, peringatan, dan catatan yang akan disimpan untuk ditampilkan. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `max_execution_time` | Ya | Batas waktu untuk menjalankan pernyataan `SELECT`, dalam milidetik. Nilainya bisa berkisar `0`–`18446744073709551615`. Ketika diatur ke`0`, tidak ada batas waktu. Untuk informasi selengkapnya, lihat [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) dalam dokumentasi MySQL. |
| `max_heap_table_size` | Ya | Tidak ada |
| `max_insert_delayed_threads` | Ya | Tidak ada |
| `max_join_size` | Ya | Tidak ada |
| `max_length_for_sort_data` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `max_prepared_stmt_count` | Ya | Tidak ada |
| `max_seeks_for_key` | Ya | Tidak ada |
| `max_sort_length` | Ya | Tidak ada |
| `max_sp_recursion_depth` | Ya | Tidak ada |
| `max_tmp_tables` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `max_user_connections` | Ya | Tidak ada |
| `max_write_lock_count` | Ya | Tidak ada |
| `metadata_locks_cache_size` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `min_examined_row_limit` | Ya | Gunakan parameter ini agar kueri yang memeriksa lebih sedikit jumlah baris dari yang ditentukan tidak dicatat. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `myisam_data_pointer_size` | Ya | Tidak ada |
| `myisam_max_sort_file_size` | Ya | Tidak ada |
| `myisam_mmap_size` | Ya | Tidak ada |
| `myisam_sort_buffer_size` | Ya | Tidak ada |
| `myisam_stats_method` | Ya | Tidak ada |
| `myisam_use_mmap` | Ya | Tidak ada |
| `net_buffer_length` | Ya | Tidak ada |
| `net_read_timeout` | Ya | Tidak ada |
| `net_retry_count` | Ya | Tidak ada |
| `net_write_timeout` | Ya | Tidak ada |
| `old-style-user-limits` | Ya | Tidak ada |
| `old_passwords` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `optimizer_prune_level` | Ya | Tidak ada |
| `optimizer_search_depth` | Ya | Tidak ada |
| `optimizer_switch` | Ya | Untuk informasi tentang fitur Aurora MySQL yang menggunakan switch ini, lihat [Praktik terbaik dengan Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). |
| `optimizer_trace` | Ya | Tidak ada |
| `optimizer_trace_features` | Ya | Tidak ada |
| `optimizer_trace_limit` | Ya | Tidak ada |
| `optimizer_trace_max_mem_size` | Ya | Tidak ada |
| `optimizer_trace_offset` | Ya | Tidak ada |
| `performance-schema-consumer-events-waits-current` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance-schema-consumer-events-waits-current`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance-schema-instrument` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance-schema-instrument`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema` | Ya | Jika kolom **Sumber** disetel ke`Modified`, Performance Insights mengelola Skema Kinerja. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_accounts_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_accounts_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_global_instrumentation` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_global_instrumentation`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_thread_instrumentation` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_thread_instrumentation`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_stages_current` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_stages_current`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_stages_history` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_stages_history`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_stages_history_long` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_stages_history_long`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_statements_current` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_statements_current`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_statements_history` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_statements_history`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_statements_history_long` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_statements_history_long`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_waits_history` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_waits_history`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_events_waits_history_long` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_events_waits_history_long`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_consumer_statements_digest` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_consumer_statements_digest`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_digests_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_digests_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_stages_history_long_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_stages_history_long_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_stages_history_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_stages_history_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_statements_history_long_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_statements_history_long_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_statements_history_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_statements_history_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_transactions_history_long_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_transactions_history_long_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_transactions_history_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_transactions_history_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_waits_history_long_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_waits_history_long_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_events_waits_history_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_events_waits_history_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_hosts_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_hosts_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_cond_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_cond_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_cond_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_cond_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_digest_length` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_digest_length`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_file_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_file_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_file_handles` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_file_handles`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_file_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_file_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_index_stat` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_index_stat`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_memory_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_memory_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_metadata_locks` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_metadata_locks`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_mutex_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_mutex_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_mutex_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_mutex_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_prepared_statements_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_prepared_statements_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_program_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_program_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_rwlock_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_rwlock_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_rwlock_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_rwlock_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_socket_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_socket_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_socket_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_socket_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_sql_text_length` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_sql_text_length`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_stage_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_stage_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_statement_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_statement_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_statement_stack` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_statement_stack`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_table_handles` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_table_handles`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_table_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_table_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_table_lock_stat` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_table_lock_stat`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_thread_classes` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_thread_classes`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_max_thread_instances` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_max_thread_instances`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_session_connect_attrs_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_session_connect_attrs_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_setup_actors_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_setup_actors_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_setup_objects_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_setup_objects_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_show_processlist` | Ya | Parameter ini menentukan implementasi SHOW PROCESSLIST mana yang akan digunakan: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Parameter ini berlaku untuk Aurora MySQL versi 2.12 dan lebih tinggi, serta versi 3. Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_show_processlist`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `performance_schema_users_size` | Ya | Jika kolom **Sumber** untuk parameter `performance_schema` diatur ke`Modified`, skema kinerja menggunakan parameter`performance_schema_users_size`. Untuk informasi selengkapnya tentang mengaktifkan Skema Kinerja, lihat. [Menentukan apakah Wawasan Performa mengelola Skema Performa](USER_PerfInsights.EnableMySQL.determining-status.md) |
| `pid_file` | Tidak | Tidak ada |
| `plugin_dir` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `port` | Tidak | Aurora MySQL mengelola properti koneksi dan memberlakukan pengaturan yang konsisten untuk semua instans DB dalam klaster. |
| `preload_buffer_size` | Ya | Ukuran buffer yang dialokasikan saat melakukan pra-pemuatan indeks. Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `profiling_history_size` | Ya | Tidak ada |
| `query_alloc_block_size` | Ya | Tidak ada |
| `query_cache_limit` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `query_cache_min_res_unit` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `query_cache_size` | Ya | Nilai default-nya direpresentasikan dengan rumus. Untuk detail tentang cara nilai `DBInstanceClassMemory` dalam rumus dihitung, lihat [Variabel formula parameter DB](USER_ParamValuesRef.md#USER_FormulaVariables). Dihapus dari Aurora MySQL versi 3. |
| `query_cache_type` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `query_cache_wlock_invalidate` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `query_prealloc_size` | Ya | Tidak ada |
| `range_alloc_block_size` | Ya | Tidak ada |
| `read_buffer_size` | Ya | Tidak ada |
| `read_only` | Ya | Ketika parameter ini diaktifkan, server tidak mengizinkan pembaruan kecuali dari yang dilakukan oleh thread replika. Untuk Aurora MySQL versi 2, nilai yang valid adalah sebagai berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Kami menyarankan Anda menggunakan grup parameter klaster DB di Aurora MySQL versi 2 untuk memastikan bahwa parameter `read_only` diterapkan ke instans penulis baru pada saat failover. Instans pembaca selalu berstatus hanya baca karena Aurora MySQL mengatur `innodb_read_only` ke `1` di semua pembaca. Oleh karena itu, `read_only` menjadi redundan di instans pembaca. Dihapus pada tingkat instans dari Aurora MySQL versi 3. |
| `read_rnd_buffer_size` | Ya | Tidak ada |
| `relay-log` | Tidak | Tidak ada |
| `relay_log_info_repository` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `relay_log_recovery` | Tidak | Tidak ada |
| `replica_checkpoint_group` | Ya | Aurora MySQL versi 3 |
| `replica_checkpoint_period` | Ya | Aurora MySQL versi 3 |
| `replica_parallel_workers` | Ya | Aurora MySQL versi 3 |
| `replica_pending_jobs_size_max` | Ya | Aurora MySQL versi 3 |
| `replica_skip_errors` | Ya | Aurora MySQL versi 3 |
| `replica_sql_verify_checksum` | Ya | Aurora MySQL versi 3 |
| `safe-user-create` | Ya | Tidak ada |
| `secure_auth` | Ya | Parameter ini selalu diaktifkan di Aurora MySQL versi 2. Percobaan untuk menonaktifkannya akan menghasilkan kesalahan. Dihapus dari Aurora MySQL versi 3. |
| `secure_file_priv` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `show_create_table_verbosity` | Ya | Pengaktifan variabel ini menyebabkan [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) menampilkan `ROW_FORMAT` terlepas dari apakah format ini merupakan format default. Parameter ini berlaku untuk Aurora MySQL versi 2.12 dan lebih tinggi, serta versi 3. |
| `skip-slave-start` | Tidak | Tidak ada |
| `skip_external_locking` | Tidak | Tidak ada |
| `skip_show_database` | Ya | Tidak ada |
| `slave_checkpoint_group` | Ya | Aurora MySQL versi 2. Gunakan `replica_checkpoint_group` di Aurora MySQL versi 3. |
| `slave_checkpoint_period` | Ya | Aurora MySQL versi 2. Gunakan `replica_checkpoint_period` di Aurora MySQL versi 3. |
| `slave_parallel_workers` | Ya | Aurora MySQL versi 2. Gunakan `replica_parallel_workers` di Aurora MySQL versi 3. |
| `slave_pending_jobs_size_max` | Ya | Aurora MySQL versi 2. Gunakan `replica_pending_jobs_size_max` di Aurora MySQL versi 3. |
| `slave_sql_verify_checksum` | Ya | Aurora MySQL versi 2. Gunakan `replica_sql_verify_checksum` di Aurora MySQL versi 3. |
| `slow_launch_time` | Ya | Tidak ada |
| `slow_query_log` | Ya | Untuk petunjuk tentang mengunggah log ke CloudWatch Log, lihat[Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). |
| `slow_query_log_file` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `socket` | Tidak | Tidak ada |
| `sort_buffer_size` | Ya | Tidak ada |
| `sql_mode` | Ya | Tidak ada |
| `sql_select_limit` | Ya | Tidak ada |
| `stored_program_cache` | Ya | Tidak ada |
| `sync_binlog` | Tidak | Tidak ada |
| `sync_master_info` | Ya | Tidak ada |
| `sync_source_info` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. |
| `sync_relay_log` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `sync_relay_log_info` | Ya | Tidak ada |
| `sysdate-is-now` | Ya | Tidak ada |
| `table_cache_element_entry_ttl` | Tidak | Tidak ada |
| `table_definition_cache` | Ya | Nilai default-nya direpresentasikan dengan rumus. Untuk detail tentang cara nilai `DBInstanceClassMemory` dalam rumus dihitung, lihat [Variabel formula parameter DB](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache` | Ya | Nilai default-nya direpresentasikan dengan rumus. Untuk detail tentang cara nilai `DBInstanceClassMemory` dalam rumus dihitung, lihat [Variabel formula parameter DB](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache_instances` | Ya | Tidak ada |
| `temp-pool` | Ya | Dihapus dari Aurora MySQL versi 3. |
| `temptable_max_mmap` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. Untuk detailnya, lihat [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md). |
| `temptable_max_ram` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. Untuk detailnya, lihat [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md). |
| `temptable_use_mmap` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. Untuk detailnya, lihat [Perilaku tabel sementara baru di Aurora MySQL versi 3](ams3-temptable-behavior.md). |
| `thread_cache_size` | Ya | Jumlah thread yang akan di-cache. Parameter ini berlaku untuk Aurora MySQL versi 2 dan 3. |
| `thread_handling` | Tidak | Tidak ada |
| `thread_stack` | Ya | Tidak ada |
| `timed_mutexes` | Ya | Tidak ada |
| `tmp_table_size` | Ya | Mendefinisikan ukuran maksimum tabel sementara dalam memori internal yang dibuat oleh mesin penyimpanan `MEMORY` di Aurora MySQL versi 3. Di Aurora MySQL versi 3.04 dan yang lebih tinggi, mendefinisikan ukuran maksimum tabel sementara dalam memori internal yang dibuat oleh mesin penyimpanan `TempTable` saat `aurora_tmptable_enable_per_table_limit` adalah `ON`. Untuk informasi selengkapnya, lihat [Membatasi ukuran tabel sementara internal dalam memori](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `tmpdir` | Tidak | Aurora MySQL menggunakan instans terkelola dengan sistem file yang tidak dapat Anda akses secara langsung. |
| `transaction_alloc_block_size` | Ya | Tidak ada |
| `transaction_isolation` | Ya | Parameter ini berlaku untuk Aurora MySQL versi 3. Parameter ini menggantikan `tx_isolation`. |
| `transaction_prealloc_size` | Ya | Tidak ada |
| `tx_isolation` | Ya | Dihapus dari Aurora MySQL versi 3. Parameter ini digantikan oleh `transaction_isolation`. |
| `updatable_views_with_limit` | Ya | Tidak ada |
| `validate-password` | Tidak | Tidak ada |
| `validate_password_dictionary_file` | Tidak | Tidak ada |
| `validate_password_length` | Tidak | Tidak ada |
| `validate_password_mixed_case_count` | Tidak | Tidak ada |
| `validate_password_number_count` | Tidak | Tidak ada |
| `validate_password_policy` | Tidak | Tidak ada |
| `validate_password_special_char_count` | Tidak | Tidak ada |
| `wait_timeout` | Ya | Aurora mengevaluasi nilai minimum `interactive_timeout` dan `wait_timeout`. Kemudian, layanan ini menggunakan nilai minimum tersebut sebagai batas waktu untuk mengakhiri semua sesi idle, interaktif, dan non-interaktif. |
## Parameter MySQL yang tidak berlaku untuk Aurora MySQL
Karena perbedaan arsitektur antara Aurora MySQL dan MySQL, sebagian parameter MySQL tidak berlaku untuk Aurora MySQL.
Parameter MySQL berikut tidak berlaku untuk Aurora MySQL: Daftar ini tidak lengkap.
+ `activate_all_roles_on_login` – Parameter ini tidak berlaku untuk Aurora MySQL versi 2. Parameter ini tersedia di Aurora MySQL versi 3.
+ `big_tables`
+ `bind_address`
+ `character_sets_dir`
+ `innodb_adaptive_flushing`
+ `innodb_adaptive_flushing_lwm`
+ `innodb_buffer_pool_chunk_size`
+ `innodb_buffer_pool_instances`
+ `innodb_change_buffering`
+ `innodb_checksum_algorithm`
+ `innodb_data_file_path`
+ `innodb_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout` – Parameter ini tidak berlaku untuk Aurora MySQL. Lihat informasi yang lebih lengkap di [Mengonfigurasi seberapa sering buffer log di-flush](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush).
+ `innodb_flush_method`
+ `innodb_flush_neighbors`
+ `innodb_io_capacity`
+ `innodb_io_capacity_max`
+ `innodb_log_buffer_size`
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ `innodb_log_spin_cpu_abs_lwm`
+ `innodb_log_spin_cpu_pct_hwm`
+ `innodb_log_writer_threads`
+ `innodb_max_dirty_pages_pct`
+ `innodb_numa_interleave`
+ `innodb_page_size`
+ `innodb_redo_log_capacity`
+ `innodb_redo_log_encrypt`
+ `innodb_undo_log_encrypt`
+ `innodb_undo_log_truncate`
+ `innodb_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Variabel status global Aurora MySQL
Aurora MySQL mencakup variabel status dari MySQL komunitas dan variabel yang unik untuk Aurora. Anda dapat memeriksa variabel-variabel ini untuk mempelajari tentang apa yang terjadi di dalam mesin database. Untuk informasi selengkapnya tentang variabel status di MySQL komunitas, [lihat Variabel Status Server](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) dalam dokumentasi MySQL 8.0 komunitas.
Anda dapat menemukan nilai saat ini untuk variabel status global Aurora MySQL dengan menggunakan pernyataan seperti berikut:
```
show global status like '%aurora%';
```
**catatan**
Variabel status global dihapus saat mesin DB reboot.
Tabel berikut menjelaskan variabel status global yang digunakan Aurora MySQL.
| Nama | Deskripsi |
| --- | --- |
| `AuroraDb_commits` | Jumlah total commit sejak pengaktifan ulang terakhir. |
| `AuroraDb_commit_latency` | Latensi commit agregat sejak pengaktifan ulang terakhir. |
| `AuroraDb_ddl_stmt_duration` | Latensi DDL agregat sejak pengaktifan ulang terakhir. |
| `AuroraDb_select_stmt_duration` | Latensi pernyataan `SELECT` agregat sejak pengaktifan ulang terakhir. |
| `AuroraDb_insert_stmt_duration` | Latensi pernyataan `INSERT` agregat sejak pengaktifan ulang terakhir. |
| `AuroraDb_update_stmt_duration` | Latensi pernyataan `UPDATE` agregat sejak pengaktifan ulang terakhir. |
| `AuroraDb_delete_stmt_duration` | Latensi pernyataan `DELETE` agregat sejak pengaktifan ulang terakhir. |
| `Aurora_binlog_io_cache_allocated` | Jumlah byte yang dialokasikan ke cache I/O binlog. |
| `Aurora_binlog_io_cache_read_requests` | Jumlah permintaan baca yang dibuat ke I/O cache binlog. |
| `Aurora_binlog_io_cache_reads` | Jumlah permintaan baca yang disajikan dari I/O cache binlog. |
| `Aurora_enhanced_binlog` | Menunjukkan apakah binlog yang ditingkatkan diaktifkan atau dinonaktifkan untuk instans DB ini. Untuk informasi selengkapnya, lihat [Menyiapkan binlog yang disempurnakan untuk Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `Aurora_external_connection_count` | Jumlah koneksi basis data ke instans DB, tidak termasuk koneksi layanan RDS yang digunakan untuk pemeriksaan kondisi basis data. |
| `Aurora_fast_insert_cache_hits` | Penghitung yang bertambah saat kursor yang di-cache berhasil diambil dan diverifikasi. Untuk informasi selengkapnya tentang cache penyisipan cepat, lihat [Peningkatan performa Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `Aurora_fast_insert_cache_misses` | Penghitung yang bertambah saat kursor yang di-cache tidak lagi valid dan Aurora melakukan penjelajahan indeks normal. Untuk informasi selengkapnya tentang cache penyisipan cepat, lihat [Peningkatan performa Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `Aurora_fts_cache_memory_used` | Jumlah memori dalam byte yang digunakan sistem pencarian teks lengkap InnoDB. Variabel ini berlaku untuk Aurora MySQL versi 3.07 dan lebih tinggi. |
| `Aurora_fwd_master_dml_stmt_count` | Total jumlah laporan DML yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 2. |
| `Aurora_fwd_master_dml_stmt_duration` | Total durasi laporan DML yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 2. |
| `Aurora_fwd_master_errors_rpc_timeout` | Berapa kali koneksi yang diteruskan gagal dibuat pada penulis. |
| `Aurora_fwd_master_errors_session_limit` | Jumlah kueri yang diteruskan yang ditolak karena `session full` pada penulis. |
| `Aurora_fwd_master_errors_session_timeout` | Berapa kali sesi penerusan berakhir karena batas waktu pada penulis. |
| `Aurora_fwd_master_open_sessions` | Jumlah sesi yang diteruskan pada instans DB penulis. Variabel ini berlaku untuk Aurora MySQL versi 2. |
| `Aurora_fwd_master_select_stmt_count` | Total jumlah pernyataan `SELECT` yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 2. |
| `Aurora_fwd_master_select_stmt_duration` | Total durasi pernyataan `SELECT` yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 2. |
| `Aurora_fwd_writer_dml_stmt_count` | Total jumlah laporan DML yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 3. |
| `Aurora_fwd_writer_dml_stmt_duration` | Total durasi laporan DML yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 3. |
| `Aurora_fwd_writer_errors_rpc_timeout` | Berapa kali koneksi yang diteruskan gagal dibuat pada penulis. |
| `Aurora_fwd_writer_errors_session_limit` | Jumlah kueri yang diteruskan yang ditolak karena `session full` pada penulis. |
| `Aurora_fwd_writer_errors_session_timeout` | Berapa kali sesi penerusan berakhir karena batas waktu pada penulis. |
| `Aurora_fwd_writer_open_sessions` | Jumlah sesi yang diteruskan pada instans DB penulis. Variabel ini berlaku untuk Aurora MySQL versi 3. |
| `Aurora_fwd_writer_select_stmt_count` | Total jumlah pernyataan `SELECT` yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 3. |
| `Aurora_fwd_writer_select_stmt_duration` | Total durasi pernyataan `SELECT` yang diteruskan ke DB instans penulis ini. Variabel ini berlaku untuk Aurora MySQL versi 3. |
| `Aurora_lockmgr_buffer_pool_memory_used` | Jumlah memori kolam buffer dalam byte yang digunakan oleh pengelola kunci MySQL Aurora. |
| `Aurora_lockmgr_memory_used` | Jumlah memori dalam byte yang digunakan oleh pengelola kunci Aurora MySQL. |
| `Aurora_ml_actual_request_cnt` | Permintaan agregat menghitung bahwa Aurora SQLmakes My ke layanan pembelajaran mesin Aurora di semua kueri yang dijalankan oleh pengguna instans DB. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_actual_response_cnt` | Jumlah respons agregat yang diterima Aurora MySQL dari layanan machine learning Aurora di semua kueri yang dijalankan oleh pengguna instans DB. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_cache_hit_cnt` | Jumlah hit cache internal agregat yang diterima Aurora MySQL dari layanan machine learning Aurora di semua kueri yang dijalankan oleh pengguna instans DB. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_request_cnt` | Jumlah permintaan logis yang telah dievaluasi instans DB untuk dikirim ke layanan machine learning Aurora sejak reset status terakhir. Tergantung pada apakah batching telah digunakan, nilai ini dapat lebih tinggi dari `Aurora_ml_actual_request_cnt`. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_response_cnt` | Jumlah respons agregat yang diterima Aurora MySQL dari layanan machine learning Aurora di semua kueri yang dijalankan oleh pengguna instans DB. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_retry_request_cnt` | Jumlah permintaan yang dicoba ulang yang dikirim instans DB ke layanan machine learning Aurora sejak reset status terakhir. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_single_request_cnt` | Jumlah agregat fungsi machine learning Aurora yang dievaluasi oleh mode non-batch di semua kueri yang dijalankan oleh pengguna instans DB. Untuk informasi selengkapnya, lihat [Menggunakan machine learning Amazon Aurora dengan Aurora MySQL](mysql-ml.md). |
| `aurora_oom_avoidance_recovery_state` | Menunjukkan apakah pemulihan penghindaran Aurora out-of-memory (OOM) berada dalam `INACTIVE` keadaan `ACTIVE` atau untuk instans DB ini. Variabel ini berlaku untuk Aurora MySQL versi 3.06.0 dan lebih tinggi. |
| `aurora_oom_reserved_mem_enter_kb` | Merupakan ambang batas untuk memasuki `RESERVED` negara bagian dalam mekanisme penanganan OOM Aurora. Ketika memori yang tersedia di server jatuh di bawah ambang batas ini`RESERVED`, `aurora_oom_status` perubahan ke, menunjukkan bahwa server mendekati tingkat kritis penggunaan memori. Variabel ini berlaku untuk Aurora MySQL versi 3.06.0 dan lebih tinggi. |
| `aurora_oom_reserved_mem_exit_kb` | Merupakan ambang batas untuk keluar dari `RESERVED` negara bagian dalam mekanisme penanganan OOM Aurora. Ketika memori yang tersedia di server naik di atas ambang batas ini, `aurora_oom_status` kembali ke`NORMAL`, menunjukkan bahwa server telah kembali ke keadaan yang lebih stabil dengan sumber daya memori yang cukup. Variabel ini berlaku untuk Aurora MySQL versi 3.06.0 dan lebih tinggi. |
| `aurora_oom_status` | Merupakan status OOM saat ini dari instance DB ini. Ketika nilainya`NORMAL`, ini menunjukkan bahwa ada sumber daya memori yang cukup. Jika nilainya berubah`RESERVED`, ini menunjukkan bahwa server memiliki memori yang tersedia rendah. Tindakan diambil berdasarkan konfigurasi `aurora_oom_response` parameter. Untuk informasi selengkapnya, lihat [Memecahkan out-of-memory masalah untuk database Aurora MySQL](AuroraMySQLOOM.md). Variabel ini berlaku untuk Aurora MySQL versi 3.06.0 dan lebih tinggi. |
| `Aurora_pq_bytes_returned` | Jumlah byte untuk struktur data tuple yang ditransmisikan ke simpul head selama kueri paralel. Bagi dengan 16.384 untuk membandingkan dengan `Aurora_pq_pages_pushed_down`. |
| `Aurora_pq_max_concurrent_requests` | Jumlah maksimum sesi kueri paralel yang dapat berjalan secara konkuren di instans Aurora DB ini. Ini adalah nomor tetap yang tergantung pada kelas instans AWS DB. |
| `Aurora_pq_pages_pushed_down` | Jumlah halaman data (masing-masing dengan ukuran tetap 16 KiB) tempat kueri paralel menghindari transmisi jaringan ke simpul head. |
| `Aurora_pq_request_attempted` | Jumlah sesi kueri paralel yang diminta. Nilai ini dapat menunjukkan lebih dari satu sesi per kueri, bergantung pada konsep SQL seperti subkueri dan penggabungan. |
| `Aurora_pq_request_executed` | Jumlah sesi kueri paralel yang berhasil berjalan. |
| `Aurora_pq_request_failed` | Jumlah sesi kueri paralel yang menampilkan kesalahan kepada klien. Dalam beberapa kasus, permintaan untuk kueri paralel mungkin gagal, misalnya karena masalah dalam lapisan penyimpanan. Dalam kasus ini, bagian kueri yang gagal dicoba kembali menggunakan mekanisme kueri nonparalel. Jika kueri yang dicoba kembali juga gagal, kesalahan ditampilkan ke klien dan penghitung ini ditambah. |
| `Aurora_pq_request_in_progress` | Jumlah sesi kueri paralel yang sedang berlangsung. Angka ini berlaku untuk instans Aurora DB tertentu yang Anda hubungkan, bukan seluruh klaster Aurora DB. Untuk melihat apakah instans DB mendekati batas konkurensinya, bandingkan nilai ini dengan `Aurora_pq_max_concurrent_requests`. |
| `Aurora_pq_request_not_chosen` | Berapa kali kueri paralel tidak dipilih untuk memenuhi suatu kueri. Nilai ini adalah jumlah dari beberapa penghitung granular lainnya. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan. |
| `Aurora_pq_request_not_chosen_below_min_rows` | Berapa kali kueri paralel tidak dipilih karena jumlah baris dalam tabel. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan. |
| `Aurora_pq_request_not_chosen_column_bit` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena jenis data yang tidak didukung dalam daftar kolom yang diproyeksikan. |
| `Aurora_pq_request_not_chosen_column_geometry` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan jenis data `GEOMETRY`. Untuk informasi tentang versi Aurora MySQL yang menghapus batasan ini, lihat [Memutakhirkan cluster kueri paralel ke Aurora Versi saya 3 SQL](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). |
| `Aurora_pq_request_not_chosen_column_lob` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan jenis data `LOB`, atau kolom `VARCHAR` yang disimpan secara eksternal karena panjang yang dinyatakan. Untuk informasi tentang versi Aurora MySQL yang menghapus batasan ini, lihat [Memutakhirkan cluster kueri paralel ke Aurora Versi saya 3 SQL](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). |
| `Aurora_pq_request_not_chosen_column_virtual` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel berisi kolom virtual. |
| `Aurora_pq_request_not_chosen_custom_charset` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan set karakter kustom. |
| `Aurora_pq_request_not_chosen_fast_ddl` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel saat ini sedang diubah oleh pernyataan `ALTER` DDL cepat. |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | Berapa kali kueri paralel tidak dipilih, meskipun kurang dari 95 persen data tabel berada di dalam pool buffer, karena data tabel yang tidak di-buffer tidak cukup untuk membuat kueri paralel layak dijalankan. |
| `Aurora_pq_request_not_chosen_full_text_index` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki indeks teks penuh. |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | Berapa kali kueri paralel tidak dipilih karena persentase tinggi data tabel (saat ini, lebih dari 95 persen) sudah berada di dalam pool buffer. Dalam kasus ini, pengoptimal menentukan bahwa membaca data dari pool buffer akan lebih efisien. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan. |
| `Aurora_pq_request_not_chosen_index_hint` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri mencakup petunjuk indeks. |
| `Aurora_pq_request_not_chosen_innodb_table_format` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel menggunakan format baris InnoDB yang tidak didukung. Kueri paralel Aurora hanya berlaku untuk format baris `COMPACT`, `REDUNDANT`, dan `DYNAMIC`. |
| `Aurora_pq_request_not_chosen_long_trx` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri dimulai di dalam transaksi yang berjalan lama. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan. |
| `Aurora_pq_request_not_chosen_no_where_clause` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri tidak mencakup klausa `WHERE` apa pun. |
| `Aurora_pq_request_not_chosen_range_scan` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri menggunakan pemindaian rentang pada indeks. |
| `Aurora_pq_request_not_chosen_row_length_too_long` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena total panjang gabungan semua kolom terlalu panjang. |
| `Aurora_pq_request_not_chosen_small_table` | Berapa kali kueri paralel tidak dipilih karena ukuran keseluruhan tabel, sebagaimana ditentukan oleh jumlah baris dan rata-rata panjang baris. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan. |
| `Aurora_pq_request_not_chosen_temporary_table` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri mengacu pada tabel sementara yang menggunakan jenis tabel `MyISAM` atau `memory` yang tidak didukung. |
| `Aurora_pq_request_not_chosen_tx_isolation` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri menggunakan tingkat isolasi transaksi yang tidak didukung. Pada instans pembaca DB, kueri paralel hanya berlaku untuk tingkat isolasi `REPEATABLE READ` dan `READ COMMITTED`. |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri adalah bagian dari pernyataan `UPDATE` atau `DELETE`. |
| `Aurora_pq_request_not_chosen_unsupported_access` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena klausa `WHERE` tidak memenuhi kriteria untuk kueri paralel. Hasil ini dapat muncul jika kueri tidak memerlukan pemindaian sarat data, atau jika kueri adalah pernyataan `DELETE` atau `UPDATE`. |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena klaster DB Aurora MySQL tidak menggunakan konfigurasi penyimpanan klaster Aurora yang didukung. Untuk informasi selengkapnya, lihat [Pembatasan](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Parameter ini berlaku untuk Aurora MySQL versi 3.04 dan lebih tinggi. |
| `Aurora_pq_request_throttled` | Berapa kali kueri paralel tidak dipilih karena jumlah maksimum kueri paralel konkuren sudah berjalan pada instans Aurora DB tertentu. |
| `Aurora_repl_bytes_received` | Jumlah byte yang direplikasi ke instans basis data pembaca Aurora MySQL sejak pengaktifan ulang terakhir. Untuk informasi selengkapnya, lihat [Replikasi dengan Amazon Aurora MySQL](AuroraMySQL.Replication.md). |
| `Aurora_reserved_mem_exceeded_incidents` | Berapa kali sejak pengaktifan ulang terakhir bahwa mesin telah melampaui batas memori yang digunakan sistem. Jika `aurora_oom_response` dikonfigurasi, ambang batas ini menentukan kapan aktivitas penghindaran out-of-memory (OOM) dipicu. Untuk informasi selengkapnya tentang respons OOM Aurora MySQL, lihat [Memecahkan out-of-memory masalah untuk database Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_temptable_max_ram_allocation` | Jumlah maksimum memori, dalam byte, digunakan pada setiap titik oleh tabel sementara internal sejak restart terakhir. |
| `aurora_temptable_ram_allocation` | Jumlah memori saat ini, dalam byte, digunakan oleh tabel sementara internal. |
| `Aurora_in_memory_relaylog_status` | Status saat ini dalam fitur log relai memori, nilainya dapat DIAKTIFKAN atau DINONAKTIFKAN. |
| `Aurora_in_memory_relaylog_disabled_reason` | Menunjukkan alasan status fitur log relay memori saat ini, jika fitur dinonaktifkan, tampilkan pesan penjelasan tentang mengapa fitur dinonaktifkan. |
| `Aurora_in_memory_relaylog_fallback_count` | Tampilkan jumlah total fallback fitur log relai memori ke mode log relai persisten (lama). Fallback dapat disebabkan oleh peristiwa tunggal yang lebih besar dari ukuran cache (saat ini 128MB) atau percobaan ulang transaksi melebihi batas percobaan ulang transaksi replika replica\$1transaction\$1retries. |
| `Aurora_in_memory_relaylog_recovery_count` | Menunjukkan jumlah total pemulihan log relai memori yang dilakukan secara otomatis. Hitungan ini mencakup jumlah total fallback dan jumlah sakelar mode otomatis kembali ke dalam mode log relai memori setelah fallback sementara. |
| `Aurora_thread_pool_thread_count` | Jumlah thread saat ini di pool thread Aurora. Untuk informasi selengkapnya tentang pool thread di Aurora MySQL, lihat [Pool thread](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). |
| `Aurora_tmz_version` | Menunjukkan versi informasi zona waktu saat ini yang digunakan oleh klaster DB. Nilai ini mengikuti format Internet Assigned Numbers Authority (IANA): `YYYYsuffix`, misalnya `2022a` dan `2023c`. Parameter ini berlaku untuk Aurora MySQL versi 2.12 dan lebih tinggi, serta versi 3.04 dan lebih tinggi. |
| `Aurora_zdr_oom_threshold` | Merupakan ambang memori, dalam kilobyte (KB), untuk instance Aurora DB untuk memulai restart waktu henti nol (ZDR) untuk memulihkan dari potensi masalah terkait memori. |
| `server_aurora_das_running` | Menunjukkan apakah Stream Aktivitas Basis Data (DAS) diaktifkan atau dinonaktifkan pada instans DB ini. Untuk informasi selengkapnya, lihat [Memantau Amazon Aurora dengan Aliran Aktivitas Basis Data](DBActivityStreams.md). |
## Variabel status MySQL yang tidak berlaku untuk Aurora MySQL
Karena perbedaan arsitektur antara Aurora MySQL dan MySQL, sebagian variabel status MySQL tidak berlaku untuk Aurora MySQL.
Variabel status MySQL berikut tidak berlaku untuk Aurora MySQL: Daftar ini tidak lengkap.
+ `innodb_buffer_pool_bytes_dirty`
+ `innodb_buffer_pool_pages_dirty`
+ `innodb_buffer_pool_pages_flushed`
Aurora MySQL versi 3 menghapus variabel status berikut yang ada di Aurora MySQL versi 2:
+ `AuroraDb_lockmgr_bitmaps0_in_use`
+ `AuroraDb_lockmgr_bitmaps1_in_use`
+ `AuroraDb_lockmgr_bitmaps_mem_used`
+ `AuroraDb_thread_deadlocks`
+ `available_alter_table_log_entries`
+ `Aurora_lockmgr_memory_used`
+ `Aurora_missing_history_on_replica_incidents`
+ `Aurora_new_lock_manager_lock_release_cnt`
+ `Aurora_new_lock_manager_lock_release_total_duration_micro`
+ `Aurora_new_lock_manager_lock_timeout_cnt`
+ `Aurora_total_op_memory`
+ `Aurora_total_op_temp_space`
+ `Aurora_used_alter_table_log_entries`
+ `Aurora_using_new_lock_manager`
+ `Aurora_volume_bytes_allocated`
+ `Aurora_volume_bytes_left_extent`
+ `Aurora_volume_bytes_left_total`
+ `Com_alter_db_upgrade`
+ `Compression`
+ `External_threads_connected`
+ `Innodb_available_undo_logs`
+ `Last_query_cost`
+ `Last_query_partial_plans`
+ `Slave_heartbeat_period`
+ `Slave_last_heartbeat`
+ `Slave_received_heartbeats`
+ `Slave_retried_transactions`
+ `Slave_running`
+ `Time_since_zero_connections`
Variabel status MySQL ini tersedia di Aurora MySQL versi 2, tetapi tidak tersedia di Aurora MySQL versi 3:
+ `Innodb_redo_log_enabled`
+ `Innodb_undo_tablespaces_total`
+ `Innodb_undo_tablespaces_implicit`
+ `Innodb_undo_tablespaces_explicit`
+ `Innodb_undo_tablespaces_active`
# Peristiwa tunggu Aurora MySQL
Berikut ini adalah beberapa peristiwa tunggu umum di Aurora MySQL.
**catatan**
Untuk informasi tentang menyesuaikan performa Aurora MySQL menggunakan peristiwa tunggu, lihat [Menyesuaikan Aurora MySQL dengan peristiwa tunggu](AuroraMySQL.Managing.Tuning.wait-events.md).
Untuk informasi tentang konvensi penamaan yang digunakan dalam peristiwa tunggu MySQL, lihat [Performance Schema instrument naming conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) dalam dokumentasi MySQL.
**cpu**
Jumlah koneksi aktif yang siap dijalankan secara konsisten lebih tinggi daripada jumlah vCPUs. Untuk informasi lebih lanjut, lihat[cpu](ams-waits.cpu.md).
**io/aurora\$1redo\$1log\$1flush**
Sesi mempersistensi data ke penyimpanan Aurora. Biasanya, peristiwa tunggu ini ditujukan untuk operasi I/O tulis di Aurora MySQL. Untuk informasi selengkapnya, lihat [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
**io/aurora\$1respond\$1to\$1client**
Pemrosesan kueri telah selesai dan hasilnya ditampilkan ke klien aplikasi untuk versi MySQL Aurora berikut: 2.10.2 dan versi 2.10 yang lebih tinggi, versi 2.09.3 dan versi 2.09 yang lebih tinggi, serta versi 2.07.7 dan versi 2.07 yang lebih tinggi. Bandingkan bandwidth jaringan kelas instans DB dengan ukuran set hasil yang ditampilkan. Selain itu, periksa waktu respons sisi klien. Jika klien tidak responsif dan tidak dapat memproses paket TCP, penghapusan paket dan transmisi ulang TCP dapat terjadi. Situasi ini berdampak negatif pada bandwidth jaringan. Dalam versi yang lebih rendah dari 2.10.2, 2.09.3, dan 2.07.7, peristiwa tunggu secara keliru menyertakan waktu idle. Untuk mempelajari cara menyesuaikan basis data Anda saat peristiwa waktu tunggu ini sering muncul, lihat [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md).
**io/file/csv/data**
Thread menulis ke tabel dalam format nilai yang dipisahkan koma (CSV). Periksa penggunaan tabel CSV Anda. Penyebab umum peristiwa ini adalah mengatur `log_output` pada tabel.
**io/file/sql/binlog**
Thread sedang menunggu file log biner (binlog) yang sedang ditulis ke disk.
**io/redo\$1log\$1flush**
Sesi mempersistensi data ke penyimpanan Aurora. Biasanya, acara tunggu ini adalah untuk I/O operasi tulis di Aurora MySQL. Untuk informasi selengkapnya, lihat [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
**io/socket/sql/client\$1koneksi**
Program `mysqld` sibuk membuat thread untuk menangani koneksi klien baru yang masuk. Untuk informasi selengkapnya, lihat [io/socket/sql/client\$1koneksi](ams-waits.client-connection.md).
**io/table/sql/handler**
Mesin sedang menunggu akses ke tabel. Peristiwa ini terjadi terlepas dari apakah data di-cache di pool buffer atau diakses pada disk. Untuk informasi selengkapnya, lihat [io/table/sql/handler](ams-waits.waitio.md).
**lock/table/sql/handler**
Peristiwa tunggu ini adalah handler peristiwa tunggu kunci tabel. Untuk informasi selengkapnya tentang peristiwa atom dan molekul di Skema Performa, lihat [Performance Schema atom and molecule events](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html) dalam dokumentasi MySQL.
**synch/cond/innodb/row\$1lock\$1tunggu**
Pernyataan bahasa manipulasi data (DML) mengakses baris basis data yang sama pada saat yang bersamaan. Untuk informasi selengkapnya, lihat [synch/cond/innodb/row\$1lock\$1tunggu](ams-waits.row-lock-wait.md).
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
Beberapa pernyataan DML mengakses baris basis data yang sama secara bersamaan. Untuk informasi selengkapnya, lihat [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md).
**synch/cond/sql/MDL\$1konteks: :cond\$1wait\$1status**
Thread sedang menunggu kunci metadata tabel. Mesin menggunakan jenis kunci ini untuk mengelola akses konkuren ke skema basis data dan untuk memastikan konsistensi data. Untuk informasi selengkapnya, lihat [Optimizing locking operations](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) dalam dokumentasi MySQL. Untuk mempelajari cara menyesuaikan basis data Anda saat peristiwa ini sering muncul, lihat [synch/cond/sql/MDL\$1konteks: :cond\$1wait\$1status](ams-waits.cond-wait-status.md).
**synch/cond/sql/MYSQL\$1BIN\$1LOG: :COND\$1DONE**
Anda telah mengaktifkan pencatatan log biner. Mungkin ada throughput commit yang tinggi, transaksi dalam jumlah besar yang di-commit, atau replika yang membaca binlog. Pertimbangkan untuk menggunakan pernyataan multibaris atau menggabungkan pernyataan ke dalam satu transaksi. Di Aurora, gunakan basis data global alih-alih replikasi log biner, atau gunakan parameter `aurora_binlog_*`.
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
Beberapa pernyataan DML mengakses baris basis data yang sama secara bersamaan. Untuk informasi selengkapnya, lihat [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md).
**synch/mutex/innodb/buf\$1pool\$1mutex**
Pool buffer tidak cukup besar untuk menampung set data kerja. Atau, beban kerja mengakses halaman dari tabel tertentu, yang mengakibatkan pertentangan di pool buffer. Untuk informasi selengkapnya, lihat [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md).
**synch/mutex/innodb/fil\$1system\$1mutex**
Proses sedang menunggu akses ke cache memori ruang tabel. Untuk informasi selengkapnya, lihat [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md).
**synch/mutex/innodb/trx\$1sys\$1mutex**
Operasi memeriksa, memperbarui, menghapus, atau menambahkan transaksi IDs di InnoDB secara konsisten atau terkontrol. Operasi ini memerlukan panggilan mutex `trx_sys`, yang dilacak oleh instrumentasi Skema Performa. Operasi mencakup manajemen sistem transaksi ketika basis data dimulai atau dinonaktifkan, rollback, pembersihan undo, akses baca baris, dan beban pool buffer. Beban basis data yang tinggi dengan sejumlah besar transaksi mengakibatkan seringnya kemunculan peristiwa tunggu ini. Untuk informasi selengkapnya, lihat [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md).
**synch/mutex/mysys/KEY\$1CACHE: :cache\$1lock**
Mutex `keycache->cache_lock` mengontrol akses ke cache kunci untuk tabel MyISAM. Meskipun Aurora MySQL tidak mengizinkan penggunaan tabel MyISAM untuk menyimpan data persisten, tabel tersebut digunakan untuk menyimpan tabel sementara internal. Pertimbangkan untuk memeriksa penghitung status `created_tmp_disk_tables` atau `created_tmp_tables` karena dalam situasi tertentu, tabel sementara ditulis ke disk ketika tidak lagi muat dalam memori.
**synch/mutex/sql/FILE\$1AS\$1TABLE: :LOCK\$1OFFSET**
Mesin memperoleh mutex ini saat membuka atau membuat file metadata tabel. Ketika peristiwa tunggu ini terjadi dengan frekuensi yang berlebihan, jumlah tabel yang dibuat atau dibuka telah melonjak.
**synch/mutex/sql/FILE\$1AS\$1TABLE: :LOCK\$1SHIM\$1LISTS**
Mesin memperoleh mutex ini saat melakukan operasi seperti `reset_size`, `detach_contents`, atau `add_contents` pada struktur internal yang melacak tabel yang dibuka. Mutex menyinkronkan akses ke konten daftar. Ketika peristiwa tunggu ini terjadi dengan frekuensi tinggi, ini menunjukkan perubahan mendadak dalam kumpulan tabel yang sebelumnya diakses. Mesin perlu mengakses tabel baru atau melepaskan konteks yang terkait dengan tabel yang diakses sebelumnya.
**synch/mutex/sql/LOCK\$1buka**
Jumlah tabel yang dibuka sesi Anda melebihi ukuran cache definisi tabel atau cache pembukaan tabel. Tingkatkan ukuran cache ini. Untuk informasi selengkapnya, lihat [Cara MySQL membuka dan menutup tabel](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOCK\$1table\$1cache**
Jumlah tabel yang dibuka sesi Anda melebihi ukuran cache definisi tabel atau cache pembukaan tabel. Tingkatkan ukuran cache ini. Untuk informasi selengkapnya, lihat [Cara MySQL membuka dan menutup tabel](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOG**
Dalam peristiwa tunggu ini, terdapat thread yang menunggu kunci log. Misalnya, thread mungkin akan menunggu kunci untuk menulis ke file log kueri lambat.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1COMMIT**
Dalam peristiwa tunggu ini, ada thread yang menunggu untuk mendapatkan kunci dengan tujuan melakukan commit ke log biner. Pertentangan log biner dapat terjadi pada basis data dengan tingkat perubahan yang sangat tinggi. Tergantung pada versi MySQL, terdapat beberapa kunci yang digunakan untuk melindungi konsistensi dan durabilitas log biner. Di RDS for MySQL, log biner digunakan untuk replikasi dan proses pencadangan otomatis. Di Aurora MySQL, log biner tidak diperlukan untuk replikasi atau pencadangan native. Opsi ini dinonaktifkan secara default, tetapi dapat diaktifkan dan digunakan untuk replikasi eksternal atau penangkapan data perubahan. Untuk informasi selengkapnya, lihat [The binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dalam dokumentasi MySQL.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1DUMP\$1THREAD\$1METRICS\$1Collection**
Jika pencatatan log biner diaktifkan, mesin memperoleh mutex ini saat mencetak metrik thread dump aktif ke log kesalahan mesin dan ke peta operasi internal.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1INACTIVE\$1BINLOGS\$1MAP**
Jika pencatatan log biner diaktifkan, mesin memperoleh mutex ini ketika menambahkan, menghapus dari, atau mencari melalui daftar file binlog di belakang yang terbaru.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1IO\$1cache**
Jika pencatatan log biner diaktifkan, mesin memperoleh mutex ini selama operasi cache Aurora IO binlog: mengalokasikan, mengubah ukuran, membebaskan, menulis, membaca, membersihkan, dan mengakses info cache. Jika peristiwa ini sering terjadi, mesin mengakses cache tempat peristiwa binlog disimpan. Untuk mengurangi waktu tunggu, kurangi commit. Cobalah mengelompokkan beberapa pernyataan ke dalam satu transaksi.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1LOG**
Anda telah mengaktifkan pencatatan log biner. Mungkin ada throughput commit yang tinggi, banyak transaksi yang dilakukan, atau replika yang membaca binlog. Pertimbangkan untuk menggunakan pernyataan multibaris atau menggabungkan pernyataan ke dalam satu transaksi. Di Aurora, gunakan basis data global alih-alih replikasi log biner atau gunakan parameter `aurora_binlog_*`.
**synch/mutex/sql/SERVER\$1THREAD: :LOCK\$1SYNC**
Mutex `SERVER_THREAD::LOCK_sync` diperoleh selama penjadwalan, pemrosesan, atau peluncuran thread untuk penulisan file. Terjadinya peristiwa tunggu yang berlebihan ini menunjukkan peningkatan aktivitas penulisan dalam basis data.
**synch/mutex/sql/TABLESPACES:kunci**
Mesin memperoleh mutex `TABLESPACES:lock` selama operasi ruang tabel berikut: membuat, menghapus, memotong, dan memperpanjang. Terjadinya peristiwa tunggu yang berlebihan ini menunjukkan frekuensi operasi ruang tabel yang tinggi. Contohnya adalah memuat sejumlah besar data ke dalam basis data.
**synch/rwlock/innodb/dict**
Dalam peristiwa tunggu ini, ada thread yang menunggu rwlock yang dipertahankan di kamus data InnoDB.
**synch/rwlock/innodb/dict\$1operation\$1lock**
Dalam peristiwa tunggu ini, ada thread yang menahan kunci di operasi kamus data InnoDB.
**synch/rwlock/innodb/dictkunci RW sys**
Sejumlah besar pernyataan bahasa kontrol data bersamaan (DCLs) dalam kode bahasa definisi data (DDLs) dipicu pada saat yang bersamaan. Kurangi ketergantungan aplikasi DDLs selama aktivitas aplikasi reguler.
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
Sejumlah besar pernyataan bahasa manipulasi data (DML) yang serupa mengakses objek basis data yang sama secara bersamaan. Coba gunakan pernyataan multibaris. Selain itu, sebarkan beban kerja ke objek basis data yang berbeda-beda. Misalnya, dengan menerapkan partisi.
**synch/sxlock/innodb/dict\$1operation\$1lock**
Sejumlah besar pernyataan bahasa kontrol data bersamaan (DCLs) dalam kode bahasa definisi data (DDLs) dipicu pada saat yang bersamaan. Kurangi ketergantungan aplikasi DDLs selama aktivitas aplikasi reguler.
**synch/sxlock/innodb/dict\$1sys\$1lock**
Sejumlah besar pernyataan bahasa kontrol data bersamaan (DCLs) dalam kode bahasa definisi data (DDLs) dipicu pada saat yang bersamaan. Kurangi ketergantungan aplikasi DDLs selama aktivitas aplikasi reguler.
**synch/sxlock/innodb/hash\$1table\$1locks**
Sesi tidak dapat menemukan halaman dalam pool buffer. Mesin perlu membaca file atau memodifikasi daftar least-recently used (LRU) untuk pool buffer. Pertimbangkan untuk meningkatkan ukuran cache buffer dan meningkatkan jalur akses untuk kueri yang relevan.
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
Banyak pernyataan bahasa manipulasi data (DML) yang serupa mengakses objek basis data yang sama secara bersamaan. Coba gunakan pernyataan multibaris. Selain itu, sebarkan beban kerja ke objek basis data yang berbeda-beda. Misalnya, dengan menerapkan partisi.
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
Peristiwa tunggu ini terjadi ketika sesi menunggu untuk memperoleh mutex untuk mengelola kumpulan ruang tabel sementara sesi.
Untuk informasi selengkapnya tentang pemecahan masalah peristiwa tunggu sinkronisasi, lihat [Mengapa instans DB MySQL saya menampilkan sejumlah besar sesi aktif yang menunggu peristiwa tunggu SYNCH di Wawasan Performa?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/).
# Aurora Utas saya menyatakan SQL
Berikut ini adalah beberapa status benang merah untuk Aurora My. SQL
**memeriksa izin**
Thread memeriksa apakah server memiliki hak akses yang diperlukan untuk menjalankan pernyataan.
**memeriksa cache kueri untuk kueri**
Server memeriksa apakah kueri saat ini ada di cache kueri.
**dibersihkan**
Ini adalah status akhir dari koneksi yang pekerjaannya selesai, tetapi belum ditutup oleh klien. Solusi terbaik adalah secara eksplisit menutup koneksi dalam kode. Atau, Anda dapat menetapkan nilai yang lebih rendah untuk `wait_timeout` di grup parameter Anda.
**menutup tabel**
Thread melakukan flushing data tabel yang diubah ke disk dan menutup tabel yang digunakan. Jika operasi ini tidak cepat, periksa metrik konsumsi bandwidth jaringan berdasarkan bandwidth jaringan kelas instans. Selain itu, periksa apakah nilai untuk parameter `table_open_cache` dan `table_definition_cache` memungkinkan tabel yang cukup dibuka secara bersamaan sehingga mesin tidak perlu sering membuka dan menutup tabel. Parameter ini memengaruhi konsumsi memori pada instans.
**konversi HEAP ke My ISAM**
Kueri mengonversi tabel sementara dari dalam memori ke di disk. Konversi ini diperlukan karena tabel sementara yang dibuat oleh My SQL dalam langkah perantara pemrosesan kueri tumbuh terlalu besar untuk memori. Periksa nilai `tmp_table_size` dan `max_heap_table_size`. Di versi yang lebih baru, nama status thread ini adalah `converting HEAP to ondisk`.
**mengkonversi HEAP ke ondisk**
Thread mengonversi tabel sementara internal dari tabel dalam memori ke tabel di disk.
**salin ke tabel sementara**
Thread sedang memproses pernyataan `ALTER TABLE`. Status ini terjadi setelah tabel dengan struktur baru telah dibuat, tetapi sebelum baris disalin ke dalamnya. Untuk thread dalam status ini, Anda dapat menggunakan Skema Performa untuk mendapatkan informasi tentang progres operasi penyalinan.
**membuat indeks pengurutan**
Aurora My SQL melakukan semacam karena tidak dapat menggunakan indeks yang ada untuk memenuhi `ORDER BY` atau `GROUP BY` klausa kueri. Untuk informasi selengkapnya, lihat [creating sort index](ams-states.sort-index.md).
**membuat tabel**
Thread membuat tabel permanen atau sementara.
**commit tertunda ok selesai**
Komit asinkron di Aurora My SQL telah menerima pengakuan dan selesai.
**commit tertunda ok diinisiasi**
SQLUtas Aurora My telah memulai proses komit async tetapi sedang menunggu pengakuan. Status ini biasanya menunjukkan waktu commit yang sebenarnya dari suatu transaksi.
**pengiriman tertunda ok selesai**
Utas Aurora SQL Pekerja saya yang terikat ke koneksi dapat dibebaskan saat respons dikirim ke klien. Utas dapat memulai pekerjaan lain. Status `delayed send ok` berarti bahwa konfirmasi asinkron ke klien selesai.
**pengiriman tertunda ok diinisiasi**
Utas Aurora SQL Pekerja saya telah mengirim respons secara asinkron ke klien dan sekarang bebas melakukan pekerjaan untuk koneksi lain. Transaksi telah memulai proses commit asinkron yang belum dikonfirmasi.
**mengeksekusi**
Thread telah mulai menjalankan pernyataan.
**membebaskan item**
Thread telah menjalankan perintah. Beberapa pembebasan item yang dilakukan selama status ini memerlukan cache kueri. Status ini biasanya diikuti dengan pembersihan.
**inisialisasi**
Status ini terjadi sebelum inisialisasi pernyataan `ALTER TABLE`, `DELETE`, `INSERT`, `SELECT`, atau `UPDATE`. Tindakan dalam status ini termasuk flushing log biner atau log InnoDB, dan beberapa pembersihan cache kueri.
**Sumber telah mengirim semua binlog ke replika; menunggu pembaruan lebih lanjut**
Simpul primer telah menyelesaikan bagiannya dalam replikasi. Thread sedang menunggu lebih banyak kueri untuk dijalankan sehingga dapat menulis ke log biner (binlog).
**membuka tabel**
Thread mencoba membuka tabel. Operasi ini cepat kecuali jika pernyataan `ALTER TABLE` atau `LOCK TABLE` perlu diselesaikan, atau melebihi nilai `table_open_cache`.
**mengoptimalkan**
Server melakukan optimisasi awal untuk kueri.
**mempersiapkan**
Status ini terjadi selama optimisasi kueri.
**akhir kueri**
Status ini terjadi setelah memproses kueri, tetapi sebelum status membebaskan item.
**menghapus duplikat**
Aurora My SQL tidak dapat mengoptimalkan `DISTINCT` operasi pada tahap awal kueri. Aurora My SQL harus menghapus semua baris duplikat sebelum mengirim hasilnya ke klien.
**mencari baris untuk pembaruan**
Thread mencari semua baris yang cocok sebelum memperbaruinya. Tahap ini diperlukan jika `UPDATE` mengubah indeks yang digunakan mesin untuk menemukan baris.
**mengirim peristiwa binlog ke slave**
Thread membaca peristiwa dari log biner dan mengirimkannya ke replika.
**mengirim hasil yang di-cache ke klien**
Server mengambil hasil kueri dari cache kueri dan mengirimkannya ke klien.
**mengirim data**
Thread sedang membaca dan memproses baris untuk pernyataan `SELECT`, tetapi belum mulai mengirim data ke klien. Proses ini mengidentifikasi halaman mana yang berisi hasil yang diperlukan untuk memenuhi kueri. Untuk informasi selengkapnya, lihat [sending data](ams-states.sending-data.md).
**mengirim ke klien**
Server menulis paket ke klien. Dalam SQL versi saya sebelumnya, acara tunggu ini diberi label`writing to net`.
**memulai**
Ini adalah tahap pertama di awal eksekusi pernyataan.
**statistik**
Server menghitung statistik untuk mengembangkan rencana eksekusi kueri. Jika thread dalam status ini dalam waktu yang lama, server mungkin terikat pada disk sambil melakukan pekerjaan lain.
**menyimpan hasil dalam cache kueri**
Server menyimpan hasil kueri dalam cache kueri.
**kunci sistem**
Thread telah memanggil `mysql_lock_tables`, tetapi status thread belum diperbarui sejak panggilan ini. Status umum ini terjadi karena berbagai alasan.
**perbarui**
Thread sedang bersiap untuk mulai memperbarui tabel.
**memperbarui**
Thread sedang mencari baris dan memperbaruinya.
**kunci pengguna**
Thread mengeluarkan panggilan `GET_LOCK`. Thread meminta kunci advisory dan sedang menunggunya, atau berencana untuk memintanya.
**menunggu pembaruan lainnya**
Simpul primer telah menyelesaikan bagiannya dalam replikasi. Thread sedang menunggu lebih banyak kueri untuk dijalankan sehingga dapat menulis ke log biner (binlog).
**menunggu kunci metadata skema**
Ini adalah peristiwa tunggu untuk kunci metadata.
**menunggu kunci metadata fungsi tersimpan**
Ini adalah peristiwa tunggu untuk kunci metadata.
**menunggu kunci metadata prosedur tersimpan**
Ini adalah peristiwa tunggu untuk kunci metadata.
**menunggu flushing tabel**
Thread sedang menjalankan `FLUSH TABLES` dan sedang menunggu semua thread untuk menutup tabelnya. Atau, thread menerima notifikasi bahwa struktur dasar untuk tabel berubah, sehingga harus membuka kembali tabel untuk mendapatkan struktur baru. Untuk membuka kembali tabel, thread harus menunggu sampai semua thread lainnya menutup tabel. Notifikasi ini terjadi jika thread lain telah menggunakan salah satu pernyataan berikut di tabel: `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE`, atau `OPTIMIZE TABLE`.
**menunggu kunci tingkat tabel**
Satu sesi mempertahankan kunci di tabel sementara sesi lain mencoba mendapatkan kunci yang sama di tabel yang sama.
**menunggu kunci metadata tabel**
Aurora My SQL menggunakan penguncian metadata untuk mengelola akses bersamaan ke objek database dan untuk memastikan konsistensi data. Dalam peristiwa tunggu ini, satu sesi mempertahankan kunci metadata di tabel sementara sesi lain mencoba mendapatkan kunci yang sama di tabel yang sama. Saat Skema Performa diaktifkan, status thread ini dilaporkan sebagai peristiwa tunggu `synch/cond/sql/MDL_context::COND_wait_status`.
**menulis ke net**
Server sedang menulis paket ke jaringan. Di SQL versi saya yang lebih baru, acara tunggu ini diberi label`Sending to client`.
# Tingkat isolasi Aurora MySQL
Pelajari bagaimana instans DB di klaster Aurora MySQL menerapkan properti basis data isolasi. Topik ini menjelaskan bagaimana perilaku default Aurora MySQL menyeimbangkan antara konsistensi yang ketat dan performa yang tinggi. Anda dapat menggunakan informasi ini untuk membantu memutuskan kapan akan mengubah pengaturan default berdasarkan karakteristik beban kerja Anda.
## Tingkat isolasi yang tersedia untuk instans penulis
Anda dapat menggunakan tingkat isolasi `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED`, dan `SERIALIZABLE` pada instans primer klaster DB Aurora MySQL. Tingkat isolasi ini berfungsi di Aurora MySQL sama seperti di RDS for MySQL.
## Tingkat isolasi REPEATABLE READ untuk instans pembaca
Secara default, instans DB Aurora MySQL yang dikonfigurasi sebagai Replika Aurora hanya baca selalu menggunakan tingkat isolasi `REPEATABLE READ`. Instans DB ini mengabaikan pernyataan `SET TRANSACTION ISOLATION LEVEL` dan terus menggunakan tingkat isolasi `REPEATABLE READ`.
## Tingkat isolasi READ COMMITTED untuk instans pembaca
Jika aplikasi Anda mencakup beban kerja sarat penulisan pada instans primer dan kueri yang berjalan lama pada Replika Aurora, Anda mungkin mengalami lag pembuangan yang substansial. *Lag pembuangan* terjadi jika pengumpulan sampah internal diblokir oleh kueri yang berjalan lama. Gejala yang Anda lihat adalah nilai yang tinggi untuk `history list length` dalam output dari perintah `SHOW ENGINE INNODB STATUS`. Anda dapat memantau nilai ini menggunakan `RollbackSegmentHistoryListLength` metrik di CloudWatch. Lag pembuangan yang substansial dapat mengurangi efektivitas indeks sekunder, menurunkan performa kueri secara keseluruhan, dan menyebabkan pemborosan ruang penyimpanan.
Jika Anda mengalami masalah seperti itu, Anda dapat mengatur pengaturan konfigurasi tingkat sesi Aurora MySQL, `aurora_read_replica_read_committed`, agar menggunakan tingkat isolasi `READ COMMITTED` pada Replika Aurora. Saat menerapkan pengaturan ini, Anda dapat membantu mengurangi pelambatan dan ruang terbuang yang dapat timbul karena melakukan kueri berjalan lama pada saat yang sama seperti transaksi yang mengubah tabel Anda.
Kami menyarankan Anda untuk memahami perilaku tertentu Aurora MySQL karena isolasi `READ COMMITTED` sebelum menggunakan pengaturan ini. Perilaku Replika Aurora `READ COMMITTED` sesuai dengan standar ANSI SQL. Namun, isolasinya tidak seketat perilaku `READ COMMITTED` MySQL biasa yang mungkin Anda kenal. Dengan demikian, Anda mungkin melihat hasil kueri yang berbeda berdasarkan `READ COMMITTED` di replika baca Aurora MySQL daripada kueri yang sama berdasarkan `READ COMMITTED` di instans primer Aurora MySQL atau di RDS for MySQL. Anda dapat mempertimbangkan untuk menggunakan pengaturan `aurora_read_replica_read_committed` untuk kasus seperti laporan komprehensif yang memindai basis data yang sangat besar. Sebaliknya, Anda dapat menghindarinya untuk kueri pendek dengan set hasil kecil yang mementingkan presisi dan keterulangan.
Tingkat isolasi `READ COMMITTED` tidak tersedia untuk sesi dengan klaster sekunder dalam basis data global Aurora yang menggunakan fitur penerusan tulis. Untuk informasi tentang penerusan tulis, lihat [Menggunakan penerusan menulis dalam basis data global Amazon Aurora](aurora-global-database-write-forwarding.md).
### Menggunakan READ COMMITTED untuk pembaca
Untuk menggunakan tingkat isolasi `READ COMMITTED` untuk Replika Aurora, atur pengaturan konfigurasi `aurora_read_replica_read_committed` ke `ON`. Gunakan pengaturan ini di tingkat sesi saat terhubung ke Replika Aurora tertentu. Untuk melakukannya, jalankan perintah SQL berikut.
```
set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;
```
Anda dapat menggunakan pengaturan konfigurasi ini sementara waktu untuk melakukan kueri interaktif satu kali. Anda mungkin juga ingin menjalankan aplikasi pelaporan atau analisis data yang mendapatkan manfaat dari tingkat isolasi `READ COMMITTED`, sementara membiarkan pengaturan default tidak berubah untuk aplikasi lain.
Saat pengaturan `aurora_read_replica_read_committed` diaktifkan, gunakan perintah `SET TRANSACTION ISOLATION LEVEL` untuk menentukan tingkat isolasi untuk transaksi yang sesuai.
```
set transaction isolation level read committed;
```
### Perbedaan dalam perilaku READ COMMITTED pada replika Aurora
Pengaturan `aurora_read_replica_read_committed` membuat tingkat isolasi `READ COMMITTED` tersedia untuk Replika Aurora, dengan perilaku konsistensi yang dioptimalkan untuk transaksi yang berjalan lama. Tingkat isolasi `READ COMMITTED` pada Replika Aurora memiliki isolasi yang tidak terlalu ketat dibandingkan pada instans primer Aurora. Oleh karena itu, aktifkan pengaturan ini hanya di Replika Aurora, yang memungkinkan Anda mengetahui bahwa kueri Anda dapat menerima kemungkinan jenis hasil tertentu yang tidak konsisten.
Kueri Anda dapat mengalami beberapa jenis anomali baca ketika pengaturan `aurora_read_replica_read_committed` diaktifkan. Dua jenis anomali ini sangat penting untuk dipahami dan ditangani dalam kode aplikasi Anda. *Pembacaan yang tidak dapat diulang* terjadi saat transaksi lain di-commit saat kueri Anda sedang berjalan. Kueri yang berjalan lama dapat melihat data yang berbeda pada awal kueri dibandingkan dengan yang dilihat pada akhir kueri. *Pembacaan phantom* terjadi ketika transaksi lain menyebabkan baris yang ada disusun ulang saat kueri Anda berjalan, dan satu atau beberapa baris dibaca dua kali oleh kueri Anda.
Kueri Anda mungkin mengalami jumlah baris yang tidak konsisten sebagai hasil dari pembacaan phantom. Kueri Anda juga dapat memberikan hasil yang tidak lengkap atau tidak konsisten karena pembacaan yang tidak dapat diulang. Misalnya, anggaplah sebuah operasi join merujuk ke tabel yang secara bersamaan dimodifikasi oleh pernyataan SQL seperti `INSERT` atau `DELETE`. Dalam kasus ini, kueri join mungkin membaca baris dari satu tabel, tetapi bukan baris yang sesuai dari tabel lain.
Standar ANSI SQL memungkinkan kedua perilaku ini untuk tingkat isolasi `READ COMMITTED`. Namun, perilaku tersebut berbeda dari implementasi `READ COMMITTED` MySQL biasa. Jadi, sebelum mengaktifkan pengaturan `aurora_read_replica_read_committed`, periksa kode SQL yang ada untuk memverifikasi apakah kode ini beroperasi seperti yang diharapkan berdasarkan model konsistensi yang lebih longgar.
Jumlah baris dan hasil lainnya mungkin tidak terlalu konsisten berdasarkan tingkat isolasi `READ COMMITTED` sementara pengaturan ini diaktifkan. Dengan demikian, Anda biasanya mengaktifkan pengaturan hanya saat menjalankan kueri analitik yang mengumpulkan data dalam jumlah besar dan tidak memerlukan presisi absolut. Jika Anda tidak memiliki jenis kueri yang berjalan lama ini bersama dengan beban kerja rata penulisan, Anda mungkin tidak memerlukan pengaturan `aurora_read_replica_read_committed`. Tanpa kombinasi kueri yang berjalan lama dan beban kerja yang sarat penulisan, Anda cenderung tidak akan menghadapi masalah dengan panjang daftar riwayat.
**Example Kueri yang menunjukkan perilaku isolasi untuk READ COMMITTED pada Replika Aurora**
Contoh berikut menunjukkan bagaimana kueri `READ COMMITTED` pada Replika Aurora dapat memberikan hasil yang tidak dapat diulang jika transaksi mengubah tabel terkait pada saat yang sama. Tabel `BIG_TABLE` berisi 1 juta baris sebelum kueri dimulai. Pernyataan bahasa manipulasi data (DML) lainnya menambahkan, menghapus, atau mengubah baris saat sedang berjalan.
Kueri pada instans primer Aurora berdasarkan tingkat isolasi `READ COMMITTED` memberikan hasil yang dapat diprediksi. Namun demikian, overhead dalam mempertahankan tampilan baca yang konsisten selama masa pakai setiap kueri yang berjalan lama dapat menyebabkan pengumpulan sampah yang menimbulkan biaya mahal pada lain waktu.
Kueri pada Replika Aurora berdasarkan tingkat isolasi `READ COMMITTED` akan dioptimalkan untuk meminimalkan overhead pengumpulan sampah. Komprominya adalah bahwa hasilnya mungkin berbeda-beda bergantung pada apakah kueri memuat baris yang ditambahkan, dihapus, atau disusun ulang oleh transaksi yang di-commit saat kueri berjalan. Kueri diizinkan untuk mempertimbangkan baris-baris ini, tetapi tidak diwajibkan. Untuk tujuan demonstrasi, kueri hanya memeriksa jumlah baris dalam tabel dengan menggunakan fungsi `COUNT(*)`.
| Waktu | Pernyataan DML di instans primer Aurora | Kueri di instans primer Aurora dengan READ COMMITTED | Kueri di replika Aurora dengan READ COMMITTED |
| --- | --- | --- | --- |
| T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | Jika Q1 selesai sekarang, hasilnya adalah 1.000.000. | Jika Q2 selesai sekarang, hasilnya adalah 1.000.000 atau 1.000.001. |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | Jika Q1 selesai sekarang, hasilnya adalah 1.000.000. | Jika Q2 selesai sekarang, hasilnya adalah 1.000.000 atau 1.000.001 atau 999.999 atau 999.998. |
| T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | |
| T8 | | Jika Q1 selesai sekarang, hasilnya adalah 1.000.000. | Jika Q2 selesai sekarang, hasilnya adalah 1.000.000 atau 1.000.001 atau 999.999, atau mungkin angka tertentu yang lebih tinggi. |
| T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | Jika Q3 selesai sekarang, hasilnya adalah 999.999. | Jika Q4 selesai sekarang, hasilnya adalah 999.999. |
| T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | |
| T13 | | Jika Q5 selesai sekarang, hasilnya adalah 0. | Jika Q6 selesai sekarang, hasilnya adalah 0 atau 1. |
Jika kueri selesai dengan cepat, sebelum transaksi lain melakukan pernyataan DML dan di-commit, hasilnya dapat diprediksi dan sama antara instans primer dan Replika Aurora. Mari kita periksa perbedaan perilaku secara mendetail, dimulai dengan kueri pertama.
Hasil untuk Q1 sangat dapat diprediksi, karena `READ COMMITTED` pada instans primer menggunakan model konsistensi kuat yang serupa dengan tingkat isolasi `REPEATABLE READ`.
Hasil untuk Q2 dapat bervariasi bergantung pada transaksi apa yang dilakukan saat kueri berjalan. Misalnya, transaksi lain melakukan pernyataan DML dan di-commit saat kueri sedang berjalan. Dalam hal ini, kueri di Replika Aurora dengan tingkat isolasi `READ COMMITTED` mungkin atau mungkin tidak memperhitungkan perubahan tersebut. Hitungan baris tidak dapat diprediksi dengan cara yang sama seperti berdasarkan tingkat isolasi `REPEATABLE READ`. Hitungan baris juga tidak dapat diprediksi seperti kueri yang berjalan berdasarkan tingkat isolasi `READ COMMITTED` pada instans primer, atau pada instans RDS for MySQL.
Pernyataan `UPDATE` di T7 tidak benar-benar mengubah jumlah baris dalam tabel. Namun, dengan mengubah panjang kolom panjang variabel, pernyataan ini dapat menyebabkan baris-baris tersebut disusun ulang secara internal. Transaksi `READ COMMITTED` yang berjalan lama dapat melihat baris versi lama, lalu dalam kueri yang sama, melihat versi baru dari baris yang sama. Kueri ini juga dapat melewati versi baris lama dan baru, sehingga jumlah baris mungkin berbeda dari yang diharapkan.
Hasil Q5 dan Q6 mungkin identik atau sedikit berbeda. Kueri Q6 pada Replika Aurora berdasarkan `READ COMMITTED` dapat melihat, tetapi tidak wajib untuk melihat, baris baru yang di-commit saat kueri berjalan. Kueri ini juga dapat melihat baris dari satu tabel, tetapi tidak dari tabel lainnya. Jika kueri join tidak menemukan baris yang cocok di kedua tabel, kueri ini akan menghasilkan angka nol. Jika kueri ini menemukan baris baru di `PARENT_TABLE` dan `CHILD_TABLE`, kueri tersebut akan menampilkan satu angka. Dalam kueri yang berjalan lama, pencarian dari tabel gabungan dapat terjadi pada waktu yang terpisah secara luas.
Perbedaan perilaku ini bergantung pada waktu transaksi di-commit dan kueri memproses baris tabel yang mendasarinya. Oleh karena itu, kemungkinan besar Anda akan melihat perbedaan tersebut dalam kueri laporan yang memakan waktu beberapa menit atau jam dan yang berjalan di klaster Aurora yang memproses transaksi OLTP pada saat yang sama. Ini adalah jenis beban kerja campuran yang mendapatkan manfaat maksimal dari tingkat isolasi `READ COMMITTED` pada Replika Aurora.
# Aurora Petunjuk saya SQL
Anda dapat menggunakan SQL petunjuk dengan kueri Aurora SQL My untuk menyempurnakan kinerja. Anda juga dapat menggunakan petunjuk agar rencana eksekusi untuk kueri penting tidak berubah karena kondisi yang tidak dapat diprediksi.
**Tip**
Untuk memverifikasi efek petunjuk pada kueri, periksa rencana kueri yang dihasilkan oleh pernyataan `EXPLAIN`. Bandingkan rencana kueri dengan atau tanpa petunjuk.
Di Aurora My SQL versi 3, Anda dapat menggunakan semua petunjuk yang tersedia di My SQL Community Edition 8.0. Untuk informasi selengkapnya tentang petunjuk ini, lihat [Petunjuk Pengoptimal di Manual Referensi](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) *Saya SQL*.
Petunjuk berikut tersedia di Aurora SQL My versi 2. Petunjuk ini berlaku untuk kueri yang menggunakan fitur gabungan hash di Aurora My SQL versi 2, terutama kueri yang menggunakan optimasi kueri paralel.
**PQ, NO\$1PQ**
Menentukan apakah akan memaksa pengoptimisasi untuk menggunakan kueri paralel berdasarkan per tabel atau per kueri.
`PQ` memaksa pengoptimisasi untuk menggunakan kueri paralel untuk tabel tertentu atau seluruh kueri (blok). `NO_PQ` mencegah pengoptimisasi menggunakan kueri paralel untuk tabel tertentu atau seluruh kueri (blok).
Petunjuk ini tersedia di Aurora SQL My versi 2.11 dan lebih tinggi. Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
Menentukan nama tabel akan memaksa pengoptimisasi untuk menerapkan petunjuk `PQ/NO_PQ` hanya pada tabel pilihan tersebut. Jika nama tabel tidak ditentukan, petunjuk `PQ/NO_PQ` akan dipaksa pada semua tabel yang terpengaruh oleh blok kueri.
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN, TIDAK\$1 \$1 HASH JOIN**
Mengaktifkan atau menonaktifkan kemampuan pengoptimisasi kueri paralel untuk memilih apakah akan menggunakan metode optimisasi hash join untuk kueri. `HASH_JOIN` memungkinkan pengoptimisasi menggunakan hash join jika mekanismenya lebih efisien. `NO_HASH_JOIN` mencegah pengoptimisasi menggunakan hash join untuk kueri. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi. Ini tidak berpengaruh di Aurora My SQL versi 3.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
```
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1 JOIN \$1PROBING, TIDAK \$1 \$1 HASH \$1 JOIN PROBING**
Di kueri hash join, tentukan apakah akan menggunakan tabel yang ditentukan untuk sisi probe dari join. Kueri ini menguji apakah nilai kolom dari tabel build ada di tabel probe, bukan membaca seluruh konten tabel probe. Anda dapat menggunakan `HASH_JOIN_PROBING` dan `HASH_JOIN_BUILDING` untuk menentukan cara kueri hash join diproses, tanpa mengatur ulang susunan tabel dalam teks kueri. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi. Ini tidak berpengaruh di Aurora My SQL versi 3.
Contoh berikut menunjukkan cara menggunakan petunjuk ini. Menentukan petunjuk `HASH_JOIN_PROBING` untuk tabel `T2` memiliki efek yang sama seperti menentukan `NO_HASH_JOIN_PROBING` untuk tabel `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1 JOIN \$1BUILDING, TIDAK \$1 \$1 HASH \$1 JOIN BUILDING**
Di kueri hash join, tentukan apakah akan menggunakan tabel yang ditentukan untuk sisi build dari join. Kueri ini memproses semua baris dari tabel ini untuk membuat daftar nilai kolom untuk melakukan referensi silang dengan tabel lain. Anda dapat menggunakan `HASH_JOIN_PROBING` dan `HASH_JOIN_BUILDING` untuk menentukan cara kueri hash join diproses, tanpa mengatur ulang susunan tabel dalam teks kueri. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi. Ini tidak berpengaruh di Aurora My SQL versi 3.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini. Menentukan petunjuk `HASH_JOIN_BUILDING` untuk tabel `T2` memiliki efek yang sama seperti menentukan `NO_HASH_JOIN_BUILDING` untuk tabel `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**JOIN\$1FIXED\$1ORDER**
Menentukan bahwa tabel dalam kueri digabungkan berdasarkan urutan pencantumannya dalam kueri. Ini berguna dengan kueri yang memerlukan tiga tabel atau lebih. Ini dimaksudkan sebagai pengganti SQL `STRAIGHT_JOIN` petunjuk Saya dan setara dengan petunjuk SQL [JOIN\$1 FIXED \$1 ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) Saya. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
```
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1ORDER**
Menentukan urutan join untuk tabel dalam kueri. Ini berguna dengan kueri yang memerlukan tiga tabel atau lebih. Ini setara dengan ORDER petunjuk SQL [JOIN\$1](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) Saya. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
```
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1PREFIX**
Menentukan tabel yang dimasukkan pertama dalam urutan join. Ini berguna dengan kueri yang memerlukan tiga tabel atau lebih. Ini setara dengan PREFIX petunjuk SQL [JOIN\$1](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) Saya. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
Menentukan tabel yang dimasukkan terakhir dalam urutan join. Ini berguna dengan kueri yang memerlukan tiga tabel atau lebih. Ini setara dengan SUFFIX petunjuk SQL [JOIN\$1](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) Saya. Petunjuk ini tersedia di Aurora SQL My versi 2.08 dan lebih tinggi.
Contoh berikut menunjukkan kepada Anda cara menggunakan petunjuk ini.
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
Untuk informasi tentang menggunakan kueri hash join, lihat [Mengoptimalkan kueri join MySQL Aurora besar dengan hash join](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin).
# Aurora Referensi prosedur SQL tersimpan saya
Anda dapat mengelola cluster Aurora My SQL DB Anda dengan memanggil prosedur tersimpan bawaan.
**Topics**
+ [Mengumpulkan dan memelihara Sejarah Status Global](mysql-stored-proc-gsh.md)
+ [Mengkonfigurasi, memulai, dan menghentikan replikasi log biner (binlog)](mysql-stored-proc-replicating.md)
+ [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md)
+ [Mereplikasi transaksi menggunakan GTIDs](mysql-stored-proc-gtid.md)
+ [Memutar log kueri](mysql-stored-proc-logging.md)
+ [Mengatur dan menampilkan konfigurasi log biner](mysql-stored-proc-configuring.md)
# Mengumpulkan dan memelihara Sejarah Status Global
Amazon RDS menyediakan serangkaian prosedur yang mengambil snapshot dari nilai variabel status dari waktu ke waktu dan menuliskannya ke tabel, bersama dengan perubahan apa pun sejak snapshot terakhir. Infrastruktur ini disebut Global Status History. Untuk informasi selengkapnya, lihat [Mengelola Global Status History](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Prosedur tersimpan berikut mengelola bagaimana Global Status History dikumpulkan dan dipelihara.
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Mengambil snapshot sesuai permintaan untuk Global Status History.
### Sintaks
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Menonaktifkan snapshot yang diambil oleh Global Status History.
### Sintaks
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Menonaktifkan rotasi tabel `mysql.global_status_history`.
### Sintaks
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Mengaktifkan Global Status History untuk mengambil snapshot default pada interval yang ditentukan oleh `rds_set_gsh_collector`.
### Sintaks
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Mengaktifkan rotasi konten tabel `mysql.global_status_history` ke `mysql.global_status_history_old` pada interval yang ditentukan oleh `rds_set_gsh_rotation`.
### Sintaks
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Merotasi konten tabel `mysql.global_status_history` ke `mysql.global_status_history_old` sesuai permintaan.
### Sintaks
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Menentukan interval, dalam menit, di antara snapshot yang diambil oleh Global Status History.
### Sintaks
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Parameter
*intervalPeriod*
Interval, dalam menit, di antara snapshot. Nilai default-nya adalah `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Menentukan interval, dalam hari, antara rotasi tabel `mysql.global_status_history`.
### Sintaks
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Parameter
*intervalPeriod*
Interval, dalam hari, di antara rotasi tabel. Nilai default-nya adalah `7`.
# Mengkonfigurasi, memulai, dan menghentikan replikasi log biner (binlog)
Anda dapat memanggil prosedur tersimpan berikut saat terhubung dengan instans primer di klaster Aurora MySQL. Prosedur ini mengontrol bagaimana transaksi direplikasi dari basis data eksternal ke Aurora MySQL, atau dari Aurora MySQL ke basis data eksternal.
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versi 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versi 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log versi 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (RDS )](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master versi 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source ( 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versi 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (RDS )](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versi 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versi 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position (RDS )](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL versi 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versi 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position ( 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versi 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versi 2)
Menonaktifkan pencatatan log biner untuk sesi saat ini dengan mengatur variabel `sql_log_bin` ke `OFF`.
### Sintaksis
```
CALL mysql.rds_disable_session_binlog;
```
### Parameter
Tidak ada
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Untuk Aurora, prosedur ini didukung untuk Aurora MySQL versi 2.12 dan versi yang lebih tinggi yang kompatibel dengan MySQL 5.7.
**catatan**
Di Aurora MySQL versi 3, Anda dapat menggunakan perintah berikut untuk menonaktifkan pencatatan log biner untuk sesi saat ini jika Anda memiliki hak istimewa `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versi 2)
Mengaktifkan pencatatan log biner untuk sesi saat ini dengan mengatur variabel `sql_log_bin` ke `ON`.
### Sintaksis
```
CALL mysql.rds_enable_session_binlog;
```
### Parameter
Tidak ada
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Untuk Aurora, prosedur ini didukung untuk Aurora MySQL versi 2.12 dan versi yang lebih tinggi yang kompatibel dengan MySQL 5.7.
**catatan**
Di Aurora MySQL versi 3, Anda dapat menggunakan perintah berikut untuk mengaktifkan pencatatan log biner untuk sesi saat ini jika Anda memiliki hak istimewa `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
Mengimpor sertifikat otoritas sertifikat, sertifikat klien, dan kunci klien ke klaster DB Aurora MySQL. Informasi tersebut diperlukan untuk komunikasi SSL dan replikasi terenkripsi.
**catatan**
Saat ini, prosedur ini didukung untuk Aurora MySQL versi 2:2.09.2, 2.10.0, 2.10.1, dan 2.11.0; serta versi 3:3.01.1 dan yang lebih tinggi.
### Sintaks
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### Parameter
*ssl\$1material*
Payload JSON yang berisi konten file berformat .pem berikut untuk klien MySQL:
+ “ssl\$1ca”:”” *Certificate authority certificate*
+ “ssl\$1cert”:”” *Client certificate*
+ “ssl\$1key”:”” *Client key*
### Catatan penggunaan
Persiapkan untuk replikasi terenkripsi sebelum Anda menjalankan prosedur ini:
+ Jika Anda tidak memiliki SSL yang diaktifkan pada instans basis data sumber MySQL eksternal dan tidak menyiapkan kunci klien dan sertifikat klien, aktifkan SSL pada server basis data MySQL serta buat kunci klien dan sertifikat klien yang diperlukan.
+ Jika SSL diaktifkan pada instans basis data sumber eksternal, sediakan kunci dan sertifikat klien untuk klaster DB Aurora MySQL. Jika Anda tidak memilikinya, buat kunci dan sertifikat baru untuk klaster DB Aurora MySQL. Untuk menandatangani sertifikat klien, Anda harus memiliki kunci otoritas sertifikat yang Anda gunakan untuk mengonfigurasi SSL pada instans basis data sumber MySQL eksternal.
Untuk informasi selengkapnya, lihat [Creating SSL certificates and keys using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) dalam dokumentasi MySQL.
**penting**
Setelah Anda mempersiapkan replikasi terenkripsi, gunakan koneksi SSL untuk menjalankan prosedur ini. Kunci klien tidak boleh ditransfer melalui koneksi yang tidak aman.
Prosedur ini mengimpor informasi SSL dari basis data MySQL eksternal ke klaster DB Aurora MySQL. Informasi SSL dalam file berformat .pem yang berisi informasi SSL untuk klaster DB Aurora MySQL. Selama replikasi terenkripsi, klaster DB Aurora MySQL berperan sebagai klien untuk server basis data MySQL. Sertifikat dan kunci untuk klien Aurora MySQL ada di dalam file berformat .pem.
Anda dapat menyalin informasi dari file ini ke dalam parameter `ssl_material` dalam payload JSON yang benar. Untuk mendukung replikasi terenkripsi, impor informasi SSL ini ke klaster DB Aurora MySQL.
Payload JSON harus dalam format berikut.
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### Contoh
Contoh berikut mengimpor informasi SSL ke Aurora MySQL. Dalam file berformat .pem, kode konten biasanya lebih panjang dari kode konten yang ditunjukkan dalam contoh.
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## mysql.rds\$1next\$1master\$1log versi 2)
Mengubah posisi log instans basis data sumber menjadi awal log biner berikutnya pada instans basis data sumber. Gunakan prosedur ini hanya jika Anda menerima I/O kesalahan replikasi 1236 pada replika baca.
### Sintaks
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### Parameter
*curr\$1master\$1log*
Indeks file log master saat ini. Misalnya, jika file saat ini bernama `mysql-bin-changelog.012345`, maka indeksnya adalah 12345. Untuk menentukan nama file log master saat ini, jalankan perintah `SHOW REPLICA STATUS` dan lihat kolom `Master_Log_File`.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_next_master_log`.
**Awas**
Panggil `mysql.rds_next_master_log` hanya jika replikasi gagal setelah failover instans DB multi-AZ yang merupakan sumber replikasi, dan `Last_IO_Errno` bidang laporan kesalahan 1236. `SHOW REPLICA STATUS` I/O
Memanggil `mysql.rds_next_master_log` dapat mengakibatkan hilangnya data di replika baca jika transaksi dalam instans sumber tidak ditulis ke log biner di disk sebelum peristiwa failover terjadi.
### Contoh
Asumsikan replikasi gagal pada replika baca Aurora MySQL. Menjalankan `SHOW REPLICA STATUS\G` pada replika baca akan menampilkan hasil berikut:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
Kolom `Last_IO_Errno` menunjukkan bahwa instans menerima kesalahan I/O 1236. Kolom `Master_Log_File` menunjukkan bahwa nama file adalah `mysql-bin-changelog.012345`, yang berarti indeks file log adalah `12345`. Untuk mengatasi kesalahan, Anda dapat memanggil `mysql.rds_next_master_log` dengan parameter berikut:
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (RDS )
Mengubah posisi log instans basis data sumber menjadi awal log biner berikutnya pada instans basis data sumber. Gunakan prosedur ini hanya jika Anda menerima I/O kesalahan replikasi 1236 pada replika baca.
### Sintaks
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### Parameter
*curr\$1source\$1log*
Indeks file log sumber saat ini. Misalnya, jika file saat ini bernama `mysql-bin-changelog.012345`, maka indeksnya adalah 12345. Untuk menentukan nama file log sumber saat ini, jalankan perintah `SHOW REPLICA STATUS` dan lihat kolom `Source_Log_File`.
### Catatan penggunaan
Pengguna administratif harus menjalankan prosedur `mysql.rds_next_source_log`.
**Awas**
Panggil `mysql.rds_next_source_log` hanya jika replikasi gagal setelah failover instans DB multi-AZ yang merupakan sumber replikasi, dan `Last_IO_Errno` bidang laporan kesalahan 1236. `SHOW REPLICA STATUS` I/O
Memanggil `mysql.rds_next_source_log` dapat mengakibatkan hilangnya data di replika baca jika transaksi dalam instans sumber tidak ditulis ke log biner di disk sebelum peristiwa failover terjadi. Anda dapat mengurangi kemungkinan hal ini terjadi dengan menyetel parameter instance sumber `sync_binlog` dan `innodb_support_xa` ke`1`, meskipun ini dapat mengurangi kinerja.
### Contoh
Asumsikan replikasi gagal pada replika baca Aurora MySQL. Menjalankan `SHOW REPLICA STATUS\G` pada replika baca akan menampilkan hasil berikut:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
Kolom `Last_IO_Errno` menunjukkan bahwa instans menerima kesalahan I/O 1236. Kolom `Source_Log_File` menunjukkan bahwa nama file adalah `mysql-bin-changelog.012345`, yang berarti indeks file log adalah `12345`. Untuk mengatasi kesalahan, Anda dapat memanggil `mysql.rds_next_source_log` dengan parameter berikut:
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
Menghapus sertifikat otoritas sertifikat, sertifikat klien, dan kunci klien untuk komunikasi SSL dan replikasi terenkripsi. Informasi ini diimpor menggunakan [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
### Sintaksis
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master versi 2)
Mengonfigurasi ulang instans DB Aurora MySQL agar tidak lagi menjadi replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
**penting**
Untuk menjalankan prosedur ini, `autocommit` harus diaktifkan. Untuk mengaktifkannya, atur parameter `autocommit` ke `1`. Lihat informasi tentang cara mengubah parameter di [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md).
### Sintaks
```
CALL mysql.rds_reset_external_master;
```
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_reset_external_master`. Prosedur ini harus dijalankan pada instans DB MySQL agar dihapus sebagai replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
**catatan**
Kami menawarkan prosedur tersimpan ini terutama untuk mengaktifkan replikasi dengan instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda menggunakan Aurora Replicas untuk mengelola replikasi dalam klaster DB Aurora MySQL jika memungkinkan. Untuk informasi tentang cara mengelola replikasi di klaster DB Aurora MySQL, lihat [Menggunakan Replika Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Untuk informasi selengkapnya tentang cara menggunakan replikasi untuk mengimpor data dari instans MySQL yang berjalan di luar Aurora MySQL, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md).
## mysql.rds\$1reset\$1external\$1source ( 3)
Mengonfigurasi ulang instans DB Aurora MySQL agar tidak lagi menjadi replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
**penting**
Untuk menjalankan prosedur ini, `autocommit` harus diaktifkan. Untuk mengaktifkannya, atur parameter `autocommit` ke `1`. Lihat informasi tentang cara mengubah parameter di [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md).
### Sintaks
```
CALL mysql.rds_reset_external_source;
```
### Catatan penggunaan
Pengguna administratif harus menjalankan prosedur `mysql.rds_reset_external_source`. Prosedur ini harus dijalankan pada instans DB MySQL agar dihapus sebagai replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
**catatan**
Kami menawarkan prosedur tersimpan ini terutama untuk mengaktifkan replikasi dengan instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda menggunakan Aurora Replicas untuk mengelola replikasi dalam klaster DB Aurora MySQL jika memungkinkan. Untuk informasi tentang cara mengelola replikasi di klaster DB Aurora MySQL, lihat [Menggunakan Replika Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versi 3)
Mengaktifkan `SOURCE_SSL` enkripsi untuk replikasi binlog. Untuk informasi selengkapnya, lihat [MENGUBAH SUMBER REPLIKASI KE pernyataan](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) dalam dokumentasi MySQL.
### Sintaks
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### Parameter
*mode*
Nilai yang menunjukkan apakah `SOURCE_SSL` enkripsi diaktifkan:
+ `0`— `SOURCE_SSL` enkripsi dinonaktifkan. Nilai default-nya `0`.
+ `1`— `SOURCE_SSL` enkripsi diaktifkan. Anda dapat mengonfigurasi enkripsi menggunakan SSL atau TLS.
### Catatan penggunaan
Prosedur ini didukung untuk Aurora MySQL versi 3.06 dan lebih tinggi.
## mysql.rds\$1set\$1external\$1master 2)
Mengonfigurasi instans DB Aurora MySQL agar tidak lagi menjadi replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
Prosedur `mysql.rds_set_external_master` tidak digunakan lagi dan akan dihapus dalam rilis mendatang. Gunakan `mysql.rds\$1set\$1external\$1source` sebagai gantinya.
**penting**
Untuk menjalankan prosedur ini, `autocommit` harus diaktifkan. Untuk mengaktifkannya, atur parameter `autocommit` ke `1`. Lihat informasi tentang cara mengubah parameter di [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md).
### Sintaks
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parameter
*host\$1name*
Nama host atau alamat IP instans MySQL yang berjalan di luar Amazon RDS untuk menjadi instans basis data sumber.
*host\$1port*
Port yang digunakan oleh instans MySQL yang berjalan di luar Amazon RDS untuk dikonfigurasi sebagai instans basis data sumber. Jika konfigurasi jaringan Anda mencakup replikasi port Secure Shell (SSH) yang mengubah nomor port, tentukan nomor port yang diekspos oleh SSH.
*replication\$1user\$1name*
ID pengguna dengan izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda memberikan akun yang digunakan sepenuhnya untuk replikasi dengan instans eksternal.
*replication\$1user\$1password*
Kata sandi ID pengguna yang ditentukan dalam `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nama log biner pada instans basis data sumber yang berisi informasi replikasi.
*mysql\$1binary\$1log\$1file\$1location*
Lokasi di log biner `mysql_binary_log_file_name` tempat replikasi mulai membaca informasi replikasi.
Anda dapat menentukan nama dan lokasi file binlog dengan menjalankan `SHOW MASTER STATUS` pada instans basis data sumber.
*ssl\$1encryption*
Nilai yang menentukan apakah enkripsi Lapisan Soket Aman (SSL) digunakan pada sambungan replikasi. 1 menentukan untuk menggunakan enkripsi SSL, 0 menentukan untuk tidak menggunakan enkripsi. Default-nya adalah 0.
Opsi `MASTER_SSL_VERIFY_SERVER_CERT` tidak didukung. Opsi ini diatur ke 0, yang berarti koneksi dienkripsi, tetapi sertifikat tidak diverifikasi.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_set_external_master`. Prosedur ini harus dijalankan pada instans DB MySQL untuk dikonfigurasi sebagai replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
Sebelum menjalankan `mysql.rds_set_external_master`, Anda harus mengonfigurasi instans MySQL yang berjalan di luar Amazon RDS menjadi instans basis data sumber. Untuk terhubung ke instans MySQL yang berjalan di luar Amazon RDS, Anda harus menentukan nilai `replication_user_name` dan `replication_user_password` yang menunjukkan pengguna replikasi yang memiliki izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans eksternal MySQL.
**Untuk mengonfigurasi instans eksternal MySQL sebagai instans basis data sumber**
1. Dengan menggunakan klien MySQL pilihan Anda, hubungkan ke instans eksternal MySQL dan buat akun pengguna yang akan digunakan untuk replikasi. Berikut adalah contohnya.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**catatan**
Tetapkan kata sandi selain penggugah (prompt) yang ditampilkan di sini sebagai praktik terbaik keamanan.
1. Pada instans eksternal MySQL, berikan hak istimewa `REPLICATION CLIENT` dan `REPLICATION SLAVE` kepada pengguna replikasi Anda. Contoh berikut memberikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada semua basis data untuk pengguna ‘repl\$1user’ domain Anda.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Untuk menggunakan replikasi terenkripsi, konfigurasikan instans basis data sumber untuk menggunakan koneksi SSL. Selain itu, impor sertifikat otoritas sertifikat, sertifikat klien, dan kunci klien ke dalam instans DB atau klaster DB menggunakan prosedur [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
**catatan**
Kami menawarkan prosedur tersimpan ini terutama untuk mengaktifkan replikasi dengan instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda menggunakan Aurora Replicas untuk mengelola replikasi dalam klaster DB Aurora MySQL jika memungkinkan. Untuk informasi tentang cara mengelola replikasi di klaster DB Aurora MySQL, lihat [Menggunakan Replika Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Setelah memanggil `mysql.rds_set_external_master` untuk mengonfigurasi instans DB Amazon RDS sebagai replika baca, Anda dapat memanggil [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) pada replika baca untuk memulai proses replikasi. Anda dapat memanggil [mysql.rds\$1reset\$1external\$1master versi 2)](#mysql_rds_reset_external_master) untuk menghapus konfigurasi replika baca.
Saat `mysql.rds_set_external_master` dipanggil, Amazon RDS mencatat waktu, pengguna, dan tindakan `set master` di tabel `mysql.rds_history` dan `mysql.rds_replication_status`.
### Contoh
Ketika dijalankan pada instans DB MySQL, contoh berikut mengonfigurasi instans DB menjadi replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source (RDS )
Mengonfigurasi instans DB Aurora MySQL agar tidak lagi menjadi replika baca dari instans MySQL yang berjalan di luar Amazon RDS.
**penting**
Untuk menjalankan prosedur ini, `autocommit` harus diaktifkan. Untuk mengaktifkannya, atur parameter `autocommit` ke `1`. Lihat informasi tentang cara mengubah parameter di [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md).
### Sintaks
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parameter
*host\$1name*
Nama host atau alamat IP instans MySQL yang berjalan di luar Amazon RDS untuk menjadi instans basis data sumber.
*host\$1port*
Port yang digunakan oleh instans MySQL yang berjalan di luar Amazon RDS untuk dikonfigurasi sebagai instans basis data sumber. Jika konfigurasi jaringan Anda mencakup replikasi port Secure Shell (SSH) yang mengubah nomor port, tentukan nomor port yang diekspos oleh SSH.
*replication\$1user\$1name*
ID pengguna dengan izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda memberikan akun yang digunakan sepenuhnya untuk replikasi dengan instans eksternal.
*replication\$1user\$1password*
Kata sandi ID pengguna yang ditentukan dalam `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nama log biner pada instans basis data sumber yang berisi informasi replikasi.
*mysql\$1binary\$1log\$1file\$1location*
Lokasi di log biner `mysql_binary_log_file_name` tempat replikasi mulai membaca informasi replikasi.
Anda dapat menentukan nama dan lokasi file binlog dengan menjalankan `SHOW MASTER STATUS` pada instans basis data sumber.
*ssl\$1encryption*
Nilai yang menentukan apakah enkripsi Lapisan Soket Aman (SSL) digunakan pada sambungan replikasi. 1 menentukan untuk menggunakan enkripsi SSL, 0 menentukan untuk tidak menggunakan enkripsi. Standarnya adalah 0.
Anda harus telah mengimpor sertifikat SSL khusus menggunakan [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) untuk mengaktifkan opsi ini. Jika Anda belum mengimpor sertifikat SSL kustom, maka atur parameter ini ke 0 dan gunakan untuk mengaktifkan SSL [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versi 3)](#mysql_rds_set_binlog_source_ssl) untuk replikasi log biner.
Opsi `SOURCE_SSL_VERIFY_SERVER_CERT` tidak didukung. Opsi ini diatur ke 0, yang berarti koneksi dienkripsi, tetapi sertifikat tidak diverifikasi.
### Catatan penggunaan
Pengguna administratif harus menjalankan prosedur `mysql.rds_set_external_source`. Prosedur ini harus dijalankan pada Aurora MySQL agar instance MySQL DB dikonfigurasi sebagai replika baca instance MySQL yang berjalan di luar Amazon RDS.
Sebelum menjalankan `mysql.rds_set_external_source`, Anda harus mengonfigurasi instans MySQL yang berjalan di luar Amazon RDS menjadi instans basis data sumber. Untuk terhubung ke instans MySQL yang berjalan di luar Amazon RDS, Anda harus menentukan nilai `replication_user_name` dan `replication_user_password` yang menunjukkan pengguna replikasi yang memiliki izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans eksternal MySQL.
**Untuk mengonfigurasi instans eksternal MySQL sebagai instans basis data sumber**
1. Dengan menggunakan klien MySQL pilihan Anda, hubungkan ke instans eksternal MySQL dan buat akun pengguna yang akan digunakan untuk replikasi. Berikut sebuah contoh.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**catatan**
Tetapkan kata sandi selain penggugah (prompt) yang ditampilkan di sini sebagai praktik terbaik keamanan.
1. Pada instans eksternal MySQL, berikan hak istimewa `REPLICATION CLIENT` dan `REPLICATION SLAVE` kepada pengguna replikasi Anda. Contoh berikut memberikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada semua basis data untuk pengguna ‘repl\$1user’ domain Anda.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Untuk menggunakan replikasi terenkripsi, konfigurasikan instans basis data sumber untuk menggunakan koneksi SSL. Selain itu, impor sertifikat otoritas sertifikat, sertifikat klien, dan kunci klien ke dalam instans DB atau klaster DB menggunakan prosedur [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**catatan**
Kami menawarkan prosedur tersimpan ini terutama untuk mengaktifkan replikasi dengan instans MySQL yang berjalan di luar Amazon RDS. Kami menyarankan Anda menggunakan Aurora Replicas untuk mengelola replikasi dalam klaster DB Aurora MySQL jika memungkinkan. Untuk informasi tentang cara mengelola replikasi di klaster DB Aurora MySQL, lihat [Menggunakan Replika Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Setelah memanggil `mysql.rds_set_external_source` untuk mengkonfigurasi Aurora MySQL DB instance sebagai replika baca, Anda dapat memanggil replika baca untuk memulai proses replikasi. [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) Anda dapat memanggil [mysql.rds\$1reset\$1external\$1source ( 3)](#mysql_rds_reset_external_source) untuk menghapus konfigurasi replika baca.
Saat `mysql.rds_set_external_source` dipanggil, Amazon RDS mencatat waktu, pengguna, dan tindakan `set master` di tabel `mysql.rds_history` dan `mysql.rds_replication_status`.
### Contoh
Ketika dijalankan pada Aurora MySQL DB, contoh berikut mengonfigurasi instans DB menjadi replika baca dari instance MySQL yang berjalan eksternal ke Amazon RDS.
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versi 2)
Mengonfigurasi instans primer Aurora MySQL untuk menerima replikasi masuk dari instans MySQL eksternal. Prosedur ini juga mengonfigurasi replikasi berdasarkan pengidentifikasi transaksi global (). GTIDs
Prosedur ini tidak mengonfigurasi replikasi tertunda, karena Aurora MySQL tidak mendukung replikasi tertunda.
### Sintaksis
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parameter
*host\$1name*
Nama host atau alamat IP instans MySQL yang berjalan di luar Aurora untuk menjadi sumber replikasi.
*host\$1port*
Port yang digunakan oleh instans MySQL yang berjalan di luar Aurora untuk dikonfigurasi sebagai sumber replikasi. Jika konfigurasi jaringan Anda mencakup replikasi port Secure Shell (SSH) yang mengubah nomor port, tentukan nomor port yang diekspos oleh SSH.
*replication\$1user\$1name*
ID pengguna dengan izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL yang berjalan di luar Aurora. Kami menyarankan Anda memberikan akun yang digunakan sepenuhnya untuk replikasi dengan instans eksternal.
*replication\$1user\$1password*
Kata sandi ID pengguna yang ditentukan dalam `replication_user_name`.
*ssl\$1encryption*
Opsi ini belum diterapkan. Default-nya adalah 0.
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Pengguna utama harus menjalankan prosedur `mysql.rds_set_external_master_with_auto_position`. Pengguna utama menjalankan prosedur ini pada instans primer dari klaster DB Aurora MySQL yang bertindak sebagai target replikasi. Ini dapat menjadi target replikasi dari instans DB MySQL eksternal atau klaster DB Aurora MySQL.
Prosedur ini didukung untuk Aurora MySQL versi 2. Untuk Aurora MySQL versi 3, gunakan prosedur [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versi 3)](#mysql_rds_set_external_source_with_auto_position) sebagai gantinya.
Sebelum Anda menjalankan `mysql.rds_set_external_master_with_auto_position`, konfigurasikan instans DB MySQL eksternal menjadi sumber replikasi. Agar terhubung ke instans MySQL eksternal, tentukan nilai untuk `replication_user_name` dan `replication_user_password`. Nilai-nilai ini harus menunjukkan pengguna replikasi yang memiliki izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL eksternal.
**Untuk mengonfigurasi instans MySQL eksternal sebagai sumber replikasi**
1. Dengan menggunakan klien MySQL pilihan Anda, hubungkan ke instans MySQL eksternal dan buat akun pengguna yang akan digunakan untuk replikasi. Berikut adalah contohnya.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Pada instans MySQL eksternal, berikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` kepada pengguna replikasi Anda. Contoh berikut memberikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada semua basis data untuk pengguna `'repl_user'` domain Anda.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Saat Anda memanggil `mysql.rds_set_external_master_with_auto_position`, Amazon RDS mencatat informasi tertentu. Informasi ini adalah waktu, pengguna, dan tindakan `"set master"` di tabel `mysql.rds_history` dan `mysql.rds_replication_status`.
Untuk melewati transaksi berbasis GTID tertentu yang diketahui menyebabkan masalah, Anda dapat menggunakan prosedur tersimpan [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versi 2 dan 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Untuk informasi selengkapnya tentang cara menggunakan replikasi berbasis GTID, lihat [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md).
### Contoh
Saat menjalankan di instans primer Aurora, contoh berikut mengonfigurasi klaster Aurora untuk bertindak sebagai replika baca dari instans MySQL yang berjalan di luar Aurora.
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versi 3)
Mengonfigurasi instans primer Aurora MySQL untuk menerima replikasi masuk dari instans MySQL eksternal. Prosedur ini juga mengonfigurasi replikasi berdasarkan pengidentifikasi transaksi global (). GTIDs
### Sintaks
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parameter
*host\$1name*
Nama host atau alamat IP instans MySQL yang berjalan di luar Aurora untuk menjadi sumber replikasi.
*host\$1port*
Port yang digunakan oleh instans MySQL yang berjalan di luar Aurora untuk dikonfigurasi sebagai sumber replikasi. Jika konfigurasi jaringan Anda mencakup replikasi port Secure Shell (SSH) yang mengubah nomor port, tentukan nomor port yang diekspos oleh SSH.
*replication\$1user\$1name*
ID pengguna dengan izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL yang berjalan di luar Aurora. Kami menyarankan Anda memberikan akun yang digunakan sepenuhnya untuk replikasi dengan instans eksternal.
*replication\$1user\$1password*
Kata sandi ID pengguna yang ditentukan dalam `replication_user_name`.
*ssl\$1encryption*
Opsi ini belum diterapkan. Default-nya adalah 0.
Gunakan [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versi 3)](#mysql_rds_set_binlog_source_ssl) untuk mengaktifkan SSL untuk replikasi log biner.
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Pengguna administratif harus menjalankan prosedur `mysql.rds_set_external_source_with_auto_position`. Pengguna administratif menjalankan prosedur ini pada instans primer dari klaster DB Aurora MySQL yang bertindak sebagai target replikasi. Ini dapat menjadi target replikasi dari instans DB MySQL eksternal atau klaster DB Aurora MySQL.
Prosedur ini didukung untuk Aurora MySQL versi 3. Prosedur ini tidak mengonfigurasi replikasi tertunda, karena Aurora MySQL tidak mendukung replikasi tertunda.
Sebelum Anda menjalankan `mysql.rds_set_external_source_with_auto_position`, konfigurasikan instans DB MySQL eksternal menjadi sumber replikasi. Agar terhubung ke instans MySQL eksternal, tentukan nilai untuk `replication_user_name` dan `replication_user_password`. Nilai-nilai ini harus menunjukkan pengguna replikasi yang memiliki izin `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada instans MySQL eksternal.
**Untuk mengonfigurasi instans MySQL eksternal sebagai sumber replikasi**
1. Dengan menggunakan klien MySQL pilihan Anda, hubungkan ke instans MySQL eksternal dan buat akun pengguna yang akan digunakan untuk replikasi. Berikut adalah contohnya.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Pada instans MySQL eksternal, berikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` kepada pengguna replikasi Anda. Contoh berikut memberikan hak akses `REPLICATION CLIENT` dan `REPLICATION SLAVE` pada semua basis data untuk pengguna `'repl_user'` domain Anda.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Saat Anda memanggil `mysql.rds_set_external_source_with_auto_position`, Amazon RDS mencatat informasi tertentu. Informasi ini adalah waktu, pengguna, dan tindakan `"set master"` di tabel `mysql.rds_history` dan `mysql.rds_replication_status`.
Untuk melewati transaksi berbasis GTID tertentu yang diketahui menyebabkan masalah, Anda dapat menggunakan prosedur tersimpan [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versi 2 dan 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Untuk informasi selengkapnya tentang cara menggunakan replikasi berbasis GTID, lihat [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md).
### Contoh
Saat menjalankan di instans primer Aurora, contoh berikut mengonfigurasi klaster Aurora untuk bertindak sebagai replika baca dari instans MySQL yang berjalan di luar Aurora.
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position (RDS )
Menetapkan mode replikasi untuk didasarkan pada posisi file log biner atau pada pengidentifikasi transaksi global ()GTIDs.
### Sintaks
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### Parameter
*auto\$1position\$1mode*
Nilai yang menunjukkan apakah akan menggunakan replikasi posisi file log atau replikasi berbasis GTID:
+ `0` – Gunakan metode replikasi berdasarkan posisi file log biner. Nilai default-nya `0`.
+ `1` – Gunakan metode replikasi berbasis GTID.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_set_master_auto_position`.
Prosedur ini didukung untuk Aurora MySQL versi 2.
## mysql.rds\$1set\$1read\$1only (Aurora MySQL versi 3)
Menghidupkan atau menonaktifkan `read_only` mode secara global untuk instans DB.
### Sintaks
```
CALL mysql.rds_set_read_only(mode);
```
### Parameter
*mode*
Nilai yang menunjukkan apakah `read_only` mode aktif atau tidak aktif secara global untuk instans DB:
+ `0`—`OFF`. Defaultnya adalah`0`.
+ `1` – `ON`
### Catatan penggunaan
Prosedur yang `mysql.rds_set_read_only` disimpan hanya memodifikasi `read_only` parameter. `innodb_read_only`Parameter tidak dapat diubah pada instans DB pembaca.
Perubahan `read_only` parameter tidak bertahan saat reboot. Untuk membuat perubahan permanen`read_only`, Anda harus menggunakan parameter cluster `read_only` DB.
Prosedur ini didukung untuk Aurora MySQL versi 3.06 dan lebih tinggi.
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versi 2)
Mengatur format log biner untuk sesi saat ini.
### Sintaksis
```
CALL mysql.rds_set_session_binlog_format(format);
```
### Parameter
*format*
Nilai yang menunjukkan format log biner untuk sesi saat ini:
+ `STATEMENT` – Sumber replikasi menulis peristiwa ke log biner berdasarkan pernyataan SQL.
+ `ROW` – Sumber replikasi menulis peristiwa ke log biner yang menunjukkan perubahan pada baris tabel individual.
+ `MIXED` – Pencatatan log umumnya didasarkan pada pernyataan SQL, tetapi beralih ke baris dalam kondisi tertentu. Untuk informasi selengkapnya, lihat [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) dalam dokumentasi MySQL.
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Untuk menggunakan prosedur tersimpan ini, Anda harus memiliki pencatatan log biner yang dikonfigurasi untuk sesi saat ini.
Untuk Aurora, prosedur ini didukung untuk Aurora MySQL versi 2.12 dan versi yang lebih tinggi yang kompatibel dengan MySQL 5.7.
## mysql.rds\$1set\$1source\$1auto\$1position ( 3)
Menetapkan mode replikasi untuk didasarkan pada posisi file log biner atau pada pengidentifikasi transaksi global ()GTIDs.
### Sintaks
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### Parameter
*auto\$1position\$1mode*
Nilai yang menunjukkan apakah akan menggunakan replikasi posisi file log atau replikasi berbasis GTID:
+ `0` – Gunakan metode replikasi berdasarkan posisi file log biner. Nilai default-nya `0`.
+ `1` – Gunakan metode replikasi berbasis GTID.
### Catatan penggunaan
Untuk klaster DB Aurora MySQL, Anda memanggil prosedur tersimpan ini saat terhubung ke instans primer.
Pengguna administratif harus menjalankan prosedur `mysql.rds_set_source_auto_position`.
## mysql.rds\$1skip\$1repl\$1error
Melewati dan menghapus kesalahan replikasi pada replika baca DB MySQL.
### Sintaksis
```
CALL mysql.rds_skip_repl_error;
```
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_skip_repl_error` pada replika baca. Untuk informasi selengkapnya tentang prosedur ini, lihat [Melewati kesalahan replikasi saat ini](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError).
Untuk menentukan apakah ada kesalahan, jalankan perintah `SHOW REPLICA STATUS\G` MySQL. Jika kesalahan replikasi tidak parah, Anda dapat menjalankan `mysql.rds_skip_repl_error` untuk melewati kesalahan tersebut. Jika ada beberapa kesalahan, `mysql.rds_skip_repl_error` akan menghapus kesalahan pertama, lalu memberi peringatan bahwa ada kesalahan lain. Anda kemudian dapat menggunakan `SHOW REPLICA STATUS\G` untuk menentukan tindakan yang benar untuk kesalahan berikutnya. Untuk informasi tentang nilai yang ditampilkan, lihat [SHOW REPLICA STATUS statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) dalam dokumentasi MySQL.
Untuk informasi selengkapnya tentang cara mengatasi kesalahan replikasi dengan Aurora MySQL, lihat [](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR).
#### Kesalahan replikasi terhenti
Ketika memanggil prosedur `mysql.rds_skip_repl_error`, Anda mungkin menerima pesan kesalahan yang menyatakan bahwa replika tidak berfungsi atau dinonaktifkan.
Pesan kesalahan ini muncul jika Anda menjalankan prosedur pada instans primer, bukan replika baca. Anda harus menjalankan prosedur ini pada replika baca agar prosedur berfungsi.
Pesan kesalahan ini mungkin juga muncul jika Anda menjalankan prosedur pada replika baca, tetapi replikasi tidak berhasil dimulai ulang.
Jika Anda perlu melewati sejumlah besar kesalahan, lag replikasi dapat meningkat hingga melampaui periode retensi default untuk file log biner (binlog). Dalam hal ini, Anda mungkin mengalami kesalahan fatal karena file binlog dibersihkan sebelum diputar ulang pada replika baca. Penghapusan ini menyebabkan replikasi berhenti, dan Anda tidak dapat lagi memanggil perintah `mysql.rds_skip_repl_error` untuk melewati kesalahan replikasi.
Anda dapat memitigasi masalah ini dengan meningkatkan jumlah jam retensi file binlog tersebut pada instans basis data sumber Anda. Setelah meningkatkan waktu retensi binlog, Anda dapat memulai ulang replikasi dan memanggil perintah `mysql.rds_skip_repl_error` sesuai kebutuhan.
Untuk mengatur waktu retensi binlog, gunakan prosedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) dan tentukan parameter konfigurasi `'binlog retention hours'` bersama dengan jumlah jam untuk mempertahankan file binlog di klaster DB. Contoh berikut menetapkan periode penyimpanan file binlog menjadi 48 jam.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Memulai replikasi dari klaster DB Aurora MySQL.
**catatan**
Anda dapat menggunakan prosedur tersimpan [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versi 3)](#mysql_rds_start_replication_until) atau [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versi 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) untuk memulai replikasi dari instans DB Aurora MySQL dan menghentikan replikasi di lokasi file log biner yang telah ditentukan.
### Sintaksis
```
CALL mysql.rds_start_replication;
```
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_start_replication`.
Untuk mengimpor data dari instance MySQL eksternal ke Amazon RDS, `mysql.rds_start_replication` panggil replika baca untuk memulai proses replikasi setelah Anda [mysql.rds\$1set\$1external\$1master 2)](#mysql_rds_set_external_master) memanggil [mysql.rds\$1set\$1external\$1source (RDS )](#mysql_rds_set_external_source) atau membangun konfigurasi replikasi. Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md).
Untuk mengekspor data ke instans MySQL yang berjalan di luar Amazon RDS, panggil `mysql.rds_start_replication` dan `mysql.rds_stop_replication` pada replika baca untuk mengontrol beberapa tindakan replikasi, seperti membersihkan log biner. Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md).
Anda juga dapat memanggil `mysql.rds_start_replication` pada replika baca untuk memulai kembali proses replikasi apa pun yang sebelumnya Anda hentikan dengan memanggil `mysql.rds_stop_replication`. Untuk informasi selengkapnya, lihat [Kesalahan replikasi terhenti](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped).
## mysql.rds\$1start\$1replication\$1until (Aurora MySQL versi 3)
Memulai replikasi dari klaster DB Aurora MySQL dan menghentikan replikasi di lokasi file log biner yang telah ditentukan.
### Sintaks
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### Parameter
*replication\$1log\$1file*
Nama log biner pada instans basis data sumber yang berisi informasi replikasi.
*replication\$1stop\$1point *
Lokasi di log biner `replication_log_file` tempat replikasi akan berhenti.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_start_replication_until`.
Prosedur ini didukung untuk Aurora MySQL versi 3.04 dan yang lebih tinggi.
Prosedur `mysql.rds_start_replication_until` tersimpan tidak didukung untuk replikasi terkelola, yang mencakup hal-hal berikut:
+ [Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Memigrasikan data dari instans DB RDS for MySQL ke klaster DB Amazon Aurora MySQL menggunakan replika baca Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
Nama file yang ditentukan untuk parameter `replication_log_file` harus cocok dengan nama file binlog instans basis data sumber.
Jika parameter `replication_stop_point` menentukan lokasi perhentian di masa lalu, replikasi akan segera dihentikan.
### Contoh
Contoh berikut memulai replikasi dan mereplikasi perubahan hingga mencapai lokasi `120` di file log biner `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
Menghentikan replikasi dari instans DB MySQL.
### Sintaks
```
CALL mysql.rds_stop_replication;
```
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_stop_replication`.
Jika Anda mengonfigurasi replikasi untuk mengimpor data dari instans MySQL yang berjalan di luar Amazon RDS, Anda memanggil `mysql.rds_stop_replication` pada replika baca untuk menghentikan proses replikasi setelah impor selesai. Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md).
Jika Anda mengonfigurasi replikasi untuk mengekspor data ke instans MySQL yang berjalan di luar Amazon RDS, Anda memanggil `mysql.rds_start_replication` dan `mysql.rds_stop_replication` pada replika baca untuk mengontrol beberapa tindakan replikasi, seperti membersihkan log biner. Untuk informasi selengkapnya, lihat [Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner)](AuroraMySQL.Replication.MySQL.md).
Prosedur `mysql.rds_stop_replication` tersimpan tidak didukung untuk replikasi terkelola, yang mencakup hal-hal berikut:
+ [Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Memigrasikan data dari instans DB RDS for MySQL ke klaster DB Amazon Aurora MySQL menggunakan replika baca Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# Mengakhiri sesi atau kueri
Prosedur tersimpan berikut mengakhiri sesi atau kueri.
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
Mengakhiri koneksi ke server MySQL.
### Sintaksis
```
CALL mysql.rds_kill(processID);
```
### Parameter
*processID*
Identitas utas koneksi akan diakhiri.
### Catatan penggunaan
Setiap koneksi ke server MySQL berjalan di utas terpisah. Untuk mengakhiri koneksi, gunakan prosedur `mysql.rds_kill` dan teruskan ID utas koneksi tersebut. Untuk mendapatkan ID utas, gunakan perintah [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) MySQL.
### Contoh
Contoh berikut mengakhiri koneksi dengan ID utas 4243:
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Mengakhiri kueri yang berjalan pada server MySQL.
### Sintaksis
```
CALL mysql.rds_kill_query(processID);
```
### Parameter
*processID*
Identitas proses atau utas yang menjalankan kueri yang akan diakhiri.
### Catatan penggunaan
Untuk mengakhiri kueri yang berjalan pada server MySQL, gunakan prosedur `mysql_rds_kill_query` dan teruskan ID koneksi utas yang menjalankan kueri. Lalu, prosedur akan mengakhiri koneksi.
Untuk mendapatkan ID, lakukan kueri pada [tabel INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) MySQL atau gunakan perintah [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) MySQL. Nilai dalam kolom ID dari `SHOW PROCESSLIST` atau `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` adalah *processID*.
### Contoh
Contoh berikut mengakhiri kueri dengan ID utas kueri 230040:
```
CALL mysql.rds_kill_query(230040);
```
# Mereplikasi transaksi menggunakan GTIDs
Prosedur tersimpan berikut mengontrol bagaimana transaksi direplikasi menggunakan pengidentifikasi transaksi global (GTIDs) dengan Aurora MySQL. Untuk mempelajari cara menggunakan replikasi berdasarkan GTIDs Aurora MySQL, lihat. [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md)
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versi 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL versi 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versi 2 dan 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versi 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versi 3)
Mengonfigurasi opsi `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` dari pernyataan `CHANGE REPLICATION SOURCE TO`. Hal ini akan membuat saluran replikasi menetapkan GTID ke transaksi replikasi yang tidak memilikinya. Dengan begitu, Anda dapat melakukan replikasi log biner dari sumber yang tidak menggunakan replikasi berbasis GTID ke replika yang menggunakan replikasi tersebut. *Untuk informasi selengkapnya, lihat [MENGUBAH SUMBER REPLIKASI MENJADI Pernyataan](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) dan [Replikasi Dari Sumber Tanpa GTIDs ke Replika Dengan GTIDs di Manual Referensi](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) MySQL.*
### Sintaks
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### Parameter
*gtid\$1option*
Nilai string. Nilai yang diizinkan adalah `OFF`, `LOCAL`, atau UUID yang ditentukan.
### Catatan penggunaan
Prosedur ini memiliki efek yang sama seperti mengeluarkan pernyataan `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` di komunitas MySQL.
GTID harus diubah `ON` untuk disetel *gtid\$1option* ke `LOCAL` atau UUID tertentu.
Defaultnya adalah `OFF`, yang artinya fitur tersebut tidak digunakan.
`LOCAL` menetapkan GTID termasuk UUID replika itu sendiri (pengaturan `server_uuid`).
Meneruskan parameter yang merupakan UUID akan menetapkan GTID yang menyertakan UUID tertentu, seperti pengaturan `server_uuid` untuk server sumber replikasi.
### Contoh
Untuk menonaktifkan fitur ini:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)
```
Untuk menggunakan UUID replika itu sendiri:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)
```
Untuk menggunakan UUID yang ditentukan:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)
```
## mysql.rds\$1gtid\$1purged (Aurora MySQL versi 3)
Menetapkan nilai global variabel sistem `gtid_purged` ke set pengidentifikasi transaksi global (GTID) yang diberikan. Variabel `gtid_purged` sistem adalah set GTID yang terdiri GTIDs dari semua transaksi yang telah dilakukan di server, tetapi tidak ada dalam file log biner apa pun di server.
Untuk memungkinkan kompatibilitas dengan MySQL 8.0, ada dua cara untuk mengatur nilai `gtid_purged`:
+ Ganti nilai `gtid_purged` dengan set GTID yang Anda tentukan.
+ Tambahkan set GTID yang Anda tentukan ke set GTID yang sudah ada di `gtid_purged`.
### Sintaksis
Untuk mengganti nilai `gtid_purged` dengan set GTID yang Anda tentukan:
```
CALL mysql.rds_gtid_purged (gtid_set);
```
Untuk menambahkan nilai `gtid_purged` ke set GTID yang Anda tentukan:
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### Parameter
*gtid\$1set*
Nilai *gtid\$1set* harus menjadi superset dari nilai saat ini`gtid_purged`, dan tidak dapat berpotongan dengan. `gtid_subtract(gtid_executed,gtid_purged)` Artinya, set GTID baru harus menyertakan apa pun GTIDs yang sudah ada`gtid_purged`, dan tidak dapat menyertakan `gtid_executed` yang belum dibersihkan. GTIDs *gtid\$1set*Parameter juga tidak dapat menyertakan apa pun GTIDs yang ada di `gtid_owned` set global, GTIDs untuk transaksi yang saat ini sedang diproses di server.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_gtid_purged`.
Prosedur ini didukung untuk Aurora MySQL versi 3.04 dan yang lebih tinggi.
### Contoh
Contoh berikut menetapkan GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` ke variabel global `gtid_purged`.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versi 2 dan 3)
Melewati replikasi transaksi dengan pengenal transaksi global (GTID) yang ditentukan pada instans primer Aurora.
Anda dapat menggunakan prosedur ini untuk pemulihan bencana ketika transaksi GTID tertentu diketahui menyebabkan masalah. Gunakan prosedur tersimpan ini untuk melewati transaksi bermasalah. Contoh transaksi bermasalah mencakup transaksi yang menonaktifkan replikasi, menghapus data penting, atau menyebabkan instans DB menjadi tidak tersedia.
### Sintaksis
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parameter
*gtid\$1to\$1skip*
GTID dari transaksi replikasi yang akan dilewati.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_skip_transaction_with_gtid`.
Prosedur ini didukung untuk Aurora MySQL versi 2 dan 3.
### Contoh
Contoh berikut melewati replikasi transaksi dengan GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versi 3)
Memulai replikasi dari klaster DB Aurora MySQL dan menghentikan replikasi segera setelah pengidentifikasi transaksi global (GTID) yang ditentukan.
### Sintaksis
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parameter
*gtid*
GTID setelah replikasi dihentikan.
### Catatan penggunaan
Pengguna utama harus menjalankan prosedur `mysql.rds_start_replication_until_gtid`.
Prosedur ini didukung untuk Aurora MySQL versi 3.04 dan yang lebih tinggi.
Prosedur `mysql.rds_start_replication_until_gtid` tersimpan tidak didukung untuk replikasi terkelola, yang mencakup hal-hal berikut:
+ [Mereplikasi kluster DB MySQL Amazon Aurora Wilayah AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Memigrasikan data dari instans DB RDS for MySQL ke klaster DB Amazon Aurora MySQL menggunakan replika baca Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
Saat parameter `gtid` menentukan transaksi yang telah dijalankan oleh replika, replikasi akan segera dihentikan.
### Contoh
Contoh berikut memulai replikasi dan mereplikasi perubahan hingga mencapai GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Memutar log kueri
Prosedur tersimpan berikut memutar SQL log Saya ke tabel cadangan. Untuk informasi selengkapnya, lihat [File log database MySQL Aurora](USER_LogAccess.Concepts.MySQL.md).
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
Merotasi tabel `mysql.general_log` ke tabel cadangan.
### Sintaks
```
CALL mysql.rds_rotate_general_log;
```
### Catatan penggunaan
Anda bisa merotasi tabel `mysql.general_log` ke tabel cadangan dengan memanggil prosedur `mysql.rds_rotate_general_log`. Saat tabel log dirotasi, tabel log saat ini disalin ke tabel log cadangan dan entri di tabel log saat ini dihapus. Jika sudah ada, tabel log cadangan akan dihapus sebelum tabel log saat ini disalin ke cadangan. Anda dapat meminta tabel log cadangan jika diperlukan. Tabel log cadangan untuk tabel `mysql.general_log` bernama `mysql.general_log_backup`.
Anda dapat menjalankan prosedur ini hanya ketika parameter `log_output` diatur ke `TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Merotasi tabel `mysql.slow_log` ke tabel cadangan.
### Sintaks
```
CALL mysql.rds_rotate_slow_log;
```
### Catatan penggunaan
Anda bisa merotasi tabel `mysql.slow_log` ke tabel cadangan dengan memanggil prosedur `mysql.rds_rotate_slow_log`. Saat tabel log dirotasi, tabel log saat ini disalin ke tabel log cadangan dan entri di tabel log saat ini dihapus. Jika sudah ada, tabel log cadangan akan dihapus sebelum tabel log saat ini disalin ke cadangan.
Anda dapat meminta tabel log cadangan jika diperlukan. Tabel log cadangan untuk tabel `mysql.slow_log` bernama `mysql.slow_log_backup`.
# Mengatur dan menampilkan konfigurasi log biner
Prosedur tersimpan berikut mengatur dan menampilkan parameter konfigurasi, seperti untuk retensi file log biner.
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Menentukan jumlah jam untuk mempertahankan log biner atau jumlah detik untuk menunda replikasi.
### Sintaksis
```
CALL mysql.rds_set_configuration(name,value);
```
### Parameter
*name*
Nama parameter konfigurasi yang akan diatur.
*value*
Nilai parameter konfigurasi.
### Catatan penggunaan
Prosedur `mysql.rds_set_configuration` mendukung parameter konfigurasi berikut:
+ [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
Parameter konfigurasi disimpan secara permanen dan bertahan dari boot ulang atau failover instans DB apa pun.
#### binlog retention hours
Parameter `binlog retention hours` digunakan untuk menentukan jumlah jam untuk mempertahankan file log biner. Amazon Aurora biasanya membersihkan log biner sesegera mungkin, tetapi log biner mungkin masih diperlukan untuk replikasi dengan basis data MySQL di luar Aurora.
Nilai default `binlog retention hours` adalah `NULL`. Untuk Aurora MySQL, `NULL` menandakan bahwa log biner dibersihkan dengan lambat. Log biner Aurora MySQL mungkin masih berada di dalam sistem untuk jangka waktu tertentu, yang biasanya tidak lebih dari satu hari.
Untuk menentukan jumlah jam guna mempertahankan log biner pada klaster DB, gunakan prosedur tersimpan `mysql.rds_set_configuration` dan tentukan periode dengan waktu yang cukup untuk terjadinya proses replikasi, seperti yang diperlihatkan dalam contoh berikut.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**catatan**
Anda tidak dapat menggunakan nilai `0` untuk `binlog retention hours`.
Untuk Aurora MySQL versi 2.11.0 dan yang lebih tinggi dan klaster DB versi 3, nilai `binlog retention hours` maksimumnya adalah 2160 (90 hari).
Setelah Anda mengatur periode retensi, pantau penggunaan penyimpanan untuk instans DB guna memastikan bahwa log biner yang dipertahankan tidak memakan terlalu banyak ruang penyimpanan.
## mysql.rds\$1show\$1configuration
Jumlah jam untuk mempertahankan log biner.
### Sintaksis
```
CALL mysql.rds_show_configuration;
```
### Catatan penggunaan
Untuk memverifikasi jumlah jam Amazon RDS mempertahankan log biner, gunakan prosedur tersimpan `mysql.rds_show_configuration`.
### Contoh
Contoh berikut menampilkan periode retensi:
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Aurora My SQL —tabel information\$1schema spesifik
Aurora My SQL memiliki `information_schema` tabel tertentu yang khusus untuk Aurora.
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
Tabel `information_schema.aurora_global_db_instance_status` berisi informasi tentang status semua instans DB dalam klaster DB primer dan sekunder di basis data global. Tabel berikut menunjukkan kolom yang dapat Anda gunakan. Kolom yang tersisa hanya ditujukan untuk penggunaan internal Aurora.
**catatan**
Tabel skema informasi ini hanya tersedia dengan Aurora SQL My versi 3.04.0 dan database global yang lebih tinggi.
| Kolom | Jenis data | Deskripsi |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | Pengidentifikasi instans DB. |
| SESSION\$1ID | varchar(100) | Pengidentifikasi unik untuk sesi saat ini. Nilai MASTER\$1SESSION\$1ID mengidentifikasi instans DB Penulis (primer). |
| AWS\$1REGION | varchar(100) | Wilayah AWS Di mana instance database global ini berjalan. Untuk daftar Wilayah, lihat [Ketersediaan wilayah](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| DURABLE\$1LSN | bigint unsigned | Nomor urutan log (LSN) dibuat tahan lama dalam penyimpanan. Nomor urutan log (LSN) adalah nomor urut unik yang mengidentifikasi catatan dalam log transaksi database. LSNsdipesan sedemikian rupa sehingga yang lebih besar LSN mewakili transaksi selanjutnya. |
| HIGHEST\$1LSN\$1RCVD | bigint unsigned | Yang tertinggi LSN diterima oleh instans DB dari instans DB penulis. |
| OLDEST\$1 READ \$1 \$1 VIEW TRX \$1 ID | bigint unsigned | ID transaksi terlama yang dapat dibuang oleh instans DB penulis. |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | Yang tertua LSN digunakan oleh instans DB untuk membaca dari penyimpanan. |
| VISIBILITY\$1 LAG \$1IN\$1 MSEC | float(10,0) unsigned | Untuk pembaca di klaster DB primer, seberapa jauh instans DB ini tertinggal dari instans DB penulis dalam milidetik. Untuk pembaca di DB klaster sekunder, seberapa jauh DB instans ini tertinggal dari volume sekunder dalam milidetik. |
## information\$1schema.aurora\$1global\$1db\$1status
`information_schema.aurora_global_db_status`Tabel berisi informasi tentang berbagai aspek lag database global Aurora, khususnya, lag penyimpanan Aurora yang mendasarinya (disebut lag daya tahan) dan jeda antara tujuan titik pemulihan (). RPO Tabel berikut menunjukkan kolom yang dapat Anda gunakan. Kolom yang tersisa hanya ditujukan untuk penggunaan internal Aurora.
**catatan**
Tabel skema informasi ini hanya tersedia dengan Aurora SQL My versi 3.04.0 dan database global yang lebih tinggi.
| Kolom | Jenis data | Deskripsi |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | Wilayah AWS Di mana instance database global ini berjalan. Untuk daftar Wilayah, lihat [Ketersediaan wilayah](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | Nomor urutan log tertinggi (LSN) yang saat ini ada di cluster DB ini. Nomor urutan log (LSN) adalah nomor urut unik yang mengidentifikasi catatan dalam log transaksi database. LSNsdipesan sedemikian rupa sehingga yang lebih besar LSN mewakili transaksi selanjutnya. |
| DURABILITY\$1 LAG \$1IN\$1 MILLISECONDS | float(10,0) unsigned | Perbedaan nilai stempel waktu antara HIGHEST\$1LSN\$1WRITTEN di klaster DB sekunder dan HIGHEST\$1LSN\$1WRITTEN di klaster DB primer. Nilai ini selalu 0 pada klaster DB primer di basis data global Aurora. |
| RPO\$1 LAG \$1IN\$1 MILLISECONDS | float(10,0) unsigned | Tujuan titik pemulihan (RPO) lag. RPOKelambatan adalah waktu yang dibutuhkan untuk transaksi pengguna terbaru COMMIT untuk disimpan di cluster DB sekunder setelah disimpan di cluster DB utama dari database global Aurora. Nilai ini selalu 0 pada klaster DB primer basis data global Aurora. Secara sederhana, metrik ini menghitung tujuan titik pemulihan untuk setiap cluster Aurora SQL My DB di database global Aurora, yaitu, berapa banyak data yang mungkin hilang jika ada pemadaman. Seperti halnya lag, RPO diukur dalam waktu. |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | Stempel waktu yang menentukan kapan nilai terakhir dihitung untuk DURABILITY\$1LAG\$1IN\$1MILLISECONDS dan RPO\$1LAG\$1IN\$1MILLISECONDS. Nilai waktu seperti 1970-01-01 00:00:00\$100 menunjukkan bahwa ini adalah klaster DB primer. |
| OLDEST\$1 READ \$1 \$1 VIEW TRX \$1 ID | bigint unsigned | ID transaksi terlama yang dapat dibuang oleh instans DB penulis. |
## information\$1schema.replica\$1host\$1status
Tabel `information_schema.replica_host_status` berisi informasi replikasi. Kolom yang dapat Anda gunakan ditunjukkan pada tabel berikut. Kolom yang tersisa hanya ditujukan untuk penggunaan internal Aurora.
| Kolom | Jenis data | Deskripsi |
| --- | --- | --- |
| CPU | double | CPUPersentase penggunaan host replika. |
| ADALAH\$1 CURRENT | tinyint | Apakah replika adalah yang terbaru atau tidak. |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | Waktu pembaruan terakhir terjadi. Digunakan untuk menentukan apakah sebuah catatan sudah usang. |
| REPLICA\$1 LAG \$1IN\$1 MILLISECONDS | double | Lag replika dalam milidetik. |
| SERVER\$1ID | varchar(100) | ID server basis data. |
| SESSION\$1ID | varchar(100) | ID sesi basis data. Digunakan untuk menentukan apakah instans DB adalah instans penulis atau pembaca. |
**catatan**
Ketika instans replika tertinggal, informasi yang dikueri dari tabel `information_schema.replica_host_status` milik instans replika tersebut mungkin sudah usang. Dalam situasi ini, kami menyarankan Anda mengueri dari instans penulis sebagai gantinya.
Meskipun tabel `mysql.ro_replica_status` memiliki informasi serupa, kami tidak menyarankan Anda untuk menggunakannya.
## information\$1schema.aurora\$1forwarding\$1processlist
Tabel `information_schema.aurora_forwarding_processlist` berisi informasi tentang proses terkait dalam penerusan penulisan.
Konten tabel ini hanya terlihat pada instans DB penulis untuk klaster DB dengan penerusan penulisan global atau penerusan penulisan dalam klaster diaktifkan. Set hasil kosong dihasilkan pada instans DB pembaca.
| Bidang | Jenis data | Deskripsi |
| --- | --- | --- |
| ID | bigint | Pengidentifikasi koneksi pada instans DB penulis. Pengidentifikasi ini adalah nilai yang sama yang ditampilkan di kolom Id untuk pernyataan SHOW PROCESSLIST dan dihasilkan oleh fungsi CONNECTION\$1ID() di dalam thread. |
| USER | varchar(32) | SQLPengguna saya yang mengeluarkan pernyataan. |
| HOST | varchar(255) | SQLKlien saya yang mengeluarkan pernyataan itu. Untuk pernyataan yang diteruskan, bidang ini menunjukkan alamat host klien aplikasi yang membuat koneksi pada instans DB pembaca yang melakukan penerusan. |
| DB | varchar(64) | Basis data default untuk thread. |
| COMMAND | varchar(16) | Jenis perintah yang dijalankan thread atas nama klien, atau Sleep jika sesinya idle. Untuk deskripsi perintah thread, lihat SQL Dokumentasi saya tentang [Nilai Perintah Thread](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) dalam SQL dokumentasi Saya. |
| TIME | int | Waktu dalam hitungan detik saat thread berada dalam status saat ini. |
| STATE | varchar(64) | Tindakan, peristiwa, atau status yang menunjukkan apa yang dilakukan thread. Untuk deskripsi nilai status, lihat [Status Utas Umum](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) dalam SQL dokumentasi Saya. |
| INFO | longtext | Pernyataan bahwa thread sedang mengeksekusi pernyataan, atau NULL jika tidak sedang mengeksekusi pernyataan. Pernyataan ini mungkin adalah pernyataan yang dikirim ke server, atau mungkin adalah pernyataan terdalam jika mengeksekusi pernyataan lain. |
| ADALAH\$1 FORWARDED | bigint | Menunjukkan apakah thread diteruskan dari instans DB pembaca. |
| REPLICASESSION\$1 ID | bigint | Pengidentifikasi koneksi pada Replika Aurora. Pengidentifikasi ini adalah nilai yang sama yang ditampilkan di kolom Id untuk pernyataan SHOW PROCESSLIST pada instans DB Aurora pembaca yang melakukan penerusan. |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | Pengidentifikasi instans DB dari thread penerusan. |
| REPLICA\$1CLUSTER\$1NAME | varchar(64) | Pengidentifikasi klaster DB dari thread penerusan. Untuk penerusan penulisan dalam klaster, pengidentifikasi ini adalah klaster DB yang sama dengan instans DB penulis. |
| REPLICA\$1REGION | varchar(64) | Wilayah AWS Dari mana utas penerusan berasal. Untuk penerusan penulisan dalam klaster, Wilayah ini adalah Wilayah AWS yang sama dengan instans DB penulis. |