Memulihkan basis data global Aurora dari pemadaman yang tidak direncanakan Melakukan switchover untuk basis data global Aurora Mengelola RPO untuk basis data global berbasis Aurora PostgreSQL

Menggunakan switchover atau failover dalam basis data global Amazon Aurora

Basis data global Aurora menghadirkan perlindungan kelangsungan bisnis dan pemulihan bencana (BCDR) yang lebih tinggi daripada ketersediaan tinggi standar yang dihadirkan oleh klaster DB Aurora dalam satu Wilayah AWS. Dengan menggunakan basis data global Aurora, Anda dapat membuat rencana dan melakukan pemulihan dari bencana Regional yang riil atau menyelesaikan pemadaman tingkat layanan dengan cepat. Pemulihan dari bencana biasanya didorong oleh dua tujuan bisnis berikut:

Sasaran waktu pemulihan (RTO)—Waktu yang diperlukan sistem untuk kembali ke status kerja aktif setelah terjadinya bencana atau pemadaman layanan. Dengan kata lain, RTO mengukur waktu henti operasional. Untuk basis data global Aurora, RTO dapat berada dalam hitungan menit.
Sasaran titik pemulihan (RPO)—Jumlah data yang dapat hilang (diukur berdasarkan waktu) setelah terjadinya bencana atau pemadaman layanan. Kehilangan data tersebut biasanya disebabkan oleh keterlambatan replikasi asinkron. Untuk basis data global Aurora, RPO biasanya diukur dalam hitungan detik. Dengan basis data global berbasis Aurora PostgreSQL, Anda dapat menggunakan parameter rds.global_db_rpo untuk mengatur dan melacak batas atas RPO, tetapi melakukannya dapat memengaruhi pemrosesan transaksi pada simpul penulis di klaster primer. Untuk informasi selengkapnya, lihat Mengelola RPO untuk basis data global berbasis Aurora PostgreSQL.

Melakukan switchover atau failover terhadap basis data global Aurora melibatkan tindakan promosi klaster DB di salah satu Wilayah sekunder basis data global Anda menjadi klaster DB primer. Istilah "pemadaman regional" sering kali digunakan untuk mendeskripsikan berbagai skenario kegagalan. Skenario terburuk dapat berupa pemadaman luas karena peristiwa bencana yang memengaruhi wilayah seluas ratusan mil persegi. Namun, kebanyakan pemadaman sudah jauh lebih terlokalisasi, dengan hanya memengaruhi sebagian kecil subset layanan cloud atau sistem pelanggan. Pertimbangkan cakupan pemadaman secara menyeluruh untuk memastikan bahwa failover lintas Wilayah merupakan solusi yang tepat dan untuk memilih metode failover yang sesuai dengan situasi tersebut. Penggunaan pendekatan failover atau switchover bergantung pada skenario pemadaman tertentu:

Failover—Gunakan pendekatan ini untuk melakukan pemulihan dari pemadaman yang tidak direncanakan. Dengan pendekatan ini, Anda melakukan failover lintas Wilayah ke salah satu klaster DB sekunder dalam basis data global Aurora Anda. RPO untuk pendekatan ini biasanya merupakan nilai bukan nol yang diukur dalam hitungan detik. Jumlah kehilangan data tergantung pada kelambatan replikasi database global Aurora Wilayah AWS pada saat kegagalan. Untuk mempelajari selengkapnya, lihat Memulihkan basis data global Amazon Aurora dari pemadaman yang tidak direncanakan.
Switchover—Operasi ini sebelumnya disebut "failover terencana terkelola". Gunakan pendekatan ini untuk skenario terkontrol, seperti pemeliharaan operasional dan prosedur operasional terencana lainnya. Karena fitur ini menyinkronkan klaster DB sekunder dengan primer sebelum membuat perubahan lain, RPO adalah 0 (tidak ada kehilangan data). Untuk mempelajari selengkapnya, lihat Melakukan switchover untuk basis data global Amazon Aurora.

catatan

Jika ingin melakukan switchover atau failover ke klaster DB Aurora sekunder headless, Anda harus terlebih dahulu menambahkan instans DB ke klaster tersebut. Untuk informasi selengkapnya tentang klaster DB headless, lihat Membuat klaster DB Aurora tanpa kepala di Wilayah sekunder.

Topik

Memulihkan basis data global Amazon Aurora dari pemadaman yang tidak direncanakan
Melakukan switchover untuk basis data global Amazon Aurora
Mengelola RPO untuk basis data global berbasis Aurora PostgreSQL

Memulihkan basis data global Amazon Aurora dari pemadaman yang tidak direncanakan

Pada kesempatan yang sangat langka, basis data global Aurora Anda mungkin mengalami pemadaman yang tak terduga di Wilayah AWS primernya. Jika hal ini terjadi, klaster DB Aurora primer dan simpul penulisnya tidak akan tersedia, dan replikasi antara klaster DB primer dan sekunder akan terhenti. Untuk meminimalkan waktu henti (RTO) dan kehilangan data (RPO), Anda dapat segera melakukan failover lintas Wilayah.

Terdapat dua metode untuk melakukan failover dalam situasi pemulihan bencana:

