Deployment instans DB Multi-AZ - Layanan Basis Data Relasional Amazon
Mengubah instans DB menjadi deployment instans DB Multi-AZProses failover untuk Amazon RDS

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

Deployment instans DB Multi-AZ

Amazon RDS menyediakan ketersediaan tinggi dan dukungan failover untuk instans DB menggunakan deployment Multi-AZ dengan instans DB siaga tunggal. Jenis deployment ini disebut deployment instans DB Multi-AZ. Amazon RDS menggunakan berbagai teknologi untuk memberikan dukungan failover ini. Deployment Multi-AZ untuk instans DB MariaDB, MySQL, Oracle, PostgreSQL, dan RDS Custom for SQL Server menggunakan teknologi failover Amazon. Instans DB Microsoft SQL Server menggunakan SQL Server Database Mirroring (DBM) atau Always On Availability Groups (AG). Untuk informasi tentang dukungan versi SQL Server untuk Multi-AZ, lihat Penerapan multi-AZ untuk Amazon untuk Microsoft Server RDS SQL. Untuk informasi tentang penggunaan RDS Custom for SQL Server untuk Multi-AZ, lihat Mengelola deployment Multi-AZ untuk RDS Custom for SQL Server.

Dalam deployment instans DB Multi-AZ, Amazon RDS akan otomatis menyediakan dan mempertahankan replika siaga yang sinkron di Zona Ketersediaan yang berbeda. Instans DB primer direplikasi secara sinkron di seluruh Zona Ketersediaan ke replika siaga untuk memberikan redundansi data dan meminimalkan lonjakan latensi selama pencadangan sistem. Menjalankan instans DB dengan ketersediaan tinggi dapat meningkatkan ketersediaan selama pemeliharaan sistem terencana. Hal ini juga dapat membantu melindungi basis data Anda terhadap kegagalan instans DB dan gangguan Zona Ketersediaan. Untuk informasi selengkapnya tentang Zona Ketersediaan, lihat Wilayah, Zona Ketersediaan, dan Zona Lokal.

catatan

Opsi ketersediaan tinggi bukanlah solusi penskalaan untuk skenario baca-saja. Anda tidak dapat menggunakan replika siaga untuk menyajikan lalu lintas baca. Untuk menyajikan lalu lintas baca-saja, gunakan klaster DB Multi-AZ atau replika baca. Untuk informasi selengkapnya tentang klaster DB Multi-AZ, lihat Deployment klaster basis data Multi-AZ. Untuk informasi selengkapnya tentang replika baca, lihat Menggunakan replika baca instans DB.

Skenario ketersediaan tinggi

Dengan menggunakan konsol RDS, Anda dapat membuat deployment instans DB Multi-AZ hanya dengan menentukan Multi-AZ saat membuat instans DB. Anda dapat menggunakan konsol untuk mengonversi instans DB yang ada ke deployment instans DB Multi-AZ dengan mengubah instans DB dan menentukan opsi Multi-AZ. Anda juga dapat menentukan penerapan instans DB multi-AZ dengan atau AWS CLI Amazon RDS API. Gunakan perintah create-db-instanceatau modify-db-instanceCLI, atau operasi CreateDBInstance atau ModifydBInstance API.

Konsol RDS menunjukkan Zona Ketersediaan replika siaga (disebut AZ sekunder). Anda juga dapat menggunakan perintah describe-db-instancesCLI atau operasi API DescribedBInstances untuk menemukan AZ sekunder.

Instans DB yang menggunakan deployment instans DB Multi-AZ dapat meningkatkan latensi tulis dan commit dibandingkan dengan deployment Single-AZ. Hal ini karena replikasi data sinkron yang terjadi. Anda mungkin mengalami perubahan latensi jika penerapan Anda gagal ke replika siaga, meskipun direkayasa dengan konektivitas jaringan latensi rendah AWS antara Availability Zones. Untuk beban kerja produksi, sebaiknya Anda menggunakan IOPS yang Tersedia (operasi input/output per detik) untuk performa yang cepat dan konsisten. Untuk informasi selengkapnya tentang kelas instans DB, lihat DB.

