Gagal dalam cluster DB multi-AZ untuk Amazon RDS - Layanan Basis Data Relasional Amazon
Failover otomatisMelakukan failover secara manual klaster basis data Multi-AZMenentukan apakah klaster basis data Multi-AZ sudah failoverMengatur JVM TTL pencarian DNS nama untuk

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

Gagal dalam cluster DB multi-AZ untuk Amazon RDS

Jika ada pemadaman instans DB penulis yang direncanakan atau tidak direncanakan di cluster DB multi-AZ, Amazon RDS secara otomatis gagal mengakses instans DB pembaca di Availability Zone yang berbeda. Ini memastikan ketersediaan tinggi dengan gangguan minimal. Kegagalan dapat terjadi selama kegagalan perangkat keras, masalah jaringan, atau permintaan manual. Topik menguraikan deteksi otomatis kegagalan, urutan peristiwa selama failover, dan dampaknya pada operasi baca dan tulis. Ini juga menyediakan praktik terbaik untuk memantau dan meminimalkan waktu failover.

Waktu yang diperlukan untuk menyelesaikan failover bergantung pada aktivitas basis data dan kondisi-kondisi lain ketika instans basis data penulis tidak tersedia. Durasi failover biasanya kurang dari 35 detik. Failover selesai ketika kedua instans basis data pembaca telah menerapkan transaksi tertunggak dari penulis yang gagal. Ketika failover selesai, RDS konsol dapat mengambil waktu tambahan untuk mencerminkan Availability Zone yang baru.

Failover otomatis

Amazon RDS menangani failover secara otomatis sehingga Anda dapat melanjutkan operasi database secepat mungkin tanpa intervensi administratif. Agar dapat failover, instans basis data penulis beralih secara otomatis ke instans basis data pembaca.

Melakukan failover secara manual klaster basis data Multi-AZ

Jika Anda gagal secara manual melalui cluster DB multi-AZ, RDS pertama-tama hentikan instans DB utama. Kemudian, sistem pemantauan internal mendeteksi bahwa instans DB primer tidak sehat dan mempromosikan instance DB replika yang dapat dibaca. Durasi failover biasanya kurang dari 35 detik.

Anda dapat gagal melalui cluster DB multi-AZ secara manual menggunakan AWS Management Console, AWS CLI, atau file. RDS API

Untuk melakukan secara manual failover klaster basis data Multi-AZ

  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.

  3. Pilih klaster basis data Multi-AZ yang ingin Anda lakukan failover.

  4. Untuk Tindakan, pilih Failover.

    Halaman Failover klaster basis data muncul.

  5. Pilih Failover untuk menegaskan failover manual.

Untuk gagal melalui cluster DB Multi-AZ secara manual, gunakan AWS CLI perintah failover-db-cluster.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Untuk gagal melalui cluster DB multi-AZ secara manual, panggil Amazon RDS API F ailoverDBCluster dan tentukan file. DBClusterIdentifier

Menentukan apakah klaster basis data Multi-AZ sudah failover

Untuk mengetahui apakah klaster basis data Multi-AZ Anda sudah failover, Anda dapat melakukan hal-hal 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.

  • Melihat peristiwa DB Anda menggunakan RDS konsol atau API operasi Amazon.

  • Lihat status klaster DB multi-AZ Anda saat ini dengan menggunakan RDS konsol Amazon, the AWS CLI, dan file. RDS API

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

Mengatur JVM TTL pencarian DNS nama untuk

Mekanisme failover secara otomatis mengubah catatan Domain Name System (DNS) dari instans DB untuk menunjuk ke instans DB pembaca. 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.

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.ttlproperti. 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");