Failover terkelola—Metode ini direkomendasikan untuk pemulihan bencana. Jika Anda menggunakan metode ini, Aurora akan secara otomatis menambahkan kembali Wilayah primer yang lama ke basis data global sebagai Wilayah sekunder saat sudah tersedia lagi. Dengan begitu, topologi asli klaster global akan dipertahankan. Untuk mempelajari cara menggunakan metode ini, lihat Melakukan failover terkelola untuk basis data global Aurora.
Failover manual—Metode alternatif ini dapat digunakan ketika failover terkelola bukan merupakan pilihan, misalnya, ketika Wilayah primer dan sekunder Anda menjalankan versi mesin yang tidak kompatibel. Untuk mempelajari cara menggunakan metode ini, lihat Melakukan failover manual untuk basis data global Aurora.

penting

Kedua metode failover tersebut dapat mengakibatkan hilangnya data transaksi tulis yang tidak direplikasi ke tujuan sekunder yang dipilih sebelum peristiwa failover terjadi. Namun, proses pemulihan yang mempromosikan instans DB pada klaster DB sekunder pilihan menjadi instans DB penulis primer akan memastikan bahwa data berada dalam kondisi yang konsisten secara transaksional.

Melakukan failover terkelola untuk basis data global Aurora

Pendekatan ini ditujukan untuk kelangsungan bisnis saat terjadi bencana alam Regional yang riil atau pemadaman tingkat layanan secara menyeluruh.

Selama failover terkelola, klaster primer Anda melakukan failover ke Wilayah sekunder yang dipilih sekaligus mempertahankan topologi replikasi yang ada pada basis data global Aurora. Klaster sekunder yang dipilih mempromosikan salah satu simpul hanya-bacanya ke status penulis penuh. Langkah ini memungkinkan klaster untuk mengambil peran sebagai klaster primer. Basis data Anda tidak akan tersedia untuk sementara saat klaster ini mengambil peran barunya. Data yang tidak direplikasi dari klaster primer lama ke klaster sekunder pilihan akan hilang saat klaster sekunder ini menjadi klaster primer yang baru.

catatan

Anda hanya dapat melakukan failover basis data lintas Wilayah terkelola pada basis data global Aurora jika klaster DB primer dan sekunder memiliki versi mesin tingkat utama, minor, dan patch yang sama. Namun, tingkat patch bisa berbeda, tergantung versi mesin kecil. Untuk informasi selengkapnya, lihat Kompatibilitas tingkat patch untuk switchover dan failover lintas wilayah yang dikelola. Jika versi mesin Anda tidak kompatibel, Anda dapat melakukan failover secara manual dengan mengikuti langkah-langkah dalam Melakukan failover manual untuk basis data global Aurora.

Untuk meminimalkan kehilangan data, sebaiknya lakukan hal berikut sebelum menggunakan fitur ini:

Buat aplikasi menjadi offline untuk mencegah penulisan dikirim ke klaster primer basis data global Aurora.
Periksa waktu keterlambatan untuk semua klaster DB Aurora sekunder dalam basis data global Aurora. Memilih Wilayah sekunder dengan keterlambatan replikasi minimum dapat meminimalkan kehilangan data dari Wilayah primer yang mengalami kegagalan. Untuk semua database global berbasis Aurora PostgreSQL dan untuk database global berbasis Aurora MySQL yang dimulai dengan versi mesin 3.04.0 dan lebih tinggi, atau 2.12.0 dan lebih tinggi, gunakan Amazon untuk melihat metrik untuk semua cluster DB sekunder. CloudWatch AuroraGlobalDBRPOLag Untuk basis data global berbasis Aurora MySQL versi minor yang lebih rendah, lihat metrik AuroraGlobalDBReplicationLag. Metrik ini menunjukkan seberapa terlambatnya (dalam milidetik) replikasi ke klaster sekunder dibandingkan ke klaster DB primer.

Untuk informasi selengkapnya tentang CloudWatch metrik untuk Aurora, lihat. Metrik tingkat klaster untuk Amazon Aurora

Selama failover terkelola, klaster DB sekunder yang dipilih dipromosikan ke peran barunya sebagai klaster primer. Namun, klaster ini tidak mewarisi berbagai opsi konfigurasi klaster DB primer. Ketidakcocokan dalam konfigurasi dapat menyebabkan masalah performa, inkompatibilitas beban kerja, dan perilaku anomali lainnya. Untuk mencegah masalah tersebut, sebaiknya atasi perbedaan di antara klaster basis data global Aurora untuk konfigurasi berikut:

Konfigurasi grup parameter klaster DB Aurora untuk klaster primer yang baru jika diperlukan—Anda dapat mengonfigurasi grup parameter klaster DB Aurora secara independen untuk masing-masing klaster Aurora dalam basis data global Aurora Anda. Karena itu, ketika Anda mempromosikan klaster DB sekunder untuk mengambil alih peran sebagai klaster primer, grup parameter dari klaster sekunder mungkin memiliki konfigurasi yang berbeda dengan klaster primer. Jika demikian, ubah grup parameter klaster DB sekunder yang dipromosikan agar sesuai dengan pengaturan klaster primer Anda. Untuk mempelajari caranya, lihat Memodifikasi parameter basis data global Aurora.
Konfigurasikan alat dan opsi pemantauan, seperti Amazon CloudWatch Events dan alarm — Konfigurasikan cluster DB yang dipromosikan dengan kemampuan logging, alarm, dan sebagainya yang sama sesuai kebutuhan untuk database global. Seperti grup parameter, konfigurasi untuk fitur ini tidak diwariskan dari klaster primer selama proses failover berlangsung. Beberapa CloudWatch metrik, seperti replikasi lag, hanya tersedia untuk Wilayah sekunder. Karena itu, failover akan mengubah cara Anda melihat metrik tersebut dan mengatur alarmnya, serta mengharuskan adanya perubahan pada dasbor yang ditentukan sebelumnya. Untuk informasi selengkapnya tentang klaster DB Aurora dan pemantauan, lihat Ikhtisar pemantauan Amazon Aurora.
Konfigurasikan integrasi dengan AWS layanan lain — Jika database global Aurora Anda terintegrasi AWS dengan layanan, AWS Secrets Manager seperti, AWS Identity and Access Management Amazon S3, AWS Lambda dan, Anda perlu memastikan ini dikonfigurasi sesuai kebutuhan. Untuk informasi selengkapnya tentang cara mengintegrasi basis data global Aurora dengan IAM, Amazon S3, dan Lambda, lihat Menggunakan basis data global Amazon Aurora dengan layanan AWS lainnya. Untuk mempelajari Secrets Manager selengkapnya, lihat Cara mengotomatiskan replikasi rahasia secara AWS Secrets Manager keseluruhan. Wilayah AWS

Biasanya, klaster sekunder yang dipilih akan mengasumsikan peran primer dalam beberapa menit. Segera setelah simpul penulis Wilayah primer baru tersedia, Anda dapat menghubungkan aplikasi Anda ke simpul tersebut dan melanjutkan beban kerja Anda. Setelah mempromosikan klaster primer yang baru, Aurora secara otomatis membangun ulang semua klaster Wilayah sekunder tambahan.

Karena basis data global Aurora menggunakan replikasi asinkron, keterlambatan replikasi di masing-masing Wilayah sekunder dapat bervariasi. Aurora membangun kembali Wilayah sekunder ini untuk memiliki point-in-time data yang sama persis dengan cluster Region primer yang baru. Durasi penyelesaian tugas pembangunan ulang dapat memerlukan waktu beberapa menit hingga beberapa jam, bergantung pada ukuran volume penyimpanan dan jarak di antara Wilayah. Saat klaster Wilayah sekunder selesai dibuat ulang dari Wilayah primer yang baru, klaster ini menjadi tersedia untuk akses baca.

Segera setelah penulis primer baru dipromosikan dan tersedia, klaster Wilayah primer yang baru dapat menangani operasi baca dan tulis untuk basis data global Aurora. Pastikan Anda mengubah titik akhir untuk aplikasi agar dapat menggunakan titik akhir yang baru. Jika Anda menyetujui nama yang disediakan saat membuat basis data global Aurora, Anda dapat mengubah titik akhir dengan menghapus -ro dari string titik akhir klaster yang dipromosikan dalam aplikasi Anda.

Sebagai contoh, titik akhir klaster sekunder my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com menjadi my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com ketika klaster tersebut dipromosikan menjadi klaster primer.

Jika Anda menggunakan Proksi RDS, pastikan untuk mengalihkan operasi tulis aplikasi ke titik akhir baca/tulis yang sesuai dari proksi yang terkait dengan klaster primer baru. Titik akhir proksi ini mungkin merupakan titik akhir default atau titik akhir baca/tulis kustom. Untuk informasi selengkapnya, lihat Cara kerja titik akhir Proksi RDS dengan basis data global.

Untuk memulihkan topologi asli klaster basis data global, Aurora memantau ketersediaan Wilayah primer yang lama. Segera setelah Wilayah tersebut normal dan tersedia kembali, Aurora secara otomatis menambahkannya kembali ke klaster global sebagai Wilayah sekunder. Sebelum membuat volume penyimpanan baru di Wilayah primer yang lama, Aurora mencoba mengambil snapshot dari volume penyimpanan lama pada titik kegagalan. Hal ini dilakukan agar Anda dapat menggunakannya untuk memulihkan setiap data yang hilang. Jika operasi ini berhasil, Aurora menempatkan snapshot ini bernama “rds: unplanned-global-failover - name-of-old-primary-DB-cluster - timestamp" di bagian snapshot. AWS Management Console Anda juga dapat melihat snapshot ini tercantum dalam informasi yang ditampilkan oleh operasi DescribeDB API ClusterSnapshots.

catatan

Snapshot dari volume penyimpanan lama adalah snapshot sistem yang tunduk pada periode retensi pencadangan yang dikonfigurasi pada klaster primer yang lama. Untuk mempertahankan snapshot ini di luar periode retensi, Anda dapat menyalin snapshot untuk disimpan sebagai snapshot manual. Untuk mempelajari selengkapnya tentang cara menyalin snapshot, termasuk harga, lihat Menyalin snapshot klaster DB.