Mengubah instans DB menjadi deployment instans DB Multi-AZ

Jika Anda memiliki instans DB dalam deployment Single-AZ dan mengubahnya menjadi deployment instans DB Multi-AZ (untuk mesin selain Amazon Aurora), Amazon RDS akan melakukan beberapa tindakan:

  1. Mengambil snapshot volume Amazon Elastic Block Store (EBS) instans DB utama.

  2. Membuat volume baru untuk replika siaga dari snapshot. Volume tersebut diinisialisasi di latar belakang, dan performa volume maksimum akan tercapai setelah data sepenuhnya diinisialisasi.

  3. Mengaktifkan replikasi tingkat blok sinkron antara volume replika utama dan siaga.

penting

Penggunaan snapshot untuk membuat instans siaga dapat menghindari waktu henti saat mengonversi dari Single-AZ ke Multi-AZ, tetapi Anda dapat merasakan dampak performa selama dan setelah mengonversi ke Multi-AZ. Hal ini dapat memberikan dampak yang signifikan terhadap beban kerja yang sensitif terhadap latensi tulis.

Meskipun kemampuan ini memungkinkan volume besar dipulihkan dengan cepat dari snapshot, peningkatan latensi operasi I/O yang signifikan dapat terjadi karena adanya replikasi yang sinkron. Latensi ini dapat memengaruhi performa basis data Anda. Praktik terbaik yang sangat direkomendasikan adalah tidak melakukan konversi multi-AZ pada instans DB produksi.

Untuk menghindari dampak performa pada instans DB yang saat ini melayani beban kerja sensitif, buat replika baca dan aktifkan pencadangan pada replika baca. Konversikan replika baca ke Multi-AZ, dan jalankan kueri yang memuat data ke dalam volume replika baca (pada kedua AZ). Kemudian, promosikan replika baca menjadi instans DB primer. Untuk informasi selengkapnya, lihat Menggunakan replika baca instans DB.

Ada dua cara untuk mengubah instans DB menjadi deployment instans DB Multi-AZ:

Mengonversi menjadi deployment instans DB Multi-AZ dengan konsol RDS

Anda dapat menggunakan konsol RDS untuk mengonversi instans DB menjadi deployment instans DB Multi-AZ.

Anda hanya dapat menggunakan konsol tersebut untuk menyelesaikan konversi. Untuk menggunakan AWS CLI atau RDS API, ikuti petunjuk diMengubah instans DB menjadi deployment instans DB Multi-AZ.

Untuk mengonversi menjadi deployment instans DB Multi-AZ dengan konsol RDS

  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 yang ingin diubah.

  3. Dari Tindakan, pilih Konversikan menjadi deployment Multi-AZ.

  4. Di halaman konfirmasi, pilih Terapkan langsung untuk langsung menerapkan perubahan. Memilih opsi ini tidak akan menyebabkan waktu henti, tetapi ada kemungkinan dampak performa. Atau, Anda dapat memilih untuk menerapkan pembaruan pada periode pemeliharaan berikutnya. Untuk informasi selengkapnya, lihat Pengaturan modifikasi jadwal.

  5. Pilih Konversikan menjadi Multi-AZ.

Mengubah instans DB menjadi deployment instans DB Multi-AZ

Anda dapat mengubah instans DB menjadi deployment instans DB MultiAZ dengan cara berikut:

  • Dengan menggunakan konsol RDS, ubah instans DB, dan tetapkan Deployment Multi-AZ ke Ya.

  • Menggunakan AWS CLI, panggil modify-db-instanceperintah, dan atur --multi-az opsi.

  • Dengan menggunakan API RDS, panggil operasi ModifyDBInstance, dan tetapkan parameter MultiAZ ke true.

Untuk informasi tentang cara mengubah instans DB, lihat Memodifikasi instans DB Amazon RDS. Setelah perubahan selesai, Amazon RDS memicu peristiwa (RDS-EVENT-0025) yang menunjukkan bahwa proses telah selesai. Anda dapat memantau peristiwa Amazon RDS. Untuk informasi selengkapnya tentang peristiwa, lihat Bekerja dengan pemberitahuan RDS acara Amazon.

