Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Gagal dalam cluster Multi-AZ DB untuk Amazon RDS
Jika ada pemadaman instans DB penulis yang direncanakan atau tidak direncanakan di cluster DB, Amazon RDS secara otomatis gagal ke instans DB pembaca di Availability Zone yang berbeda. Multi-AZ 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. Setelah failover selesai, mungkin perlu beberapa waktu sebelum konsol RDS dapat mencerminkan Zona Ketersediaan baru.
Topik
Failover otomatis
Amazon RDS menangani secara otomatis failover sehingga Anda dapat melanjutkan operasi basis data secepat mungkin tanpa campur tangan administratif. Agar dapat failover, instans basis data penulis beralih secara otomatis ke instans basis data pembaca.
Gagal secara manual melalui cluster Multi-AZ DB
Jika Anda gagal secara manual melalui cluster Multi-AZ DB, RDS pertama-tama mengakhiri 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 Multi-AZ DB secara manual menggunakan Konsol Manajemen AWS, AWS CLI, atau RDS API.
Untuk gagal melalui cluster Multi-AZ DB secara manual
Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/
. -
Di panel navigasi, pilih Basis data.
-
Pilih cluster Multi-AZ DB yang ingin Anda gagal.
-
Untuk Tindakan, pilih Failover.
Halaman Failover klaster basis data muncul.
-
Pilih Failover untuk menegaskan failover manual.
Untuk gagal melalui cluster Multi-AZ DB secara manual, gunakan AWS CLI perintah failover-db-cluster.
contoh
aws rds failover-db-cluster --db-cluster-identifiermymultiazdbcluster
Untuk gagal melalui kluster Multi-AZ DB secara manual, panggil Amazon RDS API FailOverdbCluster dan tentukan. DBClusterIdentifier
Menentukan apakah cluster Multi-AZ DB telah gagal
Untuk menentukan apakah cluster Multi-AZ DB Anda gagal, Anda dapat melakukan hal berikut:
Siapkan langganan peristiwa DB untuk memberi tahu Anda melalui email atau SMS bahwa failover telah diinisiasi. Lihat informasi yang lebih lengkap tentang peristiwa di Menggunakan pemberitahuan peristiwa Amazon RDS.
Lihat peristiwa basis data Anda dengan menggunakan konsol Amazon RDS atau operasi API.
Lihat status cluster Multi-AZ DB Anda saat ini dengan menggunakan konsol Amazon RDS, API AWS CLI, dan RDS.
Lihat informasi tentang cara merespons failover, mengurangi waktu pemulihan, dan praktik-praktik terbaik lain untuk Amazon RDS di Praktik terbaik untuk Amazon RDS.
Mengatur TTL JVM untuk pencarian nama DNS
Mekanisme failover mengubah secara otomatis catatan Sistem Nama Domain (DNS) dari instans basis data untuk menunjuk ke instans basis data pembaca. Alhasil, Anda perlu membentuk kembali koneksi yang ada dengan instans basis data Anda. Di lingkungan mesin virtual Java (JVM), karena cara kerja mekanisme caching DNS Java, Anda mungkin perlu mengonfigurasi ulang pengaturan JVM.
JVM menyimpan cache pencarian nama DNS. Ketika JVM menyelesaikan nama host ke alamat IP, JVM menyimpan cache alamat IP untuk jangka waktu tertentu, yang disebut time-to-live (TTL).
Karena AWS sumber daya menggunakan entri nama DNS yang terkadang berubah, kami sarankan Anda mengonfigurasi JVM Anda dengan nilai TTL tidak lebih dari 60 detik. Hal ini dapat memastikan bahwa ketika alamat IP sumber daya berubah, aplikasi Anda dapat menerima dan menggunakan alamat IP baru sumber daya dengan mengueri ulang DNS.
Pada beberapa konfigurasi Java, TTL default JVM diatur untuk tidak pernah menyegarkan entri DNS hingga JVM dimulai ulang. 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 kasus ini, mengatur TTL JVM adalah penting agar fungsi itu menyegarkan secara berkala informasi IP yang tersimpan dalam cache.
catatan
TTL default dapat bervariasi menurut versi JVM dan apakah manajer keamanan terinstal. Banyak JVM memberikan TTL default kurang dari 60 detik. Jika Anda menggunakan JVM seperti itu dan tidak menggunakan manajer keamanan, Anda dapat mengabaikan topik selanjutnya. Untuk informasi selengkapnya tentang manajer keamanan di Oracle, lihat The security manager
Untuk mengubah TTL JVM, atur nilai properti networkaddress.cache.ttl
-
Untuk menetapkan nilai properti secara global untuk semua aplikasi yang menggunakan JVM, tetapkan
networkaddress.cache.ttldalam file$JAVA_HOME/jre/lib/security/java.security.networkaddress.cache.ttl=60 -
Untuk menetapkan properti secara lokal hanya untuk aplikasi Anda, tetapkan
networkaddress.cache.ttldalam kode inisialisasi aplikasi Anda sebelum koneksi jaringan dibuat.java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