Setelah topologi asli dipulihkan, Anda dapat mengembalikan basis data global ke Wilayah primer asli dengan melakukan operasi switchover jika dianggap sebagai tindakan terbaik untuk bisnis dan beban kerja Anda. Untuk melakukannya, ikuti langkah-langkah yang ada di Melakukan switchover untuk basis data global Amazon Aurora.

Anda dapat gagal atas database global Aurora Anda menggunakan AWS Management Console, API AWS CLI, atau RDS.

Untuk melakukan failover terkelola pada basis data global Aurora:

Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
Pilih Basis Data, lalu temukan basis data global Aurora yang ingin Anda terapkan failover.
Pilih Alihkan atau lakukan failover basis data global dari menu Tindakan.
Pilih Failover (memungkinkan kehilangan data).
Untuk cluster primer baru, pilih klaster aktif di salah satu cluster sekunder Anda Wilayah AWS untuk menjadi cluster primer baru.
Masukkan confirm, lalu pilih Konfirmasi.

Setelah failover selesai, Anda dapat melihat klaster DB Aurora dan statusnya saat ini di daftar Basis Data, sebagaimana ditunjukkan pada gambar berikut.

Menampilkan daftar Basis Data dengan basis data global yang dipilih. Klaster sekunder yang dipilih kini menunjukkan telah memiliki peran klaster primer dan klaster primer yang lama memiliki peran klaster sekunder.

Untuk melakukan failover terkelola pada basis data global Aurora:

Gunakan perintah CLI failover-global-cluster untuk melakukan failover pada basis data global Aurora. Dengan perintah tersebut, loloskan nilai untuk parameter berikut.

--region— Tentukan Wilayah AWS di mana cluster DB sekunder yang Anda inginkan menjadi primer baru untuk database global Aurora berjalan.
--global-cluster-identifier—Tentukan nama basis data global Aurora.
--target-db-cluster-identifier—Tentukan Amazon Resource Name (ARN) untuk klaster DB Aurora yang ingin Anda promosikan menjadi klaster primer baru untuk basis data global Aurora.
--allow-data-loss—Secara eksplisit jadikan tindakan ini sebagai operasi failover, bukan operasi switchover. Operasi failover dapat membuat Anda kehilangan sejumlah data jika komponen replikasi asinkron belum selesai mengirim semua data yang direplikasi ke Wilayah sekunder.

Untuk Linux, macOS, atau Unix:


aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Untuk Windows:


aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

Untuk gagal dalam database global Aurora, jalankan operasi FailoverGlobalClusterAPI.

Melakukan failover manual untuk basis data global Aurora

Dalam skenario tertentu, Anda mungkin tidak dapat menggunakan proses failover terkelola. Salah satu contohnya adalah jika klaster DB primer dan sekunder tidak menjalankan versi mesin yang kompatibel. Dalam kasus ini, Anda dapat mengikuti proses manual ini untuk melakukan failover basis data global ke Wilayah sekunder tujuan Anda.

Tip

Sebaiknya Anda memahami proses ini sebelum menggunakannya. Siapkan rencana untuk segera memulai saat pertama kali muncul tanda masalah tingkat Wilayah. Anda dapat siap mengidentifikasi Wilayah sekunder dengan kelambatan replikasi paling sedikit dengan menggunakan Amazon CloudWatch secara teratur untuk melacak waktu jeda untuk klaster sekunder. Pastikan Anda menguji rencana untuk memastikan prosedur sudah lengkap dan akurat, dan bahwa staf Anda terlatih untuk melakukan failover pemulihan bencana sebelum bencana benar-benar terjadi.

Untuk melakukan failover ke klaster sekunder secara manual setelah terjadi pemadaman tak terduga di Wilayah primer:

Berhenti mengeluarkan pernyataan DHTML dan operasi penulisan lainnya ke klaster Aurora DB utama di with the Wilayah AWS outage.
Identifikasi cluster Aurora DB dari sekunder Wilayah AWS untuk digunakan sebagai cluster DB primer baru. Jika Anda memiliki dua atau lebih sekunder Wilayah AWS dalam database global Aurora Anda, pilih cluster sekunder yang memiliki kelambatan replikasi paling sedikit.
Lepaskan klaster DB sekunder pilihan Anda dari basis data global Aurora.

Pelepasan klaster DB sekunder dari basis data global Aurora akan segera menghentikan replikasi dari klaster primer ke klaster sekunder tersebut dan mempromosikannya menjadi klaster DB Aurora yang berdiri sendiri dengan kapabilitas baca/tulis penuh. Klaster DB Aurora sekunder lainnya yang terkait dengan klaster primer di Wilayah yang mengalami pemadaman akan tetap tersedia dan dapat menerima panggilan dari aplikasi Anda. Klaster tersebut juga mengonsumsi sumber daya. Karena Anda membuat ulang basis data global Aurora, hapus klaster DB sekunder lainnya sebelum membuat basis data global Aurora yang baru dengan mengikuti langkah-langkah berikut. Tindakan ini akan mencegah inkonsistensi data di antara klaster DB dalam basis data global Aurora (masalah split-brain).