Proses failover untuk Amazon RDS

Jika penghentian instans DB terencana atau tidak terencana terjadi karena cacat infrastruktur, Amazon RDS akan otomatis beralih ke replika siaga di Zona Ketersediaan lain jika Anda telah mengaktifkan Multi-AZ. 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. Setelah failover selesai, perlu waktu tambahan agar konsol RDS dapat mencerminkan Zona Ketersediaan baru.

catatan

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

Amazon RDS menangani failover secara otomatis sehingga Anda dapat melanjutkan operasi basis data 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 instans basis data RDS sedang di-patch dalam operasi offline.

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

Untuk informasi selengkapnya, lihat Memelihara instans DB.
Host primer instans Multi-AZ RDS tidak sehat. Deployment instans DB Multi-AZ mendeteksi instans DB primer mengalami gangguan dan failover.
Host primer instans Multi-AZ RDS tidak terjangkau karena kehilangan konektivitas jaringan.

Pemantauan RDS mendeteksi kegagalan menjangkau jaringan ke instans DB primer dan telah memicu failover.
Instans RDS diubah oleh pelanggan.

Perubahan instans DB RDS memicu failover.

Untuk informasi selengkapnya, lihat Memodifikasi instans DB Amazon RDS.
Instans primer Multi-AZ RDS 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 primer instans Multi-AZ RDS mengalami kegagalan. Deployment instans DB Multi-AZ mendeteksi masalah penyimpanan pada instans DB primer dan mengalami failover.
Pengguna meminta failover instans DB.

Anda me-reboot 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 peristiwa 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 menggunakan operasi API konsol RDS.

  • Lihat kondisi deployment instans DB Multi-AZ menggunakan operasi API konsol RDS.

Untuk informasi tentang cara merespons failover, mengurangi waktu pemulihan, dan praktik terbaik lainnya untuk Amazon RDS, lihat Praktik terbaik untuk Amazon RDS.

Mengatur TTL JVM untuk pencarian nama DNS

Mekanisme failover otomatis mengubah catatan Sistem Nama Domain (DNS) instans DB menjadi titik ke instans DB siaga. Oleh karena itu, Anda perlu membuat kembali koneksi yang ada ke instans DB Anda. Di lingkungan mesin virtual Java (JVM), karena cara kerja mekanisme pengisian cache DNS Java, Anda mungkin perlu mengonfigurasikan ulang setelan JVM.

JVM menyimpan pencarian nama DNS di cache. Ketika JVM menyelesaikan nama host ke alamat IP, itu cache alamat IP untuk jangka waktu tertentu, yang dikenal sebagai (TTL). time-to-live

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 memastikan bahwa ketika alamat IP sumber daya berubah, aplikasi Anda dapat menerima dan menggunakan alamat IP baru sumber daya itu dengan mengueri ulang DNS.

Pada beberapa konfigurasi Java, TTL bawaan JVM diatur sedemikian rupa sehingga 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, penting untuk mengatur TTL JVM untuk menyegarkan informasi IP yang tersimpan dalam cache secara berkala.

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


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

TTL default dapat bervariasi berdasarkan versi JVM Anda dan apakah manajer keamanan telah diinstal. Banyak JVM menyediakan TTL bawaan yang kurang dari 60 detik. Jika Anda menggunakan JVM seperti itu dan tidak menggunakan manajer keamanan, Anda dapat mengabaikan bagian selebihnya topik ini. Lihat informasi yang lebih lengkap tentang manajer keamanan di Oracle di Manajer keamanan dalam dokumentasi Oracle.

Untuk mengubah TTL JVM, atur nilai properti networkaddress.cache.ttl. Gunakan salah satu metode berikut, sesuai dengan kebutuhan Anda:

  • Untuk mengatur nilai properti secara global bagi semua aplikasi yang menggunakan JVM, atur networkaddress.cache.ttl dalam file $JAVA_HOME/jre/lib/security/java.security.

    
networkaddress.cache.ttl=60

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

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