Gagal dalam instans DB Multi-AZ untuk Amazon RDS - Layanan Basis Data Relasional Amazon

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Gagal dalam instans DB Multi-AZ untuk Amazon RDS

Jika pemadaman instans DB multi-AZ yang direncanakan atau tidak direncanakan disebabkan oleh cacat infrastruktur, Amazon RDS secara otomatis beralih ke replika siaga di Availability Zone lain.

Durasi penyelesaian failover bergantung pada aktivitas basis data dan kondisi lain pada saat instans DB primer tidak tersedia. Durasi failover biasanya antara 60–120 detik. Namun, transaksi besar atau proses pemulihan yang panjang dapat meningkatkan waktu failover. Ketika failover selesai, RDS konsol dapat mengambil waktu tambahan untuk mencerminkan Availability Zone yang baru.

catatan

Anda dapat memaksa failover secara manual saat Anda me-reboot instans DB Multi-AZ. Untuk informasi selengkapnya, lihat Mem-boot ulang instans DB.

Amazon RDS menangani failover secara otomatis sehingga Anda dapat melanjutkan operasi database secepat mungkin tanpa intervensi administratif. Instans DB primer otomatis beralih ke replika siaga jika salah satu dari kondisi yang dijelaskan dalam tabel berikut terjadi. Anda dapat melihat alasan failover ini di log peristiwa.

Alasan failover Deskripsi
Sistem operasi yang mendasari instance RDS database sedang ditambal dalam operasi offline.

Failover dipicu selama periode pemeliharaan untuk patch OS atau pembaruan keamanan.

Untuk informasi selengkapnya, lihat Memelihara instans DB.

Host utama dari instans RDS Multi-AZ tidak sehat. Deployment instans DB Multi-AZ mendeteksi instans DB primer mengalami gangguan dan failover.
Host utama instans RDS Multi-AZ tidak dapat dijangkau karena hilangnya konektivitas jaringan.

RDSpemantauan mendeteksi kegagalan jangkauan jaringan ke instans DB utama dan memicu failover.

RDSContoh dimodifikasi oleh pelanggan.

Modifikasi instans RDS DB memicu failover.

Untuk informasi selengkapnya, lihat Memodifikasi instans Amazon RDS DB.

Instans utama RDS Multi-AZ sibuk dan tidak responsif.

Instans DB primer tidak responsif. Sebaiknya Anda melakukan tindakan berikut:

Untuk informasi selengkapnya terkait rekomendasi ini, lihat Alat pemantauan untuk Amazon RDS Amazon dan Praktik terbaik untuk Amazon RDS.

Volume penyimpanan yang mendasari host utama instans RDS Multi-AZ mengalami kegagalan. Deployment instans DB Multi-AZ mendeteksi masalah penyimpanan pada instans DB primer dan mengalami failover.
Pengguna meminta failover instans DB.

Anda mem-boot ulang instans DB dan memilih Boot ulang dengan failover.

Untuk informasi selengkapnya, lihat Mem-boot ulang instans DB.

Untuk mengetahui apakah instans DB Multi-AZ mengalami failover, Anda dapat melakukan tindakan berikut:

  • Siapkan langganan acara DB untuk memberi tahu Anda melalui email atau SMS bahwa failover telah dimulai. Untuk informasi selengkapnya tentang peristiwa, lihat Bekerja dengan pemberitahuan RDS acara Amazon.

  • Lihat peristiwa DB Anda dengan menggunakan RDS konsol atau API operasi.

  • Lihat status penerapan instans DB multi-AZ Anda saat ini dengan menggunakan RDS konsol atau API operasi.

Untuk informasi tentang cara Anda dapat merespons kegagalan, mengurangi waktu pemulihan, dan praktik terbaik lainnya untuk AmazonRDS, lihat. Praktik terbaik untuk Amazon RDS

Mengatur pencarian JVM TTL untuk DNS nama

Mekanisme failover secara otomatis mengubah catatan Domain Name System (DNS) dari instans DB untuk menunjuk ke instans DB siaga. Alhasil, Anda perlu membentuk kembali koneksi yang ada dengan instans basis data Anda. Dalam lingkungan mesin virtual Java (JVM), karena cara kerja mekanisme DNS caching Java, Anda mungkin perlu mengkonfigurasi ulang pengaturanJVM.

Pencarian DNS nama JVM cache. Ketika JVM menyelesaikan nama host ke alamat IP, itu cache alamat IP untuk jangka waktu tertentu, yang dikenal sebagai (). time-to-liveTTL

Karena AWS sumber daya menggunakan entri DNS nama yang terkadang berubah, kami sarankan Anda mengonfigurasi JVM dengan TTL nilai tidak lebih dari 60 detik. Melakukan hal ini memastikan bahwa ketika alamat IP sumber daya berubah, aplikasi Anda dapat menerima dan menggunakan alamat IP baru sumber daya dengan meminta. DNS

Pada beberapa konfigurasi Java, JVM default TTL diatur sehingga tidak pernah menyegarkan DNS entri sampai restart. JVM Jadi, jika alamat IP untuk AWS sumber daya berubah saat aplikasi Anda masih berjalan, itu tidak dapat menggunakan sumber daya itu sampai Anda secara manual me-restart JVM dan informasi IP cache di-refresh. Dalam hal ini, sangat penting untuk mengatur JVM's TTL sehingga secara berkala menyegarkan informasi IP cache.

Anda bisa mendapatkan JVM TTL default dengan mengambil nilai networkaddress.cache.ttlproperti:

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
catatan

Default TTL dapat bervariasi sesuai dengan versi Anda JVM dan apakah manajer keamanan diinstal. Banyak yang JVMs memberikan default TTL kurang dari 60 detik. Jika Anda menggunakan seperti itu JVM dan tidak menggunakan manajer keamanan, Anda dapat mengabaikan sisa topik ini. Untuk informasi selengkapnya tentang manajer keamanan di Oracle, lihat The security manager dalam dokumentasi Oracle.

Untuk memodifikasi JVM'sTTL, tetapkan nilai networkaddress.cache.ttl properti. Gunakan salah satu metode berikut, tergantung pada kebutuhan Anda:

  • Untuk menetapkan nilai properti secara global untuk semua aplikasi yang menggunakanJVM, atur networkaddress.cache.ttl dalam $JAVA_HOME/jre/lib/security/java.security file.

    networkaddress.cache.ttl=60
  • Untuk menetapkan properti secara lokal hanya untuk aplikasi Anda, tetapkan networkaddress.cache.ttl dalam kode inisialisasi aplikasi Anda sebelum koneksi jaringan dibuat.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");