Untuk langkah-langkah pelepasan terperinci, lihat Menghapus klaster dari basis data global Amazon Aurora.
Konfigurasi ulang aplikasi Anda untuk mengirim semua operasi tulis ke klaster DB Aurora yang kini berdiri sendiri ini menggunakan titik akhir barunya. Jika Anda menyetujui nama yang disediakan ketika Anda membuat basis data global Aurora, Anda dapat mengubah titik akhir dengan menghapus -ro dari string titik akhir klaster dalam aplikasi Anda.

Sebagai contoh, titik akhir klaster sekunder my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com menjadi my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com saat klaster tersebut dilepas dari basis data global Aurora.

Klaster DB Aurora ini menjadi klaster primer untuk basis data global Aurora yang baru ketika Anda mulai menambahkan Wilayah ke dalamnya pada langkah berikutnya.

Jika Anda menggunakan Proksi RDS, pastikan untuk mengalihkan operasi tulis aplikasi ke titik akhir baca/tulis yang sesuai dari proksi yang terkait dengan klaster primer baru. Titik akhir proksi ini mungkin merupakan titik akhir default atau titik akhir baca/tulis kustom. Untuk informasi selengkapnya, lihat Cara kerja titik akhir Proksi RDS dengan basis data global.
Tambahkan Wilayah AWS ke cluster DB. Saat Anda melakukannya, proses replikasi dari klaster primer ke klaster sekunder akan dimulai. Untuk langkah menambahkan Wilayah secara mendetail, lihat Menambahkan Wilayah AWS ke basis data global Amazon Aurora.
Tambahkan lebih banyak Wilayah AWS sesuai kebutuhan untuk membuat ulang topologi yang diperlukan untuk mendukung aplikasi Anda.

Pastikan penulisan aplikasi dikirim ke klaster DB Aurora yang benar, baik sebelum, selama, maupun sesudah membuat perubahan ini. Tindakan ini akan mencegah inkonsistensi data di antara klaster DB dalam basis data global Aurora (masalah split-brain).

Jika Anda mengonfigurasi ulang sebagai respons terhadap pemadaman di sebuah Wilayah AWS, Anda dapat menjadikannya primer lagi setelah pemadaman diselesaikan. Wilayah AWS Untuk melakukannya, Anda harus menambahkan Wilayah AWS yang lama ke basis data global baru, lalu menggunakan proses switchover untuk mengalihkan perannya. Basis data global Aurora harus menggunakan versi Aurora PostgreSQL atau Aurora MySQL yang mendukung switchover. Untuk informasi selengkapnya, lihat Melakukan switchover untuk basis data global Amazon Aurora.

Melakukan switchover untuk basis data global Amazon Aurora

catatan

Switchover sebelumnya disebut "failover terencana terkelola".

Dengan menggunakan switchover, Anda dapat mengubah Wilayah cluster utama Anda secara rutin. Pendekatan ini ditujukan untuk skenario yang terkontrol, seperti pemeliharaan operasional dan prosedur operasional terencana lainnya.

Terdapat tiga kasus umum untuk penggunaan switchover.

Untuk persyaratan "rotasi regional" yang diberlakukan pada industri tertentu. Misalnya, peraturan layanan keuangan mungkin menginginkan sistem tier-0 untuk beralih ke Wilayah yang berbeda selama beberapa bulan untuk memastikan prosedur pemulihan bencana dilaksanakan secara teratur.
Untuk aplikasi Multi-region follow-the-sun "”. Misalnya, suatu bisnis mungkin ingin menyediakan penulisan dengan latensi lebih rendah di berbagai Wilayah berdasarkan jam kerja di zona waktu yang berbeda.
Sebagai zero-data-loss metode untuk gagal kembali ke Wilayah primer asli setelah failover.

catatan

Switchover dirancang untuk digunakan pada basis data global Aurora yang berfungsi baik. Untuk pulih dari pemadaman yang tak terduga, ikuti prosedur yang sesuai di Memulihkan basis data global Amazon Aurora dari pemadaman yang tidak direncanakan.

Untuk melakukan switchover, klaster DB sekunder target Anda harus menjalankan versi mesin yang sama persis dengan klaster primer, termasuk tingkat patch-nya, tergantung pada versi mesin. Untuk informasi selengkapnya, lihat Kompatibilitas tingkat patch untuk switchover dan failover lintas wilayah yang dikelola. Sebelum Anda memulai switchover, periksa versi mesin di klaster global untuk memastikan versi mesin tersebut mendukung switchover lintas Wilayah terkelola, lalu tingkatkan jika diperlukan.

