Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Ketersediaan yang tinggi untuk Amazon Aurora
Arsitektur Amazon Aurora melibatkan pemisahan penyimpanan dan komputasi. Aurora memiliki beberapa fitur ketersediaan tinggi yang berlaku untuk data dalam klaster DB Anda. Data tetap aman meskipun beberapa atau semua instans DB di klaster tidak tersedia. Fitur ketersediaan tinggi lainnya berlaku untuk instans DB. Fitur-fitur ini membantu memastikan bahwa satu atau lebih instans DB siap menangani permintaan basis data dari aplikasi Anda.
Topik
Ketersediaan data Aurora yang tinggi
Aurora menyimpan salinan data dalam klaster basis data di beberapa Zona Ketersediaan dalam satu Wilayah AWS. Aurora menyimpan salinan ini terlepas jika instans dalam klaster DB mencakup beberapa Zona Ketersediaan. Untuk informasi selengkapnya tentang Aurora, lihat Mengelola klaster DB Amazon Aurora.
Ketika data ditulis ke instans DB primer, Aurora secara sinkron mereplikasi data di seluruh Zona Ketersediaan ke enam simpul penyimpanan yang terkait dengan volume klaster Anda. Melakukan hal tersebut akan memberikan redundansi data, menghilangkan I/O freeze, dan meminimalkan lonjakan latensi selama pencadangan sistem. Menjalankan instans DB dengan ketersediaan tinggi dapat meningkatkan ketersediaan selama pemeliharaan sistem terencana, dan membantu melindungi basis data Anda terhadap kegagalan dan gangguan Zona Ketersediaan. Untuk informasi selengkapnya tentang Zona Ketersediaan, lihat Wilayah dan Zona Ketersediaan.
Ketersediaan yang tinggi untuk instans DB Aurora
Setelah Anda membuat instans primer (penulis), Anda dapat membuat hingga 15 Replika Aurora hanya baca. Replika Aurora juga dikenal sebagai instans pembaca.
Selama day-to-day operasi, Anda dapat menurunkan beberapa pekerjaan untuk aplikasi intensif baca dengan menggunakan instance pembaca untuk memproses kueri. SELECT Ketika masalah memengaruhi instans utama, salah satu dari instans pembaca ini mengambil alih sebagai instans utama. Mekanisme ini dikenal sebagai failover. Banyak fitur Aurora berlaku pada mekanisme failover. Misalnya, Aurora mendeteksi masalah basis data dan mengaktifkan mekanisme failover secara otomatis jika diperlukan. Aurora juga memiliki fitur yang mengurangi waktu failover untuk menyelesaikannya. Melakukan hal ini meminimalkan waktu tidak tersedianya basis data untuk menulis selama failover.
Aurora dirancang untuk pulih secepat mungkin, dan jalur tercepat menuju pemulihan sering kali dimulai ulang atau gagal ke instans DB yang sama. Restart lebih cepat dan melibatkan lebih sedikit overhead daripada failover.
Untuk menggunakan string koneksi yang tetap sama bahkan ketika failover menaikkan instans primer baru, Anda terhubung ke titik akhir klaster. Titik akhir klaster selalu mewakili instans utama saat ini di klaster. Untuk informasi selengkapnya tentang titik akhir klaster, lihat Koneksi titik akhir Amazon Aurora.
Tip
Dalam masing-masing Wilayah AWS, Availability Zones (AZs) mewakili lokasi yang berbeda satu sama lain untuk memberikan isolasi jika terjadi pemadaman. Kami menyarankan agar Anda mendistribusikan instans utama dan instans pembaca dalam klaster DB Anda di beberapa Availability Zone untuk meningkatkan ketersediaan klaster DB Anda. Dengan demikian, masalah yang memengaruhi seluruh Availability Zone tidak menyebabkan pemadaman bagi klaster Anda.
Anda dapat mengatur cluster DB multi-AZ dengan membuat pilihan sederhana saat Anda membuat cluster. Anda dapat menggunakan AWS Management Console, AWS CLI, atau Amazon RDSAPI. Anda juga dapat mengonversi cluster Aurora DB yang ada menjadi cluster DB multi-AZ dengan menambahkan instans DB pembaca baru dan menentukan Availability Zone yang berbeda.
Ketersediaan yang tinggi di seluruh Wilayah AWS dengan basis data global Aurora
Untuk ketersediaan tinggi di beberapa Wilayah AWS, Anda dapat mengatur database global Aurora. Setiap database global Aurora mencakup beberapa Wilayah AWS, memungkinkan pembacaan global latensi rendah dan pemulihan bencana dari pemadaman di seluruh dunia. Wilayah AWS Aurora secara otomatis menangani replikasi semua data dan pembaruan dari primer Wilayah AWS ke masing-masing Wilayah sekunder. Untuk informasi selengkapnya, lihat Menggunakan basis data global Amazon Aurora.
Toleransi kesalahan untuk klaster DB Aurora
Klaster DB Aurora toleran terhadap kesalahan secara default. Volume cluster mencakup beberapa Availability Zones (AZs) dalam satu Wilayah AWS, dan setiap Availability Zone berisi salinan data volume cluster. Fungsionalitas ini berarti bahwa klaster DB Anda dapat menoleransi kesalahan dari Zona Ketersediaan tanpa kehilangan data dan hanya berupa gangguan layanan yang singkat.
Jika instans DB primer saat ini pada suatu klaster DB gagal, Aurora secara otomatis melakukan failover ke instans DB primer yang baru.
-
Dengan menaikkan Replika Aurora yang sudah ada ke instans utama yang baru
-
Dengan membuat instans primer baru
Jika klaster DB memiliki satu atau lebih Replika Aurora, maka Replika Aurora dipromosikan ke instans primer selama peristiwa failover. Peristiwa kegagalan mengakibatkan interupsi singkat, selama operasi baca dan tulis gagal dengan pengecualian. Namun, layanan biasanya dipulihkan dalam waktu kurang dari 60 detik, dan sering kali kurang dari 30 detik. Untuk meningkatkan ketersediaan klaster DB Anda, kami sarankan Anda membuat setidaknya satu Replika Aurora atau lebih di dua Zona Ketersediaan yang berbeda.
Tip
Di Aurora My SQL 2.10 dan yang lebih tinggi, Anda dapat meningkatkan ketersediaan selama failover dengan memiliki lebih dari satu instans DB pembaca dalam sebuah cluster. Di Aurora My SQL 2.10 dan yang lebih tinggi, Aurora hanya memulai ulang instans DB penulis dan instance pembaca yang gagal. Instans pembaca lain dalam klaster ini tetap tersedia selama failover untuk terus memproses kueri melalui koneksi ke titik akhir pembaca.
Anda juga dapat meningkatkan ketersediaan selama failover dengan menggunakan RDS Proxy dengan cluster Aurora DB Anda. Untuk informasi selengkapnya, lihat Ketersediaan tinggi dengan Amazon RDS Proxy.
Anda dapat menyesuaikan urutan di mana Replika Aurora Anda dinaikkan ke instans utama setelah kegagalan dengan menetapkan masing-masing replika sebagai prioritas. Prioritas berkisar dari 0 untuk prioritas tertinggi hingga 15 untuk prioritas terendah. Jika instans utama gagal, Amazon RDS mempromosikan Replika Aurora dengan prioritas tertinggi ke instance utama yang baru. Anda dapat mengubah prioritas dari Replika Aurora kapan saja. Memodifikasi prioritas tidak memicu failover.
Lebih dari satu Replika Aurora dapat memiliki prioritas yang sama, yang menghasilkan tingkat promosi. Jika dua atau lebih Replika Aurora memiliki prioritas yang sama, maka Amazon RDS mempromosikan replika yang berukuran terbesar. Jika dua atau lebih Replika Aurora memiliki prioritas dan ukuran yang sama, maka Amazon RDS mempromosikan replika arbitrer di tingkat promosi yang sama.
Jika klaster DB tidak berisi Replika Aurora, maka instans primer dibuat ulang di AZ yang sama selama peristiwa kegagalan. Peristiwa kegagalan mengakibatkan interupsi yang operasi baca dan tulisnya gagal dengan pengecualian. Layanan dipulihkan ketika instans primer baru dibuat, yang biasanya memakan waktu kurang dari 10 menit. Mempromosikan Replika Aurora ke instans primer jauh lebih cepat daripada membuat instans primer baru.
Misalkan instans primer di klaster Anda tidak tersedia karena pemadaman yang memengaruhi keseluruhan AZ. Dalam hal ini, cara untuk menjadikan instans primer baru online tergantung pada apakah klaster Anda menggunakan konfigurasi Multi-AZ:
-
Jika disediakan atau Aurora Serverless v2 klaster Anda berisi instance pembaca apa pun di tempat lain, AZs Aurora menggunakan mekanisme failover untuk mempromosikan salah satu instance pembaca tersebut menjadi instance utama yang baru.
-
Jika klaster atau Aurora Serverless v2 yang tersedia hanya berisi satu instans DB, atau jika instans primer dan semua instans pembaca berada di AZ yang sama, pastikan untuk secara manual membuat satu atau beberapa instans DB baru di AZ lain.
-
Jika klaster Anda menggunakan Aurora Serverless v1, Aurora secara otomatis membuat instans DB baru di AZ lain. Namun, proses ini melibatkan penggantian host, sehingga membutuhkan waktu lebih lama dari failover.
catatan
Amazon Aurora juga mendukung replikasi dengan SQL database Saya eksternal, atau instans DB RDS SayaSQL. Untuk informasi selengkapnya, lihat Replikasi antara Aurora dan SQL My atau antara Aurora dan cluster Aurora DB lainnya (replikasi log biner).
Ketersediaan tinggi dengan Amazon RDS Proxy
Dengan RDS Proxy, Anda dapat membangun aplikasi yang dapat secara transparan mentolerir kegagalan database tanpa perlu menulis kode penanganan kegagalan yang kompleks. Proksi RDS secara otomatis merutekan lalu lintas ke instans basis data baru sekaligus mempertahankan koneksi aplikasi. Ini juga melewati cache Sistem Nama Domain (DNS) untuk mengurangi waktu failover hingga 66% untuk database Aurora Multi-AZ. Untuk informasi selengkapnya, lihat Menggunakan Amazon RDS Proxy untuk Aurora.
