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 dibebaskanAurora Masalah replikasi saya SQL

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 dan Amazon RDS Aurora.

Untuk informasi tentang masalah debugging menggunakan Amazon RDSAPI, lihatPemecahan masalah aplikasi di Aurora.

Tidak dapat terhubung ke instans Amazon RDS DB

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 memungkinkan 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, berbagai alamat IP, atau grup VPC keamanan 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. Ini adalah Automatic Private IP Addressing Range (APIPA), yang digunakan untuk pengalamatan tautan lokal.

  • Aksesibilitas publik — Untuk terhubung ke instans DB Anda dari luarVPC, seperti dengan menggunakan aplikasi klien, instance harus memiliki alamat IP publik yang ditetapkan untuk itu.

    Agar instans dapat diakses oleh publik, ubah instans dan pilih Ya di bagian Aksesibilitas publik. Untuk informasi selengkapnya, lihat Menyembunyikan cluster DB di a VPC dari internet.

  • Port – Port yang Anda tentukan saat membuat instans DB tidak dapat digunakan untuk mengirim atau menerima komunikasi karena batasan 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 RDS konsol Amazon di https://console.aws.amazon.com/rds/.

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

    3. Di tab Connectivity & security, tuliskan nilai VPC ID di bawah VPCdan subnet ID di bawah Subnet.

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

    5. Di panel navigasi, pilih Gateway Internet. Verifikasi bahwa ada gateway internet yang terpasang pada AndaVPC. Atau, pilih Buat Gateway Internet untuk membuat gateway internet. Pilih gateway internet, lalu pilih Lampirkan ke VPC dan ikuti petunjuk untuk melampirkannya ke AndaVPC.

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

    7. Pada tab Route Table, verifikasi bahwa ada rute dengan 0.0.0.0/0 tujuan dan gateway internet untuk Anda 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.

        UntukIPv6, 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 Bekerja dengan cluster 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 protokol pesan kontrol internet (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 ini dengan memodifikasi RDS instance.

Masalah RDS keamanan Amazon

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

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 lebih lanjut, lihat IAMdokumentasi.

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 RDS konsol Amazon modify-db-instance, AWS CLI perintah, atau dengan menggunakan odifyDBInstance API operasi M. Untuk informasi selengkapnya tentang cara mengubah instans DB dalam klaster DB, lihat Memodifikasi instans DB dalam klaster DB.

Pemadaman instans Amazon RDS DB atau reboot

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 Amazon RDS DB tidak berlaku

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 me-reboot instance DB menggunakan RDS konsol. Atau Anda dapat secara eksplisit memanggil operasi. RebootDBInstanceAPI Anda dapat mem-boot ulang tanpa failover jika instans DB ada dalam deployment Multi-AZ. Persyaratan untuk me-reboot instans DB terkait setelah perubahan parameter statis membantu mengurangi 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.

Freeable memory adalah total random access memory (RAM) pada instance DB yang dapat dibuat tersedia untuk mesin database. Ini adalah jumlah dari memori sistem operasi (OS) yang kosong serta memori cache halaman dan buffer yang tersedia. Mesin database menggunakan sebagian besar memori pada host, tetapi proses OS juga menggunakan beberapaRAM. 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 My SQL RDS , Anda dapat menyesuaikan ukuran parameter. innodb_buffer_pool_size Parameter ini diatur secara default ke 75 persen memori fisik. Untuk tips SQL pemecahan masalah saya selengkapnya, lihat Bagaimana cara memecahkan masalah memori rendah yang dapat dibebaskan di database Amazon untuk Saya? RDS SQL

Untuk Aurora Serverless v2, FreeableMemory mewakili jumlah memori yang tidak terpakai yang tersedia ketika instans DB Aurora Serverless v2 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 kapasitas 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 ACU pengaturan maksimum untuk cluster. 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.

UntukAurora Serverless v1, Anda dapat mengubah rentang kapasitas untuk menggunakan lebih banyakACUs. Untuk informasi selengkapnya, lihat Memodifikasi klaster DB Aurora Serverless v1.

Aurora SQL

Beberapa masalah SQL replikasi Saya juga berlaku untuk SQL Aurora My. Anda dapat mendiagnosis dan memperbaiki masalah tersebut.

Mendiagnosis dan mengatasi jeda di antara replika baca

Setelah Anda membuat replika baca Saya SQL dan replika tersedia, RDS Amazon pertama-tama mereplikasi perubahan yang dibuat pada instans DB sumber sejak operasi pembuatan 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 RDS metrik Amazon.

AuroraBinlogReplicaLagMetrik melaporkan nilai Seconds_Behind_Master bidang SQL SHOW REPLICA STATUS perintah Saya. Untuk informasi selengkapnya, lihat SHOWREPLICASTATUSPernyataan dalam SQL dokumentasi Saya.

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 Saya atau SQL . Nilai AuroraBinlogReplicaLag sebesar -1 juga dapat berarti bahwa nilai Seconds_Behind_Master tidak dapat ditentukan atau NULL.

catatan

Versi sebelumnya dari Aurora My SQL digunakan SHOW SLAVE STATUS sebagai pengganti. SHOW REPLICA STATUS Jika Anda menggunakan Aurora My SQL versi 1 atau 2, maka gunakan. SHOW SLAVE STATUS Gunakan SHOW REPLICA STATUS untuk Aurora SQL Versi saya 3 dan 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 My SQL tidak sinkron. 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 Milik sayaSQL, lihat Detail implementasi replikasi di dokumentasi SayaSQL.

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.

  • 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 <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 Saya atau SQL

Amazon RDS memantau status replikasi replika baca Anda. RDSmemperbarui bidang Status Replikasi dari instance replika baca menjadi Error jika replikasi berhenti karena alasan apa pun. Anda dapat meninjau detail kesalahan terkait yang dilemparkan oleh mesin Saya SQL dengan melihat bidang 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 SQL kesalahan saya dikembalikan, periksa kesalahan dalam dokumentasi pesan SQL kesalahan saya.

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. max_allowed_packetParameter ini digunakan untuk menentukan ukuran maksimum bahasa manipulasi data (DML) yang dapat dijalankan pada database. 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.

  • Menggunakan mesin penyimpanan nontransaksional seperti My. ISAM Replika baca membutuhkan mesin penyimpanan transaksional. Replikasi hanya didukung untuk mesin penyimpanan berikut: InnoDB for My SQL atau MariaDB.

    Anda dapat mengonversi ISAM tabel Saya ke InnoDB dengan perintah berikut:

    alter table <schema>.<table_name> engine=innodb;

  • Gunakan kueri nondeterministik yang tidak aman seperti SYSDATE(). Untuk informasi selengkapnya, lihat Penentuan pernyataan aman dan tidak aman dalam pencatatan biner di SQL dokumentasi Saya.

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 Aurora My SQL DB Anda harus menjalankan versi yang menyertakan 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 mysql.rds_next_master_log perintah untuk Aurora My SQL versi 1 dan 2. Anda melakukannya dengan mysql.rds_next_source_log perintah untuk Aurora My SQL versi 3 dan lebih tinggi. Instans Aurora My SQL DB Anda harus menjalankan versi yang mendukung perintah ini untuk mengubah posisi replay replika. Untuk informasi versi, lihat mysql_rds_next_master_log.

  • Jika Anda mengalami masalah kinerja sementara karena DML beban tinggi, Anda dapat mengatur innodb_flush_log_at_trx_commit parameter ke 2 di grup parameter DB pada replika baca. Melakukan hal ini dapat membantu read replica catch up, meskipun untuk sementara mengurangi atomisitas, konsistensi, isolasi, dan daya tahan ()ACID.

  • 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 SQL baca saya.

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 kasus ini, Anda mungkin mengalami kesalahan fatal karena file log biner dihapus sebelum diputar ulang di 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 My SQL adalah 24 (1 hari). Contoh berikut mengatur periode retensi file binlog menjadi 48 jam.

CALL mysql.rds_set_configuration('binlog retention hours', 48);