Selama proses switchover, Aurora mengalihkan klaster primer Anda ke Wilayah sekunder pilihan sambil mempertahankan topologi replikasi yang ada pada basis data global Anda. Sebelum memulai proses switchover, Aurora menunggu hingga semua klaster Wilayah sekunder disinkronkan sepenuhnya dengan klaster Wilayah primer. Selanjutnya, klaster DB di Wilayah primer menjadi klaster hanya-baca, dan klaster sekunder yang dipilih akan mempromosikan salah satu simpul hanya-bacanya menjadi status penulis penuh. Mempromosikan simpul ini menjadi penulis memungkinkan klaster sekunder mengambil peran klaster primer. Karena semua klaster sekunder disinkronkan dengan klaster primer pada awal proses, klaster primer yang baru akan melanjutkan operasi untuk basis data global Aurora tanpa kehilangan data apa pun. Basis data Anda tidak tersedia untuk sementara selama klaster primer dan klaster sekunder yang dipilih mengambil peran barunya masing-masing.

Untuk mengoptimalkan ketersediaan aplikasi, sebaiknya lakukan hal berikut sebelum menggunakan fitur ini:

Lakukan operasi ini di luar jam sibuk atau pada waktu lainnya saat operasi penulisan ke klaster DB primer tidak banyak.
Buat aplikasi menjadi offline untuk mencegah penulisan dikirim ke klaster primer basis data global Aurora.
Periksa waktu keterlambatan untuk semua klaster DB Aurora sekunder dalam basis data global Aurora. Untuk semua database global berbasis Aurora PostgreSQL dan untuk database global berbasis Aurora MySQL yang dimulai dengan versi mesin 3.04.0 dan lebih tinggi atau 2.12.0 dan lebih tinggi, gunakan Amazon untuk melihat metrik untuk semua cluster DB sekunder. CloudWatch AuroraGlobalDBRPOLag Untuk basis data global berbasis Aurora MySQL versi minor yang lebih rendah, lihat metrik AuroraGlobalDBReplicationLag. Metrik ini menunjukkan seberapa terlambatnya (dalam milidetik) replikasi ke klaster sekunder dibandingkan ke klaster DB primer. Nilai ini berbanding lurus dengan waktu yang diperlukan Aurora untuk menyelesaikan switchover. Karena itu, semakin besar nilai keterlambatan, semakin lama durasi switchover.

Untuk informasi selengkapnya tentang CloudWatch metrik untuk Aurora, lihat. Metrik tingkat klaster untuk Amazon Aurora

Selama proses switchover, klaster DB sekunder yang dipilih akan dipromosikan ke peran barunya sebagai primer. Namun, klaster ini tidak mewarisi berbagai opsi konfigurasi klaster DB primer. Ketidakcocokan dalam konfigurasi dapat menyebabkan masalah performa, inkompatibilitas beban kerja, dan perilaku anomali lainnya. Untuk mencegah masalah tersebut, sebaiknya atasi perbedaan di antara klaster basis data global Aurora untuk konfigurasi berikut:

Konfigurasi grup parameter klaster DB Aurora untuk klaster primer yang baru jika diperlukan—Anda dapat mengonfigurasi grup parameter klaster DB Aurora secara independen untuk masing-masing klaster Aurora dalam basis data global Aurora Anda. Hal ini berarti ketika Anda mempromosikan klaster DB sekunder untuk mengambil alih peran primer, grup parameter dari klaster sekunder mungkin memiliki konfigurasi yang berbeda dengan klaster primer. Jika demikian, ubah grup parameter klaster DB sekunder yang dipromosikan agar sesuai dengan pengaturan klaster primer Anda. Untuk mempelajari caranya, lihat Memodifikasi parameter basis data global Aurora.
Konfigurasikan alat dan opsi pemantauan, seperti Amazon CloudWatch Events dan alarm — Konfigurasikan cluster DB yang dipromosikan dengan kemampuan logging, alarm, dan sebagainya yang sama sesuai kebutuhan untuk database global. Seperti grup parameter, konfigurasi untuk fitur ini tidak diwariskan dari klaster primer selama proses switchover berlangsung. Beberapa CloudWatch metrik, seperti replikasi lag, hanya tersedia untuk Wilayah sekunder. Karena itu, switchover akan mengubah cara Anda melihat metrik tersebut dan mengatur alarmnya, serta mengharuskan adanya perubahan pada dasbor yang ditentukan sebelumnya. Untuk informasi selengkapnya tentang klaster DB Aurora dan pemantauan, lihat Ikhtisar pemantauan Amazon Aurora.
Konfigurasikan integrasi dengan AWS layanan lain — Jika database global Aurora Anda terintegrasi AWS dengan layanan, AWS Secrets Manager seperti, AWS Identity and Access Management Amazon S3, AWS Lambda dan, pastikan untuk mengonfigurasi integrasi Anda dengan layanan ini sesuai kebutuhan. Untuk informasi selengkapnya tentang cara mengintegrasi basis data global Aurora dengan IAM, Amazon S3, dan Lambda, lihat Menggunakan basis data global Amazon Aurora dengan layanan AWS lainnya. Untuk mempelajari Secrets Manager selengkapnya, lihat Cara mengotomatiskan replikasi rahasia secara AWS Secrets Manager keseluruhan. Wilayah AWS

catatan

Biasanya, switchover peran dapat memerlukan waktu hingga beberapa menit. Namun, membangun klaster sekunder tambahan dapat berlangsung selama beberapa menit hingga beberapa jam, bergantung pada ukuran basis data dan jarak fisik di antara Wilayah.

