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.

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 baca-saja. 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 Manajemen koneksi Amazon Aurora.

Tip

Dalam masing-masing Wilayah AWS, Availability Zones (AZ) 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 API Amazon RDS. 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 Zone (AZ) 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 MySQL 2.10 dan yang lebih tinggi, Anda dapat meningkatkan ketersediaan selama failover dengan menyediakan lebih dari satu instans DB pembaca dalam sebuah klaster. Di Aurora MySQL 2.10 dan yang lebih tinggi, Aurora memulai ulang hanya instans DB penulis dan instans 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 Proksi RDS dengan klaster DB Aurora Anda. Untuk informasi selengkapnya, lihat Ketersediaan yang tinggi dengan Proksi Amazon RDS.

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 primer gagal, Amazon RDS mempromosikan Replika Aurora dengan prioritas yang paling tinggi untuk instans primer 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 menaikkan replika dengan ukuran paling besar. Jika dua atau lebih Replika Aurora memiliki prioritas yang sama, maka Amazon RDS menaikkan replika bebas dengan 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 klaster atau Aurora Serverless v2 yang tersedia berisi instans pembaca apa pun di AZ lain, Aurora menggunakan mekanisme failover untuk mempromosikan salah satu instans pembaca menjadi instans primer 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 basis data MySQL eksternal, atau instans DB RDS MySQL. Untuk informasi selengkapnya, lihat Replikasi antara Aurora dan MySQL atau antara Aurora dan klaster DB Aurora lainnya (replikasi log biner).

Ketersediaan yang tinggi dengan Proksi Amazon RDS

Dengan Proksi RDS, Anda dapat membangun aplikasi yang dapat secara transparan mentolerir kegagalan basis data tanpa perlu menulis kode penanganan kegagalan yang kompleks. Proksi RDS secara otomatis merutekan lalu lintas ke instans basis data baru sekaligus mempertahankan koneksi aplikasi. Proksi RDS juga melewati cache Sistem Nama Domain (DNS) untuk mengurangi waktu failover hingga 66% untuk basis data Multi-AZ Aurora. Lihat informasi yang lebih lengkap di Menggunakan Proksi Amazon RDS untuk Aurora.