Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Pemecahan Masalah untuk Amazon Aurora 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) + [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) + [Masalah memori yang dapat dikosongkan di Amazon Aurora](#Troubleshooting.FreeableMemory) + [Beberapa masalah replikasi Amazon Aurora MySQL](#CHAP_Troubleshooting.MySQL) Untuk informasi tentang masalah debug menggunakan API Amazon RDS, lihat [Pemecahan masalah aplikasi di Aurora](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 [Berikan akses ke klaster DB dalam VPC dengan membuat grup keamanan](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup). **catatan** Koneksi klien dari alamat IP dalam kisaran 169.254.0. 0/16tidak 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 klaster 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 Anda menggunakan alamat IPv6, pastikan ada rute untuk semua lalu lintas IPv6 (`::/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**. Selain itu, jika Anda mencoba untuk terhubung ke titik akhir IPv6, pastikan rentang alamat IPv6 klien diizinkan untuk terhubung ke instans DB. Untuk informasi selengkapnya, lihat [Menggunakan klaster DB di VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). ### 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. ## 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/). ## Mengatur ulang kata sandi pemilik instans DB Jika Anda terkunci dari klaster 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, atau dengan menggunakan operasi ModifydBInstance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) API.](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) Untuk informasi selengkapnya tentang cara mengubah instans DB dalam klaster DB, lihat [Memodifikasi instans DB dalam klaster DB](Aurora.Modifying.md#Aurora.Modifying.Instance). ## 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`. 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. ## 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 reboot tanpa failover jika instans DB dalam Multi-AZ penerapan. 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 [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md). ## Masalah memori yang dapat dikosongkan di Amazon Aurora *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 ](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 [Amazon Aurora:Kelas instans DB](Concepts.DBInstanceClass.md). Anda juga dapat mengubah pengaturan memori. Misalnya, pada Aurora 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/) Untuk Aurora serverless, `FreeableMemory` mewakili jumlah memori yang tidak terpakai yang tersedia ketika instans DB Aurora serverless diskalakan ke kapasitas maksimumnya. Anda mungkin memiliki instans yang diturunkan skalanya ke kapasitas yang relatif rendah, tetapi masih melaporkan nilai tinggi untuk `FreeableMemory`, karena instans dapat dinaikkan skalanya. Memori tersebut tidak tersedia saat ini, tetapi Anda bisa mendapatkannya jika Anda membutuhkannya. Untuk setiap unit kapasitas Aurora (ACU) yang kapasitasnya saat ini di bawah kapasitas maksimum, `FreeableMemory` meningkat sekitar 2 GiB. Dengan demikian, metrik ini tidak mendekati nol sampai instans DB dinaikkan skalanya setinggi mungkin. Jika metrik ini mendekati nilai `0`, instans DB telah dinaikkan skalanya setinggi mungkin. Skala ini mendekati batas memori yang tersedia. Pertimbangkan untuk meningkatkan pengaturan ACU maksimum untuk klaster. Jika metrik ini mendekati nilai `0` pada instans DB pembaca, pertimbangkan untuk menambahkan instans DB pembaca lain ke klaster. Dengan begitu, bagian hanya baca dari beban kerja dapat tersebar di lebih banyak instans DB, sehingga mengurangi penggunaan memori pada setiap instans DB pembaca. Untuk informasi selengkapnya, lihat [CloudWatch Metrik Amazon penting untuk Aurora serverless](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring). ## Beberapa masalah replikasi Amazon Aurora MySQL Beberapa masalah replikasi MySQL juga berlaku untuk Aurora MySQL. Anda dapat mendiagnosis dan memperbaiki masalah tersebut. **Topics** + [Mendiagnosis dan mengatasi jeda di antara replika baca](#CHAP_Troubleshooting.MySQL.ReplicaLag) + [](#CHAP_Troubleshooting.MySQL.RR) + [Kesalahan replikasi terhenti](#CHAP_Troubleshooting.MySQL.ReplicationStopped) + [Replikasi replika baca gagal menginisialisasi struktur metadata](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata) ### Mendiagnosis dan mengatasi jeda di antara replika baca Setelah Anda membuat replika baca MySQL 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 metrik Amazon RDS. Metrik `AuroraBinlogReplicaLag` melaporkan nilai kolom `Seconds_Behind_Master` dari perintah `SHOW REPLICA STATUS` 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 `AuroraBinlogReplicaLag` mencapai 0, replika telah menyamai instans DB sumber. Jika metrik `AuroraBinlogReplicaLag` menunjukkan -1, replikasi mungkin tidak aktif. Untuk memecahkan masalah kesalahan replikasi, lihat [](#CHAP_Troubleshooting.MySQL.RR). Nilai `AuroraBinlogReplicaLag` sebesar -1 juga dapat berarti bahwa nilai `Seconds_Behind_Master` tidak dapat ditentukan atau `NULL`. **catatan** Versi sebelumnya dari Aurora MySQL menggunakan `SHOW SLAVE STATUS`, bukan `SHOW REPLICA STATUS`. Jika Anda menggunakan Aurora MySQL versi 1 atau 2, gunakan `SHOW SLAVE STATUS`. Gunakan `SHOW REPLICA STATUS` untuk Aurora MySQL versi 3 dan yang lebih tinggi. Metrik `AuroraBinlogReplicaLag` 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 `AuroraBinlogReplicaLag` lagi. Teknologi replikasi baca MySQL bersifat asinkron. Oleh karena itu, Anda dapat sesekali mengharapkan peningkatan bagi metrik `BinLogDiskUsage` pada instans DB sumber dan bagi metrik `AuroraBinlogReplicaLag` 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. 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. 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 ``` ### 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 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 [Menggunakan pemberitahuan peristiwa Amazon RDS](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). 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 [Melewati kesalahan replika saat ini](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.SkipError.html). Instans DB Aurora MySQL Anda harus menjalankan versi yang mencakup prosedur `mysql_rds_skip_repl_error`. Untuk informasi selengkapnya, lihat [mysql\_rds\_skip\_repl\_error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_skip_repl_error.html). + Jika Anda mengalami masalah posisi log biner (binlog), Anda dapat mengubah posisi tayangan ulang replika. Anda melakukannya dengan perintah `mysql.rds_next_master_log` untuk Aurora MySQL versi 1 dan 2. Anda melakukannya dengan perintah `mysql.rds_next_source_log` untuk Aurora MySQL versi 3 dan yang lebih tinggi. Instans DB Aurora MySQL Anda harus menjalankan versi yang mendukung perintah ini untuk mengubah posisi tayangan putar ulang replika. Untuk informasi versi, lihat [mysql\_rds\_next\_master\_log](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_next_master_log.html). + Jika Anda mengalami masalah kinerja sementara karena beban DHTML yang tinggi, Anda dapat mengatur `innodb_flush_log_at_trx_commit` parameter 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. Dengan cara ini, 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 baca MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html). ### 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\_set\_configuration](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html). Tentukan parameter konfigurasi 'jam retensi binlog' sekaligus jumlah jam untuk menyimpan file binlog di klaster DB, hingga 2160 (90 hari). Default untuk Aurora MySQL adalah 24 (1 hari). Contoh berikut menetapkan periode penyimpanan file binlog menjadi 48 jam. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ### 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. GTID-based Untuk informasi selengkapnya, lihat [Menggunakan GTID-based replikasi](mysql-replication-gtid.md).