Saat proses switchover selesai, klaster DB Aurora yang dipromosikan dapat menangani operasi penulisan untuk basis data global Aurora. Pastikan Anda mengubah titik akhir untuk aplikasi agar dapat menggunakan titik akhir yang baru. Jika Anda menyetujui nama yang disediakan saat membuat basis data global Aurora, Anda dapat mengubah titik akhir dengan menghapus -ro dari string titik akhir klaster yang dipromosikan dalam aplikasi Anda.

Anda dapat beralih ke database global Aurora Anda menggunakan AWS Management Console, API AWS CLI, atau RDS.

Cara melakukan switchover pada basis data global Aurora

Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
Pilih Basis Data, lalu temukan basis data global Aurora yang ingin Anda terapkan switchover.
Pilih Alihkan atau lakukan failover basis data global dari menu Tindakan.
Pilih Switchover.
Untuk cluster primer baru, pilih klaster aktif di salah satu cluster sekunder Anda Wilayah AWS untuk menjadi cluster primer baru.
Pilih Konfirmasi.

Setelah switchover selesai, Anda dapat melihat klaster DB Aurora dan perannya saat ini di daftar Basis Data, sebagaimana ditunjukkan pada gambar berikut.

Untuk melakukan switchover pada basis data global Aurora:

Gunakan perintah CLI switchover-global-cluster untuk melakukan switchover pada basis data global Aurora. Dengan perintah tersebut, loloskan nilai untuk parameter berikut.

--region— Tentukan Wilayah AWS di mana cluster DB utama dari database global Aurora berjalan.
--global-cluster-identifier—Tentukan nama basis data global Aurora.
--target-db-cluster-identifier—Tentukan Amazon Resource Name (ARN) untuk klaster DB Aurora yang ingin Anda promosikan menjadi klaster primer basis data global Aurora.

Untuk Linux, macOS, atau Unix:


aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Untuk Windows:


aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

Untuk beralih ke database global Aurora, jalankan operasi SwitchoverGlobalClusterAPI.

Mengelola RPO untuk basis data global berbasis Aurora PostgreSQL

Dengan basis data global berbasis Aurora PostgreSQL, Anda dapat mengelola sasaran titik pemulihan (RPO) untuk basis data global Aurora menggunakan parameter rds.global_db_rpo. RPO mewakili jumlah maksimum data yang dapat hilang ketika terjadi pemadaman.

Ketika Anda mengatur RPO untuk basis data global berbasis Aurora PostgreSQL, Aurora memantau Waktu keterlambatan RPO dari semua klaster sekunder untuk memastikan bahwa setidaknya satu klaster sekunder tetap dalam jendela target RPO. Waktu keterlambatan RPO adalah salah satu metrik berbasis waktu.

RPO digunakan ketika database Anda melanjutkan operasi di baru Wilayah AWS setelah failover. Aurora mengevaluasi RPO dan waktu keterlambatan RPO untuk melakukan commit (atau memblokir) transaksi pada klaster primer sebagai berikut:

Menjalankan commit transaksi jika setidaknya satu klaster DB sekunder memiliki waktu keterlambatan RPO lebih rendah dari RPO.
Memblokir transaksi jika semua klaster DB sekunder memiliki waktu keterlambatan RPO yang lebih tinggi dari RPO. Aurora juga mencatat peristiwa ke file log PostgreSQL dan mengeluarkan peristiwa "tunggu" yang menunjukkan sesi terblokir.

Dengan kata lain, jika semua klaster sekunder berada di belakang RPO target, Aurora akan menjeda transaksi pada klaster primer hingga setidaknya satu klaster sekunder mengimbangi. Transaksi yang dijeda akan dilanjutkan dan di-commit segera setelah waktu keterlambatan dari setidaknya satu klaster DB sekunder menjadi lebih rendah dari RPO. Hasilnya adalah bahwa tidak ada transaksi yang dapat di-commit hingga RPO terpenuhi.

Parameter rds.global_db_rpo bersifat dinamis. Jika Anda memutuskan untuk tidak menghentikan semua transaksi tulis hingga keterlambatan cukup berkurang, Anda dapat meresetnya dengan cepat. Dalam kasus ini, Aurora akan menerima dan mengimplementasikan perubahan setelah beberapa saat.

penting

Dalam basis data global yang hanya memiliki dua Wilayah, sebaiknya jangan ubah nilai default parameter rds.global_db_rpo di grup parameter Wilayah sekunder. Jika melakukannya, failover ke Wilayah ini akibat hilangnya Wilayah primer dapat menyebabkan Aurora menjeda transaksi. Sebaiknya tunggu hingga Aurora menyelesaikan pembangunan ulang klaster di Wilayah lama yang mengalami kegagalan sebelum Anda mengubah parameter ini untuk menerapkan RPO maksimum.

Jika menetapkan parameter ini sebagaimana diuraikan berikutnya, Anda juga dapat memantau metrik yang dihasilkannya. Anda dapat melakukannya menggunakan psql atau alat lain untuk membuat kueri klaster DB primer basis data global Aurora dan mendapatkan informasi terperinci tentang operasi basis data global berbasis Aurora PostgreSQL. Untuk mempelajari caranya, lihat Memantau basis data global berbasis Aurora PostgreSQL.

