Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah untuk Amazon RDS
Gunakan bagian berikut untuk membantu memecahkan masalah yang Anda miliki dengan instans DB di Amazon RDS dan Amazon Aurora.
**Topics**
+ [Tidak dapat terhubung ke instans DB Amazon RDS](#CHAP_Troubleshooting.Connecting)
+ [Masalah keamanan Amazon RDS](#CHAP_Troubleshooting.Security)
+ [Memecahkan masalah status jaringan yang tidak kompatibel](#CHAP_Troubleshooting.IncompatibleNetworkMode)
+ [Mengatur ulang kata sandi pemilik instans DB](#CHAP_Troubleshooting.ResetPassword)
+ [Penghentian atau boot ulang instans DB Amazon RDS](#CHAP_Troubleshooting.Reboots)
+ [Perubahan parameter DB Amazon RDS tidak diberlakukan](#CHAP_Troubleshooting.Parameters)
+ [Instans DB Amazon RDS kehabisan ruang penyimpanan](#CHAP_Troubleshooting.Storage)
+ [Instans DB Amazon RDS tidak cukup tersedia](#CHAP_Troubleshooting.Capacity)
+ [Masalah memori yang dapat dikosongkan di Amazon RDS](#Troubleshooting.FreeableMemory)
+ [Masalah MySQL dan MariaDB](#CHAP_Troubleshooting.MySQL)
+ [Tidak dapat mengatur periode retensi cadangan menjadi 0](#CHAP_Troubleshooting.Backup.Retention)
Untuk informasi tentang masalah debug menggunakan API Amazon RDS, lihat [Pemecahan masalah aplikasi di Amazon RDS](APITroubleshooting.md).
## Tidak dapat terhubung ke instans DB Amazon RDS
Jika Anda tidak dapat terhubung ke instans DB, berikut adalah penyebab-penyebab umumnya:
+ **Aturan masuk** – Aturan akses yang diberlakukan oleh firewall lokal dan alamat IP yang diizinkan untuk mengakses instans DB mungkin tidak cocok. Kemungkinan besar masalahnya adalah aturan masuk dalam grup keamanan Anda.
Secara default, instans DB tidak mengizinkan akses. Akses diberikan melalui grup keamanan yang terkait dengan VPC yang mengizinkan lalu lintas masuk dan keluar dari instans DB. Jika perlu, tambahkan aturan masuk dan keluar untuk situasi khusus Anda ke grup keamanan. Anda dapat menentukan alamat IP, rentang alamat IP, atau grup keamanan VPC lainnya.
**catatan**
Saat menambahkan aturan masuk baru, Anda dapat memilih **IP Saya** untuk **Sumber** agar dapat mengizinkan akses ke instans DB dari alamat IP yang terdeteksi di browser.
Untuk informasi selengkapnya tentang menyiapkan grup keamanan, lihat [Memberikan akses ke instans DB di VPC Anda dengan membuat grup keamanan](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
**catatan**
Koneksi klien dari alamat IP di dalam rentang 169.254.0.0/16 tidak diizinkan. Rentang ini adalah Automatic Private IP Addressing Range (APIPA) yang digunakan untuk alamat tautan lokal.
+ **Aksesibilitas publik** – Untuk terhubung ke instans DB dari luar VPC, seperti menggunakan aplikasi klien, instans harus memiliki alamat IP publik yang ditetapkan untuk instans tersebut.
Agar instans dapat diakses oleh publik, ubah instans dan pilih **Ya** di bagian **Aksesibilitas publik**. Untuk informasi selengkapnya, lihat [Menyembunyikan instans DB dalam VPC dari internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding).
+ **Port** — Port yang Anda tentukan saat membuat instans DB tidak dapat digunakan untuk mengirim atau menerima komunikasi karena pembatasan firewall lokal Anda. Untuk menentukan apakah jaringan Anda memungkinkan port tertentu digunakan untuk komunikasi masuk dan keluar, hubungi administrator jaringan Anda.
+ **Ketersediaan** – Untuk instans DB yang baru dibuat, instans DB memiliki status `creating` hingga instans DB siap digunakan. Ketika statusnya berubah menjadi `available`, Anda dapat terhubung ke instans DB. Tergantung pada ukuran instans DB Anda, perlu waktu hingga 20 menit sebelum instans tersedia.
+ **Gateway internet** – Agar instans DB dapat diakses publik, subnet dalam grup subnet DB tersebut harus memiliki gateway internet.
**Mengonfigurasi gateway internet untuk subnet**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Basis Data** lalu pilih instans DB.
1. Di tab **Konektivitas & keamanan**, tuliskan nilai ID VPC di **VPC** dan subnet ID di **Subnet**.
1. Buka konsol Amazon VPC di. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)
1. Di panel navigasi, pilih **Gateway Internet**. Pastikan ada gateway internet yang dilampirkan ke VPC Anda. Atau, pilih **Buat Gateway Internet** untuk membuat gateway internet. Pilih gateway internet, lalu pilih **Lampirkan ke VPC** dan ikuti arahan untuk melampirkannya ke VPC Anda.
1. Di panel navigasi, pilih **Subnet**, lalu pilih subnet Anda.
1. Di tab **Tabel Rute**, pastikan ada rute dengan `0.0.0.0/0` sebagai tujuan dan gateway internet untuk VPC sebagai target.
Jika Anda terhubung ke instans menggunakan IPv6 alamatnya, verifikasi bahwa ada rute untuk semua IPv6 lalu lintas (`::/0`) yang mengarah ke gateway internet. Jika tidak, lakukan tindakan berikut:
1. Pilih ID tabel rute (rtb-*xxxxxxxx*) untuk menavigasi ke tabel rute.
1. Di tab **Rute**, pilih **Edit rute**. Pilih **Tambahkan rute**, gunakan `0.0.0.0/0` sebagai tujuan, dan gateway internet sebagai target.
Untuk IPv6, pilih **Tambahkan rute**, gunakan `::/0` sebagai tujuan dan gateway internet sebagai target.
1. Pilih **Simpan rute**.
Juga, jika Anda mencoba untuk terhubung ke IPv6 endpoint, pastikan bahwa rentang IPv6 alamat klien diotorisasi untuk terhubung ke instans DB.
Untuk informasi selengkapnya, lihat [Menggunakan instans DB di VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md).
Untuk masalah koneksi khusus mesin, lihat topik berikut:
+ [Memecahkan masalah koneksi ke instans SQL Server DB Anda](USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.md)
+ [Memecahkan masalah koneksi ke instans Oracle DB Anda](USER_ConnectToOracleInstance.Troubleshooting.md)
+ [Memecahkan masalah koneksi ke instans RDS for PostgreSQL Anda](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [Koneksi maksimum MySQL dan MariaDB](#USER_ConnectToInstance.max_connections)
### Menguji koneksi ke instans DB
Anda dapat menguji koneksi ke instans DB menggunakan alat Linux atau Microsoft Windows umum.
Dari terminal Linux atau Unix, Anda dapat menguji koneksi dengan memasukkan hal berikut. Ganti `DB-instance-endpoint` dengan titik akhir dan `port` dengan port instans DB Anda.
```
nc -zv DB-instance-endpoint port
```
Misalnya, hal berikut menunjukkan contoh perintah dan nilai kembali.
```
nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299
Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!
```
Pengguna Windows dapat menggunakan Telnet untuk menguji koneksi ke instans DB. Tindakan Telnet tidak didukung selain untuk menguji koneksi. Jika koneksi berhasil, tindakan tidak akan mengembalikan pesan. Jika koneksi gagal, Anda akan menerima pesan kesalahan seperti berikut.
```
C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819
Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
connection to the host, on port 819: Connect failed
```
Jika tindakan Telnet berhasil, artinya grup keamanan Anda dikonfigurasi dengan benar.
**catatan**
Amazon RDS tidak menerima lalu lintas Internet Control Message Protocol (ICMP), termasuk ping.
### Memecahkan masalah autentikasi koneksi
Dalam beberapa kasus, Anda dapat terhubung ke instans DB tetapi mendapatkan kesalahan autentikasi. Dalam kasus ini, Anda mungkin ingin mengatur ulang kata sandi pengguna utama untuk instans DB. Anda dapat melakukan tindakan ini dengan mengubah instans RDS.
Untuk informasi selengkapnya tentang cara mengubah instans DB, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
## Masalah keamanan Amazon RDS
Untuk menghindari masalah keamanan, jangan pernah menggunakan alamat email pengguna Akun AWS root dan kata sandi Anda untuk akun pengguna. Praktik terbaik adalah menggunakan pengguna root Anda untuk membuat pengguna dan menetapkannya ke akun pengguna DB. Anda juga dapat menggunakan pengguna root Anda untuk membuat akun pengguna lain, jika perlu.
Untuk informasi tentang membuat pengguna, lihat [Membuat pengguna IAM di Akun AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). Untuk informasi tentang membuat pengguna AWS IAM Identity Center, lihat [Mengelola identitas di Pusat Identitas IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html).
### Pesan kesalahan “gagal mengambil atribut akun, fungsi konsol tertentu mungkin terganggu.”
Kesalahan ini dapat muncul karena beberapa alasan. Penyebabnya mungkin karena akun Anda kehilangan izin, atau akun Anda belum disiapkan dengan benar. Untuk akun baru, Anda mungkin belum menunggu akun hingga siap digunakan. Untuk akun lama, Anda mungkin tidak memiliki izin dalam kebijakan akses untuk melakukan tindakan tertentu, seperti membuat instans DB. Untuk memecahkan masalah ini, administrator perlu memberikan peran yang diperlukan ke akun Anda. Untuk informasi selengkapnya, lihat [dokumentasi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
## Memecahkan masalah status jaringan yang tidak kompatibel
Status jaringan yang tidak kompatibel berarti basis datanya mungkin masih dapat diakses di tingkat basis data, tetapi Anda tidak dapat mengubah atau melakukan boot ulang pada basis data tersebut.
### Penyebab
Status jaringan instans DB Anda yang tidak kompatibel dapat disebabkan oleh salah satu tindakan berikut:
+ Mengubah kelas instans DB.
+ Mengubah instans DB untuk menggunakan deployment klaster DB Multi-AZ.
+ Mengganti host karena acara pemeliharaan.
+ Meluncurkan instans DB pengganti.
+ Memulihkan dari pencadangan snapshot.
+ Memulai instans DB yang telah dihentikan.
### Penyelesaian
#### Gunakan start-db-instance perintah
Untuk memperbaiki basis data yang berada dalam status jaringan yang tidak kompatibel, ikuti petunjuk ini:
1. Buka [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)dan pilih **Database** dari panel navigasi.
1. **Pilih instans DB yang berada dalam status jaringan yang tidak kompatibel dan catat pengidentifikasi instans DB, ID VPC, dan IDs subnet dari tab Konektivitas & Keamanan.**
1. Gunakan AWS CLI untuk menjalankan `start-db-instance` perintah. Tentukan nilai `--db-instance-identifier`.
**catatan**
Menjalankan perintah ini ketika basis data Anda dalam mode yang tidak kompatibel dapat menyebabkan beberapa waktu henti.
Perintah `start-db-instance` tidak menyelesaikan masalah ini untuk instans DB RDS for SQL Server.
Status basis data Anda berubah menjadi **Tersedia** jika perintah berhasil dijalankan.
Jika basis data Anda dimulai ulang, instans DB mungkin menjalankan operasi terakhir yang dijalankan pada instans tersebut sebelum dipindahkan ke status jaringan yang tidak kompatibel. Tindakan ini mungkin memindahkan kembali instans ke status jaringan yang tidak kompatibel.
Jika perintah `start-db-instance` tidak berhasil atau instans berpindah kembali ke status jaringan yang tidak kompatibel, buka halaman **Basis Data** di konsol RDS dan pilih basis datanya. Arahkan ke bagian **Log & peristiwa**. Bagian **Peristiwa terbaru** menampilkan langkah-langkah penyelesaian lebih lanjut untuk diikuti. Pesan-pesan tersebut diklasifikasikan sebagai berikut:
+ **PEMERIKSAAN SUMBER DAYA INTERNAL**: Mungkin ada masalah dengan sumber daya internal Anda.
+ **PEMERIKSAAN DNS**: Periksa penyelesaian DNS dan nama host untuk VPC di konsol VPC.
+ **Pemeriksaan ENI**: antarmuka jaringan elastis (ENI) untuk basis data Anda mungkin tidak ada.
+ **PEMERIKSAAN GATEWAY**: Gateway internet untuk basis data Anda yang tersedia untuk umum tidak dilampirkan ke VPC.
+ **PEMERIKSAAN IP**: Tidak ada alamat IP gratis di subnet Anda.
+ **PEMERIKSAAN GRUP KEAMANAN**: Tidak ada grup keamanan yang dikaitkan dengan basis data Anda atau grup keamanan tidak valid.
+ **PEMERIKSAAN SUBNET**: Tidak ada subnet yang valid di grup subnet DB Anda atau ada masalah dengan subnet Anda.
+ **PEMERIKSAAN VPC**: VPC yang dikaitkan dengan basis data Anda tidak valid.
#### Lakukan point-in-time pemulihan
Memiliki cadangan (snapshot atau logis) merupakan praktik terbaik, jika basis data Anda memasuki status jaringan yang tidak kompatibel. Lihat [Pengantar cadangan](USER_WorkingWithAutomatedBackups.md). Jika Anda mengaktifkan cadangan otomatis, maka hentikan sementara penulisan apa pun ke database dan lakukan pemulihan. point-in-time
**catatan**
Setelah suatu instans memasuki status jaringan yang tidak kompatibel, instans DB mungkin tidak dapat diakses untuk melakukan pencadangan logis.
Jika Anda tidak mengaktifkan pencadangan otomatis, buat instans DB baru. Kemudian, migrasikan data menggunakan [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/;Welcome.html), atau dengan menggunakan alat pencadangan dan pemulihan.
Jika ini tidak menyelesaikan masalah, hubungi Dukungan untuk bantuan lebih lanjut.
## Mengatur ulang kata sandi pemilik instans DB
Jika Anda terkunci dari instans DB, Anda dapat masuk sebagai pengguna utama. Kemudian, Anda dapat mengatur ulang kredensial untuk pengguna administratif atau peran lainnya. Jika Anda tidak dapat masuk sebagai pengguna utama, pemilik AWS akun dapat mengatur ulang kata sandi pengguna utama. Untuk detail tentang akun administratif atau peran yang mungkin perlu Anda atur ulang, lihat [Hak akses akun pengguna master](UsingWithRDS.MasterAccounts.md).
Anda dapat mengubah kata sandi instans DB dengan menggunakan konsol Amazon RDS, AWS CLI perintah [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html), atau dengan menggunakan operasi [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. Untuk informasi selengkapnya tentang cara mengubah instans DB, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
## Penghentian atau boot ulang instans DB Amazon RDS
Penghentian instans DB dapat terjadi ketika instans DB di-boot ulang. Penghentian ini juga dapat terjadi saat instans DB diubah menjadi status yang mencegah akses ke instans tersebut, dan saat basis data di-boot ulang. Boot ulang dapat terjadi saat Anda melakukan boot ulang manual pada instans DB Anda. Boot ulang juga dapat terjadi saat Anda mengubah pengaturan instans DB yang memerlukan boot ulang sebelum dapat diberlakukan.
Boot ulang instans DB terjadi saat Anda mengubah pengaturan yang memerlukan boot ulang, atau ketika Anda secara manual menyebabkan boot ulang. Boot ulang dapat segera terjadi jika Anda mengubah pengaturan dan meminta perubahan segera diberlakukan. Atau, boot ulang dapat terjadi selama jendela pemeliharaan instans DB.
Boot ulang instans DB segera terjadi ketika salah satu hal berikut terjadi:
+ Anda mengubah periode retensi pencadangan untuk instans DB dari 0 ke nilai selain nol atau dari nilai selain nol ke 0. Anda mengatur **Terapkan Segera** ke `true`.
+ Anda mengubah kelas instans DB, dan **Terapkan Segera** diatur menjadi `true`.
+ Anda mengubah jenis penyimpanan dari **Magnetis (Standar)** ke **Tujuan Umum (SSD**) atau **IOPS yang Tersedia (SSD)**, atau dari **IOPS yang Tersedia (SSD)** atau **Tujuan Umum (SSD)** ke **Magnetis (Standar)**.
Boot ulang instans DB terjadi selama jendela pemeliharaan saat salah satu dari hal berikut terjadi:
+ Anda mengubah periode retensi pencadangan untuk instans DB dari 0 ke nilai selain nol atau dari nilai selain nol ke 0, dan **Terapkan Segera** diatur ke `false`.
+ Anda mengubah kelas instans DB, dan **Terapkan Segera** diatur menjadi `false`.
Ketika Anda mengubah parameter statis dalam grup parameter DB, perubahan tersebut tidak diberlakukan hingga instans DB yang dikaitkan dengan grup parameter di-boot ulang. Perubahan ini memerlukan boot ulang manual. Instans DB tidak di-boot ulang secara otomatis selama jendela pemeliharaan.
Untuk melihat tabel yang menunjukkan tindakan instans DB dan dampak dari pengaturan nilai **Terapkan Segera**, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
## Perubahan parameter DB Amazon RDS tidak diberlakukan
Dalam beberapa kasus, Anda mungkin mengubah parameter dalam grup parameter DB, tetapi tidak melihat perubahan akan diberlakukan. Jika demikian, Anda mungkin perlu melakukan boot ulang instans DB yang dikaitkan dengan grup parameter DB. Saat Anda mengubah parameter dinamis, perubahan akan langsung diberlakukan. Ketika Anda mengubah parameter statis, perubahan tersebut tidak diberlakukan hingga Anda melakukan boot ulang instans DB yang dikaitkan dengan grup parameter.
Anda dapat melakukan boot ulang pada instans DB menggunakan konsol RDS. Atau, Anda dapat secara eksplisit memanggil operasi API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html). Anda dapat mem-boot ulang tanpa failover jika instans DB ada dalam deployment Multi-AZ. Persyaratan untuk melakukan boot ulang pada instans DB terkait setelah perubahan parameter statis membantu memitigasi risiko kesalahan konfigurasi parameter yang memengaruhi panggilan API. Contohnya adalah memanggil `ModifyDBInstance` untuk mengubah kelas instans DB. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md).
## Instans DB Amazon RDS kehabisan ruang penyimpanan
Jika instans DB Anda kehabisan ruang penyimpanan, instans tersebut mungkin tidak lagi tersedia. Kami sangat menyarankan agar Anda terus memantau `FreeStorageSpace` metrik yang diterbitkan CloudWatch untuk memastikan bahwa instans DB Anda memiliki ruang penyimpanan gratis yang cukup.
Jika instans basis data Anda kehabisan ruang penyimpanan, statusnya berubah menjadi `storage-full`. Sebagai contoh, panggilan ke operasi API `DescribeDBInstances` untuk instans DB yang telah menghabiskan output penyimpanannya berikut.
```
aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa
storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306
us-east-1b 3
SECGROUP default active
PARAMGRP default.mysql8.0 in-sync
```
Untuk memulihkan dari skenario ini, tambahkan lebih banyak ruang penyimpanan ke instans Anda menggunakan operasi `ModifyDBInstance` API atau AWS CLI perintah berikut.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--allocated-storage 60 \
--apply-immediately
```
Untuk Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--allocated-storage 60 ^
--apply-immediately
```
```
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa
storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306
us-east-1b 3 60
SECGROUP default active
PARAMGRP default.mysql8.0 in-sync
```
Kini, saat Anda menggambarkan instans DB, Anda melihat bahwa instans DB Anda memiliki status `modifying`, yang menunjukkan bahwa penyimpanan sedang diskalakan.
```
1. aws rds describe-db-instances --db-instance-identifier mydbinstance
```
```
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa
modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com
3306 us-east-1b 3 60
SECGROUP default active
PARAMGRP default.mysql8.0 in-sync
```
Setelah penskalaan penyimpanan selesai, status instans DB Anda berubah menjadi `available`.
```
aws rds describe-db-instances --db-instance-identifier mydbinstance
```
```
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa
available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306
us-east-1b 3
SECGROUP default active
PARAMGRP default.mysql8.0 in-sync
```
Anda dapat menerima notifikasi ketika ruang penyimpanan Anda habis menggunakan operasi `DescribeEvents`. Misalnya, dalam skenario ini, jika Anda membuat panggilan `DescribeEvents` setelah operasi ini, Anda akan melihat output berikut.
```
aws rds describe-events --source-type db-instance --source-identifier mydbinstance
```
```
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance
2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance
2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage
```
## Instans DB Amazon RDS tidak cukup tersedia
Kesalahan `InsufficientDBInstanceCapacity` dapat muncul saat Anda mencoba membuat, memulai, atau mengubah instans DB. Kesalahan ini juga dapat muncul saat Anda mencoba memulihkan instans DB dari snapshot DB. Saat kesalahan ini muncul, satu penyebab umumnya adalah kelas instans DB tertentu tidak tersedia di Zona Ketersediaan yang diminta. Anda dapat mencoba salah satu hal berikut untuk memecahkan masalahnya:
+ Coba kembali permintaan dengan kelas instans DB yang berbeda.
+ Coba kembali permintaan dengan Zona Ketersediaan yang berbeda.
+ Coba kembali permintaan tanpa menentukan Zona Ketersediaan eksplisit.
Untuk informasi tentang pemecahan masalah kapasitas instans untuk Amazon EC2, lihat [Kapasitas instans tidak mencukupi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#troubleshooting-launch-capacity) di *Panduan Pengguna Amazon EC2*.
Untuk informasi tentang cara mengubah instans DB, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
## Masalah memori yang dapat dikosongkan di Amazon RDS
*Memori yang dikosongkan* adalah total Random Access Memory (RAM) pada instans DB yang dapat dibuat tersedia untuk mesin basis data. Ini adalah jumlah dari memori sistem operasi (OS) yang kosong serta memori cache halaman dan buffer yang tersedia. Mesin basis data menggunakan sebagian besar memori pada host, tetapi proses OS juga menggunakan sebagian RAM. Memori yang saat ini dialokasikan ke mesin basis data atau digunakan oleh proses OS tidak termasuk dalam memori yang dapat dikosongkan. Ketika mesin basis data kehabisan memori, instans DB dapat menggunakan ruang sementara yang biasanya digunakan untuk buffering dan caching. Seperti disebutkan sebelumnya, ruang sementara ini termasuk dalam memori yang dapat dikosongkan.
Anda menggunakan `FreeableMemory` metrik di Amazon CloudWatch untuk memantau memori yang dapat dibebaskan. Untuk informasi selengkapnya, lihat [Alat pemantauan untuk Amazon RDS ](MonitoringOverview.md).
Jika instans DB Anda secara konsisten kehabisan memori yang dapat dikosongkan atau menggunakan ruang swap, pertimbangkan untuk meningkatkan ke kelas instans DB yang lebih besar. Untuk informasi selengkapnya, lihat [ DB](Concepts.DBInstanceClass.md).
Anda juga dapat mengubah pengaturan memori. Misalnya, pada RDS for MySQL, Anda dapat menyesuaikan ukuran parameter `innodb_buffer_pool_size`. Parameter ini diatur secara default ke 75 persen memori fisik. Untuk tips pemecahan masalah MySQL lainnya, lihat [Bagaimana cara memecahkan masalah memori yang dapat dikosongkan rendah di basis data Amazon RDS for MySQL?](https://aws.amazon.com/premiumsupport/knowledge-center/low-freeable-memory-rds-mysql-mariadb/)
## Masalah MySQL dan MariaDB
Anda dapat mendiagnosis dan memperbaiki masalah dengan instans DB MySQL dan MariaDB.
**Topics**
+ [Koneksi maksimum MySQL dan MariaDB](#USER_ConnectToInstance.max_connections)
+ [Mendiagnosis dan menyelesaikan status parameter yang tidak kompatibel untuk batas memori](#CHAP_Troubleshooting.incompatible-parameters-memory)
+ [Mendiagnosis dan mengatasi jeda di antara replika baca](#CHAP_Troubleshooting.MySQL.ReplicaLag)
+ [Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB](#CHAP_Troubleshooting.MySQL.RR)
+ [Membuat pemicu dengan log biner aktif memerlukan hak istimewa SUPER](#CHAP_Troubleshooting.MySQL.CreatingTriggers)
+ [Mendiagnosis dan menyelesaikan kegagalan pemulihan point-in-time](#CHAP_Troubleshooting.MySQL.PITR)
+ [Kesalahan replikasi terhenti](#CHAP_Troubleshooting.MySQL.ReplicationStopped)
+ [Pembuatan replika baca gagal atau replikasi rusak dengan kesalahan fatal 1236](#CHAP_Troubleshooting.MySQL.ReadReplicas)
+ [Replikasi replika baca gagal menginisialisasi struktur metadata](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata)
### Koneksi maksimum MySQL dan MariaDB
Jumlah koneksi maksimum yang diperbolehkan untuk instans DB RDS for MySQL atau RDS for MariaDB didasarkan pada jumlah memori yang tersedia untuk kelas instans DB. Kelas instans DB dengan memori lebih besar akan menghasilkan tersedianya koneksi yang lebih besar. Untuk informasi selengkapnya tentang kelas instans DB, lihat [ DB](Concepts.DBInstanceClass.md).
Batas koneksi untuk instans DB diatur secara default ke kelas instans maksimum DB. Anda dapat membatasi jumlah koneksi bersamaan dengan nilai berapa pun hingga jumlah maksimum koneksi yang diperbolehkan. Gunakan parameter `max_connections` dalam grup parameter untuk instans DB. Untuk informasi lebih lanjut, lihat [Jumlah maksimum koneksi basis data](CHAP_Limits.md#RDS_Limits.MaxConnections) dan [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda dapat mengambil jumlah maksimum koneksi yang diperbolehkan untuk instans DB MySQL atau MariaDB dengan menjalankan kueri berikut.
```
SELECT @@max_connections;
```
Anda dapat mengambil jumlah maksimum koneksi yang aktif untuk instans DB MySQL atau MariaDB dengan menjalankan kueri berikut.
```
SHOW STATUS WHERE `variable_name` = 'Threads_connected';
```
### Mendiagnosis dan menyelesaikan status parameter yang tidak kompatibel untuk batas memori
Instans DB MariaDB atau MySQL dapat ditempatkan dalam status **incompatible-parameters** untuk suatu batas memori saat kondisi berikut terpenuhi:
+ Instans DB dimulai ulang setidaknya tiga kali dalam satu jam atau setidaknya lima kali dalam satu hari jika status instans DB **Tersedia**.
+ Upaya untuk memulai ulang instans DB gagal karena tindakan pemeliharaan atau proses pemantauan tidak dapat memulai ulang instans DB.
+ Penggunaan memori potensial instans DB melebihi 1,2 kali memori yang dialokasikan ke kelas instans DB.
Ketika instans DB dimulai ulang untuk ketiga kalinya dalam satu jam atau untuk kali kelima dalam satu hari, instans tersebut melakukan pemeriksaan penggunaan memori. Pemeriksaan ini membuat perhitungan penggunaan memori potensial instans DB. Nilai yang ditunjukkan oleh perhitungan tersebut adalah jumlah dari nilai berikut:
+ **Nilai 1** – Jumlah parameter berikut:
+ `innodb_additional_mem_pool_size`
+ `innodb_buffer_pool_size`
Anda dapat memodifikasi nilai untuk`innodb_buffer_pool_size`. Namun, nilainya tidak akan selalu cocok dengan apa yang Anda masukkan. Ketidakcocokan ini terjadi karena beberapa alasan. Pertama, jika instance DB adalah instance micro DB, maka kita mengganti nilai default dan mengaturnya ke 256 MB. Untuk informasi selengkapnya, lihat [Mengesampingkan innodb\$1buffer\$1pool\$1size](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size).
Kedua, kami memastikan bahwa 500 MB memori dicadangkan pada instans DB untuk manajer host, mesin, sistem operasi, dan kernel.
Terakhir, kami mengoptimalkan `innodb_buffer_pool_size` dengan membaginya menjadi beberapa unit. Manajer tuan rumah membulatkan ke kelipatan terdekat dari unit-unit tersebut. Satuan dihitung dengan mengalikan `innodb_buffer_pool_chunk_size` dengan. `innodb_buffer_pool_instances` Untuk informasi selengkapnya, lihat [Mengonfigurasi Ukuran Kolam Buffer InnoDB dalam dokumentasi MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-resize.html).
Default untuk `innodb_buffer_pool_instances` adalah 8, kecuali `innodb_buffer_pool_size` kurang dari 1 GB. Jika `innodb_buffer_pool_size` kurang dari 1 GB, maka default untuk `innodb_buffer_pool_instances` adalah 1. `innodb_buffer_pool_chunk_size`Defaultnya adalah 128 MB.
+ `innodb_log_buffer_size`
+ `key_buffer_size`
+ `query_cache_size` (Hanya MySQL versi 5.7)
+ `tmp_table_size`
+ **Nilai 2** – Parameter `max_connections` dikalikan dengan jumlah parameter berikut:
+ `binlog_cache_size`
+ `join_buffer_size`
+ `read_buffer_size`
+ `read_rnd_buffer_size`
+ `sort_buffer_size`
+ `thread_stack`
+ **Nilai 3** – Jika parameter `performance_schema` diaktifkan, kalikan parameter `max_connections` dengan `429498`.
Jika parameter `performance_schema` dinonaktifkan, nilai ini adalah nol.
Jadi, nilai yang ditunjukkan oleh perhitungan adalah sebagai berikut:
`Value 1 + Value 2 + Value 3`
Ketika nilai ini melebihi 1,2 kali memori yang dialokasikan ke kelas instans DB yang digunakan oleh instans DB, instans DB ditempatkan dalam status **incompatible-parameters**. Untuk informasi tentang memori yang dialokasikan ke kelas instans DB, lihat [Spesifikasi perangkat keras untuk kelas instans DB ](Concepts.DBInstanceClass.Summary.md).
Penghitungan tersebut mengalikan nilai parameter `max_connections` dengan jumlah beberapa parameter. Jika parameter `max_connections` diatur ke nilai yang besar, parameter ini dapat menyebabkan pemeriksaan menunjukkan nilai yang sangat tinggi untuk penggunaan memori potensial dari instans DB. Dalam kasus ini, pertimbangkan untuk menurunkan nilai parameter `max_connections`.
Untuk mengatasi masalah, selesaikan langkah-langkah berikut:
1. Sesuaikan parameter memori dalam grup parameter DB yang dikaitkan dengan instans DB. Lakukan sedemikian rupa sehingga penggunaan memori potensial lebih rendah dari 1,2 kali memori yang dialokasikan ke kelas instans DB.
Untuk informasi tentang mengatur parameter, lihat [](USER_WorkingWithParamGroups.Modifying.md).
1. Mulai ulang instans DB.
Untuk informasi tentang mengatur parameter, lihat [Memulai instans Amazon RDS DB yang sebelumnya dihentikan](USER_StartInstance.md).
### Mendiagnosis dan mengatasi jeda di antara replika baca
Setelah Anda membuat replika baca MySQL atau MariaDB dan replikanya tersedia, Amazon RDS pertama-tama mereplikasi perubahan yang dibuat ke instans DB sumber sejak operasi replika baca dimulai. Selama fase ini, waktu jeda replikasi untuk replika baca lebih besar dari 0. Anda dapat memantau jeda waktu ini di Amazon CloudWatch dengan melihat `ReplicaLag`metrik Amazon RDS.
Metrik `ReplicaLag` melaporkan nilai kolom `Seconds_Behind_Master` dari perintah `SHOW REPLICA STATUS` MariaDB atau MySQL. Untuk informasi selengkapnya, lihat [SHOW REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) di dokumentasi MySQL.
Saat metrik `ReplicaLag` mencapai 0, replika telah menyamai instans DB sumber. Jika metrik `ReplicaLag` menunjukkan -1, replikasi mungkin tidak aktif. Untuk memecahkan masalah kesalahan replikasi, lihat [Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB](#CHAP_Troubleshooting.MySQL.RR). Nilai `ReplicaLag` sebesar -1 juga dapat berarti bahwa nilai `Seconds_Behind_Master` tidak dapat ditentukan atau `NULL`.
**catatan**
Versi sebelumnya dari MariaDB menggunakan `SHOW SLAVE STATUS`, bukan `SHOW REPLICA STATUS`. Jika Anda menggunakan versi MariaDB yang lebih rendah dari 10.5, maka gunakan. `SHOW SLAVE STATUS`
Metrik `ReplicaLag` menunjukkan -1 saat penghentian jaringan atau saat patch diterapkan selama jendela pemeliharaan. Dalam kasus ini, tunggu konektivitas jaringan hingga dipulihkan atau tunggu jendela pemeliharaan berakhir sebelum Anda memeriksa metrik `ReplicaLag` lagi.
Teknologi replikasi baca MySQL dan MariaDB bersifat asinkron. Oleh karena itu, Anda dapat sesekali mengharapkan peningkatan bagi metrik `BinLogDiskUsage` pada instans DB sumber dan bagi metrik `ReplicaLag` pada replika baca. Misalnya, pertimbangkan situasi saat volume operasi tulis tinggi ke instans DB sumber terjadi secara paralel. Pada saat yang sama, operasi penulisan ke replika baca diserialisasikan menggunakan satu I/O utas. Situasi tersebut dapat menyebabkan jeda antara instans sumber dan replika baca.
Untuk informasi selengkapnya tentang replika baca dan MySQL, lihat [Replication implementation details](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html) dalam dokumentasi MySQL. Untuk informasi selengkapnya tentang replika baca dan MariaDB, lihat [Replication overview](http://mariadb.com/kb/en/mariadb/replication-overview/) di dokumentasi MariaDB.
Anda dapat mengurangi lag antara pembaruan ke instans DB sumber dan pembaruan berikutnya ke replika baca dengan melakukan hal berikut:
+ Atur kelas instans DB dari replika baca agar memiliki ukuran penyimpanan yang sebanding dengan ukuran dari instans DB sumber.
+ Pastikan kompatibilitas pengaturan parameter di grup parameter DB yang digunakan oleh instans DB sumber dan replika baca. Untuk informasi selengkapnya dan contoh, lihat diskusi tentang parameter `max_allowed_packet` di bagian berikutnya.
+ Nonaktifkan cache kueri. Untuk tabel yang sering diubah, menggunakan cache kueri dapat meningkatkan lag replika karena cache terkunci dan sering disegarkan. Dalam kasus ini, Anda mungkin akan melihat lebih sedikit lag replika jika menonaktifkan cache kueri. Anda dapat menonaktifkan cache kueri dengan mengatur `query_cache_type parameter` ke 0 dalam grup parameter DB untuk instans DB. Untuk informasi selengkapnya tentang cache kueri, lihat [Konfigurasi cache kueri](https://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html).
+ Hangatkan kumpulan buffer pada replika baca untuk InnoDB for MySQL atau MariaDB. Misalnya, anggaplah Anda memiliki sejumlah kecil tabel yang sering diperbarui dan Anda menggunakan skema tabel InnoDB atau XtraDB. Dalam kasus ini, dump tabel tersebut pada replika baca. Dengan melakukan hal ini, Anda akan menyebabkan mesin basis data memindai barisan tabel tersebut dari disk, lalu menyimpannya di dalam kumpulan buffer. Pendekatan ini dapat mengurangi jeda replika. Bagian berikut menunjukkan satu contoh.
Untuk Linux, macOS, atau Unix:
```
PROMPT> mysqldump \
-h \
--port= \
-u= \
-p \
database_name table1 table2 > /dev/null
```
Untuk Windows:
```
PROMPT> mysqldump ^
-h ^
--port= ^
-u= ^
-p ^
database_name table1 table2 > /dev/null
```
### Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB
Amazon RDS memantau status replikasi replika baca Anda. RDS memperbarui bidang **Status Replikasi** instans replika baca menjadi `Error` jika replikasi berhenti karena alasan apa pun. Anda dapat meninjau detail kesalahan terkait yang dilontarkan oleh mesin MySQL atau MariaDB dengan melihat kolom **Kesalahan Replikasi**. Peristiwa yang menunjukkan status replika baca juga dihasilkan, termasuk [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046), dan [RDS-EVENT-0057](USER_Events.Messages.md#RDS-EVENT-0057). Untuk informasi selengkapnya tentang peristiwa dan berlangganan peristiwa, lihat [Bekerja dengan pemberitahuan RDS acara Amazon](USER_Events.md). Jika pesan kesalahan MySQL muncul, periksa kesalahannya di [MySQL error message documentation](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). Jika pesan kesalahan MariaDB muncul, periksa kesalahannya di [MySQL error message documentation](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/).
Situasi umum yang dapat menyebabkan kesalahan replikasi mencakup hal-hal berikut:
+ Nilai parameter `max_allowed_packet` untuk replika baca lebih kecil dari parameter `max_allowed_packet` untuk instans DB sumber.
Parameter `max_allowed_packet` adalah parameter kustom yang dapat Anda atur di grup parameter DB. Parameter `max_allowed_packet` digunakan untuk menentukan ukuran maksimum bahasa manipulasi data (DML) yang dapat dijalankan di basis data. Dalam beberapa kasus, nilai `max_allowed_packet` untuk instans DB sumber mungkin lebih besar dari nilai `max_allowed_packet` untuk replika baca. Jika demikian, proses replikasi dapat menimbulkan kesalahan dan menghentikan replikasi. Kesalahan yang paling umum adalah `packet bigger than 'max_allowed_packet' bytes`. Anda dapat memperbaiki kesalahan ini dengan mengatur agar replika sumber dan baca menggunakan grup parameter DB yang sama dengan nilai parameter `max_allowed_packet`.
+ Menulis ke tabel di replika baca. Jika Anda membuat indeks pada replika baca, parameter `read_only` harus diatur ke *0* untuk membuat indeks. Jika Anda menulis ke tabel di replika baca, tindakan ini dapat memecah replikasi.
+ Gunakan mesin penyimpanan nontransaksional seperti MyISAM. Replika baca membutuhkan mesin penyimpanan transaksional. Replikasi hanya didukung untuk mesin penyimpanan berikut: InnoDB for MySQL atau MariaDB.
Anda dapat mengonversi tabel MyISAM ke InnoDB dengan perintah berikut:
`alter table . engine=innodb;`
+ Gunakan kueri nondeterministik yang tidak aman seperti `SYSDATE()`. Untuk informasi selengkapnya, lihat [Determination of safe and unsafe statements in binary logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) di dokumentasi MySQL.
Langkah-langkah berikut dapat membantu mengatasi kesalahan replikasi Anda:
+ Jika Anda mengalami kesalahan logis dan dapat melewatkan kesalahan tersebut dengan aman, ikuti langkah-langkah yang dijelaskan dalam [Melewatkan kesalahan replikasi saat ini untuk RDS untuk MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Instans DB MySQL atau MariaDB Anda harus menjalankan versi yang mencakup prosedur `mysql_rds_skip_repl_error`. Untuk informasi selengkapnya, lihat [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error).
+ Jika Anda mengalami masalah posisi log biner (binlog), Anda dapat mengubah posisi replay replika dengan perintah or. [](mysql-stored-proc-replicating.md#mysql_rds_next_source_log) [](mysql-stored-proc-replicating.md#mysql_rds_next_master_log)
+ Anda mungkin mengalami masalah kinerja sementara karena beban DMLnya tinggi. Jika demikian, Anda dapat mengatur parameter `innodb_flush_log_at_trx_commit` ke 2 di grup parameter DB pada replika baca. Dengan melakukan hal ini, Anda dapat membantu replika baca mengejar, meskipun tindakan ini akan mengurangi atomisitas, konsistensi, isolasi, dan daya tahan (ACID) untuk sementara.
+ Anda dapat menghapus replika baca dan membuat instans menggunakan pengidentifikasi instans DB yang sama. Jika Anda melakukannya, titik akhir tetap sama dengan replika baca lama Anda.
Jika kesalahan replikasi diperbaiki, **Status Replikasi** berubah menjadi **mereplikasi**. Untuk informasi selengkapnya, lihat [Memecahkan masalah replika SQL baca saya](USER_ReadRepl.Troubleshooting.md).
### Membuat pemicu dengan log biner aktif memerlukan hak istimewa SUPER
Saat mencoba membuat pemicu di instans DB RDS for MySQL atau RDS for MariaDB, Anda mungkin menerima kesalahan berikut.
```
"You do not have the SUPER privilege and binary logging is enabled"
```
Untuk menggunakan pemicu saat pencatatan log biner diaktifkan memerlukan hak istimewa SUPER, yang dibatasi untuk instans DB RDS for MySQL dan RDS for MariaDB. Anda dapat membuat pemicu saat log biner diaktifkan tanpa hak istimewa SUPER dengan mengatur parameter `log_bin_trust_function_creators` ke true. Untuk mengatur `log_bin_trust_function_creators` menjadi true, buat grup parameter DB baru atau ubah grup parameter DB yang sudah ada.
Anda dapat membuat grup parameter DB baru sehingga Anda dapat membuat pemicu di instans DB RDS for MySQL atau RDS for MariaDB dengan log biner yang aktif. Untuk melakukannya, gunakan perintah CLI berikut. Untuk mengubah grup parameter yang ada, mulailah dengan langkah 2.
**Membuat grup parameter baru untuk mengizinkan pemicu dengan log biner yang aktif menggunakan CLI**
1. Buat grup parameter baru.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-parameter-group \
--db-parameter-group-name allow-triggers \
--db-parameter-group-family mysql8.0 \
--description "parameter group allowing triggers"
```
Untuk Windows:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name allow-triggers ^
--db-parameter-group-family mysql8.0 ^
--description "parameter group allowing triggers"
```
1. Ubah grup parameter DB untuk mengizinkan pemicu.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name allow-triggers \
--parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
```
Untuk Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name allow-triggers ^
--parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
```
1. Ubah instans DB Anda untuk menggunakan grup parameter DB yang baru.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-parameter-group-name allow-triggers \
--apply-immediately
```
Untuk Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--db-parameter-group-name allow-triggers ^
--apply-immediately
```
1. Agar perubahan diberlakukan, lakukan boot ulang pada instans DB secara manual.
```
aws rds reboot-db-instance --db-instance-identifier mydbinstance
```
### Mendiagnosis dan menyelesaikan kegagalan pemulihan point-in-time
**Memulihkan instans DB yang mencakup tabel sementara**
Saat mencoba point-in-time memulihkan (PITR) instance MySQL atau MariaDB DB Anda, Anda mungkin mengalami kesalahan berikut.
```
Database instance could not be restored because there has been incompatible database activity for restore
functionality. Common examples of incompatible activity include using temporary tables, in-memory tables,
or using MyISAM tables. In this case, use of Temporary table was detected.
```
PITR mengandalkan snapshot cadangan dan log biner (binlog) dari MySQL atau MariaDB untuk memulihkan instans DB Anda ke waktu tertentu. Informasi tabel sementara mungkin tidak dapat diandalkan di binlog dan dapat menyebabkan kegagalan PITR. Jika Anda menggunakan tabel sementara di instance MySQL atau MariaDB DB Anda, Anda dapat mengurangi kemungkinan kegagalan PITR dengan melakukan pencadangan yang lebih sering. Kegagalan PITR paling mungkin terjadi dalam waktu antara pembuatan tabel sementara dan snapshot cadangan berikutnya.
**Memulihkan instans DB yang menyertakan tabel dalam memori**
Anda mungkin mengalami masalah saat memulihkan basis data yang memiliki tabel dalam memori. Tabel dalam-memori dibersihkan selama proses mulai ulang. Sebagai hasilnya, tabel dalam memori Anda mungkin kosong setelah boot ulang. Kami merekomendasikan agar Anda merancang solusi untuk menangani tabel kosong jika proses mulai ulang terjadi saat menggunakan tabel dalam memori. Jika Anda menggunakan tabel dalam memori dengan instans DB yang direplikasi, Anda mungkin perlu membuat replika baca setelah memulai ulang. Hal ini mungkin diperlukan jika replika baca melakukan boot ulang dan tidak dapat memulihkan data dari tabel dalam memori yang kosong.
Untuk informasi selengkapnya tentang pencadangan dan PITR, lihat [Pengantar cadangan](USER_WorkingWithAutomatedBackups.md) dan [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md).
### Kesalahan replikasi terhenti
Ketika memanggil perintah `mysql.rds_skip_repl_error`, Anda mungkin menerima pesan kesalahan yang menyatakan bahwa replikasi mati atau dinonaktifkan.
Pesan kesalahan ini muncul karena replikasi dihentikan dan tidak dapat dimulai ulang.
Jika Anda perlu melewati sejumlah besar kesalahan, lag replikasi dapat meningkat hingga melampaui periode retensi default untuk file log biner. Dalam hal ini, Anda mungkin mengalami kesalahan fatal karena file log biner dibersihkan sebelum diputar ulang pada replika. 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 penyimpanan file log biner pada sumber replikasi 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). Tentukan parameter konfigurasi 'jam retensi binlog' sekaligus jumlah jam untuk menyimpan file binlog di klaster DB, hingga 720 (30 hari). Contoh berikut menetapkan periode penyimpanan file binlog menjadi 48 jam.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
### Pembuatan replika baca gagal atau replikasi rusak dengan kesalahan fatal 1236
Setelah mengubah nilai parameter default untuk instans DB MySQL atau MariaDB, Anda mungkin mengalami salah satu masalah berikut:
+ Anda tidak dapat membuat replika baca untuk instans DB.
+ Replikasi gagal dengan `fatal error 1236`.
Beberapa nilai parameter default untuk instans DB MySQL dan MariaDB membantu memastikan bahwa basis data tersebut sesuai dengan ACID dan replika baca aman dari crash. Hal ini dilakukan dengan memastikan setiap commit disinkronkan sepenuhnya dengan menulis transaksi ke log biner sebelum di-commit. Mengubah parameter ini dari nilai default untuk meningkatkan performa dapat menyebabkan replikasi gagal ketika transaksi belum ditulis ke log biner.
Untuk mengatasi masalah ini, atur nilai parameter berikut:
+ `sync_binlog = 1`
+ `innodb_support_xa = 1`
+ `innodb_flush_log_at_trx_commit = 1`
### Replikasi replika baca gagal menginisialisasi struktur metadata
Ketika Anda mencoba untuk memulai replikasi, Anda menerima pesan galat berikut:
```
Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository
```
Kesalahan ini terjadi ketika ada masalah dengan struktur metadata replika. Untuk memperbaiki struktur metadata, Anda harus membuat replika baru.
Untuk mencegah hal ini terjadi di masa depan, lakukan salah satu tindakan berikut:
+ Jika memungkinkan, nonaktifkan multi-threading pada replika Anda. Dimulai dengan MySQL 8.0.27, multi-threading diaktifkan secara default.
+ Jika Anda perlu menggunakan multi-threading pada replika Anda, maka kami sarankan Anda menggunakan replikasi berbasis GTID. Untuk informasi selengkapnya, lihat [Menggunakan replikasi GTID berbasis](mysql-replication-gtid.md).
## Tidak dapat mengatur periode retensi cadangan menjadi 0
Ada beberapa alasan mengapa Anda mungkin perlu mengatur periode retensi cadangan menjadi 0. Misalnya, Anda dapat langsung menonaktifkan pencadangan otomatis dengan mengatur periode retensi menjadi 0.
Dalam beberapa kasus, Anda mungkin menetapkan nilai ke 0 dan menerima pesan yang mengatakan bahwa jangka waktu penyimpanan harus antara 1 dan 35. Dalam kasus ini, periksa untuk memastikan bahwa Anda belum menyiapkan replika baca untuk instans. Replika baca memerlukan cadangan untuk mengelola log replika baca sehingga Anda tidak dapat mengatur periode penyimpanan sebesar 0.