Pemecahan Masalah untuk Amazon Aurora - Amazon Aurora
Tidak dapat terhubung ke instans DBMasalah keamananMengatur ulang kata sandi pemilik instans DBPenghentian atau boot ulang instans DBPerubahan parameter tidak diberlakukanMasalah memori Aurora yang dapat dikosongkanMasalah replikasi Aurora MySQL

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.

Untuk informasi tentang masalah debug menggunakan API Amazon RDS, lihat Pemecahan masalah aplikasi di Aurora.

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 Menyediakan akses ke cluster DB di VPC dengan membuat grup keamanan.

    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 klaster DB dalam VPC dari internet.

  • 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 AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

    2. Di panel navigasi, pilih Basis Data lalu pilih instans DB.

    3. Di tab Konektivitas & keamanan, tuliskan nilai ID VPC di VPC dan subnet ID di Subnet.

    4. Buka konsol VPC Amazon di. https://console.aws.amazon.com/vpc/

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

    6. Di panel navigasi, pilih Subnet, lalu pilih subnet Anda.

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

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

      3. 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 klaster DB di VPC.

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. Untuk informasi tentang membuat pengguna AWS IAM Identity Center, lihat Mengelola identitas di Pusat Identitas IAM.

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.

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.

Anda dapat mengubah kata sandi instans DB dengan menggunakan konsol Amazon RDS, AWS CLI perintah modify-db-instance, atau dengan menggunakan operasi Modify DBInstance API. Untuk informasi selengkapnya tentang cara mengubah instans DB dalam klaster DB, lihat Memodifikasi instans DB dalam klaster DB.

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 RebootDBInstance. 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 Memodifikasi parameter dalam grup parameter DB di Aurora.

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

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 Kelas instans Amazon Aurora DB.

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?

Untuk Aurora Serverless v2, FreeableMemory mewakili jumlah memori yang tidak terpakai yang tersedia saat Aurora Serverless v2 Instans DB 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 v2.

Untuk Aurora Serverless v1, Anda dapat mengubah rentang kapasitas untuk menggunakan lebih banyak ACUs. Untuk informasi selengkapnya, lihat Memodifikasi Aurora Serverless v1 Klaster DB.

Masalah replikasi Amazon Aurora MySQL

Beberapa masalah replikasi MySQL juga berlaku untuk Aurora MySQL. Anda dapat mendiagnosis dan memperbaiki masalah tersebut.

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 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 Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL. 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 tulis ke replika baca akan diserialkan menggunakan thread I/O tunggal. Situasi tersebut dapat menyebabkan jeda antara instans sumber dan replika baca.

Untuk informasi selengkapnya tentang replika baca dan MySQL, lihat Replication implementation details 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.

  • 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. Berikut ini menunjukkan contoh.

    Untuk Linux, macOS, atau Unix:

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    Untuk Windows:

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL

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, RDS-EVENT-0046, dan RDS-EVENT-0057. Untuk informasi selengkapnya tentang peristiwa dan berlangganan peristiwa, lihat Bekerja dengan pemberitahuan RDS acara Amazon. Jika pesan kesalahan MySQL muncul, periksa kesalahannya di MySQL error message documentation.

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 <schema>.<table_name> engine=innodb;

  • Gunakan kueri nondeterministik yang tidak aman seperti SYSDATE(). Untuk informasi selengkapnya, lihat Determination of safe and unsafe statements in binary logging 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. 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.

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

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

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. 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 berbasis GTID. Untuk informasi selengkapnya, lihat Menggunakan replikasi GTID berbasis.