Mengatur sasaran titik pemulihan

Parameter rds.global_db_rpo mengontrol pengaturan RPO untuk basis data PostgreSQL. Parameter ini didukung oleh Aurora PostgreSQL. Nilai yang valid untuk rds.global_db_rpo berkisar dari 20 detik hingga 2.147.483.647 detik (68 tahun). Pilih nilai yang realistis untuk memenuhi kasus penggunaan dan kebutuhan bisnis Anda. Misalnya, Anda mungkin ingin mengizinkan durasi RPO hingga 10 menit, sehingga Anda menetapkan nilai ke 600.

Anda dapat menetapkan nilai ini untuk basis data global berbasis Aurora PostgreSQL menggunakan AWS Management Console, AWS CLI, atau API RDS.

Cara mengatur RPO

Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
Pilih klaster primer basis data global Aurora, lalu buka tab Konfigurasi untuk menemukan grup parameter klaster DB. Sebagai contoh, grup parameter default untuk klaster DB primer yang menjalankan Aurora PostgreSQL 11.7 adalah default.aurora-postgresql11.

Grup parameter tidak dapat diedit secara langsung. Sebaliknya, lakukan hal berikut:
- Buat grup parameter klaster DB kustom menggunakan grup parameter default yang sesuai sebagai titik awal. Misalnya, buat grup parameter klaster DB kustom berdasarkan default.aurora-postgresql11.
- Pada grup parameter klaster DB kustom, tetapkan nilai parameter rds.global_db_rpo agar sesuai dengan kasus penggunaan Anda. Nilai yang valid berkisar dari 20 detik hingga nilai integer maksimum sebesar 2.147.483.647 (68 tahun).
- Terapkan grup parameter klaster DB yang telah dimodifikasi ke klaster DB Aurora Anda.

Untuk informasi selengkapnya, lihat Mengubah parameter dalam grup parameter klaster DB.

Untuk mengatur rds.global_db_rpo parameter, gunakan perintah modify-db-cluster-parameter-group CLI. Dalam perintahnya, tentukan nama grup parameter klaster primer dan nilai untuk parameter RPO.

Contoh berikut mengatur RPO ke 600 detik (10 menit) untuk grup parameter klaster DB primer, my_custom_global_parameter_group.

Untuk Linux, macOS, atau Unix:


aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Untuk Windows:


aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Untuk memodifikasi rds.global_db_rpo parameter, gunakan operasi Amazon RDS ModifyDB API ClusterParameterGroup.

Melihat sasaran titik pemulihan

Sasaran titik pemulihan (RPO) dari basis data global disimpan di parameter rds.global_db_rpo untuk setiap klaster DB. Anda dapat terhubung ke titik akhir klaster sekunder yang ingin Anda lihat dan menggunakan psql untuk membuat kueri instans bagi nilai ini.


db-name=>show rds.global_db_rpo;

Jika parameter ini belum diatur, kueri akan menampilkan sebagai berikut:


rds.global_db_rpo
-------------------
 -1
(1 row)

Respons selanjutnya ini berasal dari klaster DB sekunder yang memiliki pengaturan RPO 1 menit.


rds.global_db_rpo
-------------------
 60
(1 row)

Anda juga dapat menggunakan CLI untuk memperoleh nilai guna mengetahui apakah rds.global_db_rpo aktif pada salah satu klaster DB Aurora dengan menggunakan CLI untuk memperoleh nilai semua parameter user untuk klaster tersebut.

Untuk Linux, macOS, atau Unix:


aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Untuk Windows:


aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

Perintah akan menampilkan output serupa dengan yang berikut untuk semua parameter user selain parameter klaster DB default-engine atau system.


{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

Untuk mempelajari selengkapnya tentang cara melihat parameter dari grup parameter klaster, lihat Melihat nilai parameter untuk grup parameter klaster DB.

Menonaktifkan sasaran titik pemulihan

Untuk menonaktifkan RPO, reset parameter rds.global_db_rpo. Anda dapat mengatur ulang parameter menggunakan AWS Management Console, AWS CLI, atau RDS API.

Cara menonaktifkan RPO

Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
Di panel navigasi, pilih Grup parameter.
Dalam daftar, pilih grup parameter klaster DB primer Anda.
Pilih Edit parameter.
Pilih kotak di sebelah parameter rds.global_db_rpo.
Pilih Reset.
Saat layar menampilkan Reset parameter dalam grup parameter DB, pilih Reset parameter.

Untuk informasi selengkapnya tentang cara mereset parameter dengan konsol, lihat Mengubah parameter dalam grup parameter klaster DB.

Untuk mengatur ulang rds.global_db_rpo parameter, gunakan perintah reset-db-cluster-parameter-group.

Untuk Linux, macOS, atau Unix:


aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

Untuk Windows:


aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

Untuk mengatur ulang rds.global_db_rpo parameter, gunakan operasi Amazon RDS API ClusterParameterGroupResetDB.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Menggunakan penerusan tulis di Aurora PostgreSQL

Memantau basis data global Aurora