Ketersediaan tinggi (Keandalan) di Azure Database for PostgreSQL

Artikel ini menjelaskan ketersediaan tinggi di Azure Database for PostgreSQL, yang mencakup zona ketersediaan dan pemulihan lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum keandalan yang lebih rinci di Azure, lihat Keandalan Azure.

Azure Database for PostgreSQL mendukung ketersediaan tinggi dengan menyediakan replika utama dan siaga yang dipisahkan secara fisik, baik dalam zona ketersediaan (zonal) yang sama atau di seluruh zona ketersediaan (zona-redundan). Model ketersediaan tinggi ini dirancang untuk memastikan bahwa data yang diterapkan tidak pernah hilang selama kegagalan. Dalam penyiapan ketersediaan tinggi (HA), data dikomit secara sinkron ke server utama dan siaga. Model ini dirancang agar database tidak menjadi satu titik kegagalan dalam arsitektur perangkat lunak Anda. Untuk informasi selengkapnya tentang ketersediaan tinggi dan dukungan zona ketersediaan, lihat Dukungan zona ketersediaan.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik di setiap wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure Database for PostgreSQL mendukung model zona-redundan dan zonal untuk konfigurasi ketersediaan tinggi. Kedua konfigurasi ketersediaan tinggi memungkinkan kemampuan failover otomatis tanpa kehilangan data selama kejadian yang direncanakan maupun tidak direncanakan.

• Zona-redundan. Ketersediaan tinggi zona redundan menyebarkan replika siaga di zona yang berbeda dengan kemampuan failover otomatis. Redundansi zona memberikan tingkat ketersediaan tertinggi, tetapi Anda perlu mengonfigurasi redundansi aplikasi di seluruh zona. Untuk alasan itu, pilih redundansi zona saat Anda menginginkan perlindungan dari kegagalan tingkat zona ketersediaan dan kapan latensi di seluruh zona ketersediaan dapat diterima. Meskipun mungkin ada beberapa dampak latensi pada penulisan dan komitmen karena replikasi sinkron, itu tidak memengaruhi kueri baca. Dampak ini khusus untuk beban kerja Anda, jenis SKU yang Anda pilih, dan wilayah.

  Anda dapat memilih wilayah dan zona ketersediaan untuk server utama dan siaga. Server replika siaga disediakan di zona ketersediaan yang dipilih di wilayah yang sama dengan komputasi, penyimpanan, dan konfigurasi jaringan serupa dengan server utama. File data dan file log transaksi (log write-ahead, juga dikenal sebagai WAL) disimpan di penyimpanan redundan lokal (LRS) dalam setiap zona ketersediaan, secara otomatis menyimpan tiga salinan data. Konfigurasi yang redundan antar zona menyediakan isolasi fisik dari seluruh tumpukan antara server primer dan server siaga.

  

Opsi zona-redundan hanya tersedia di wilayah yang memiliki dukungan untuk zona ketersediaan.

Redundansi zona tidak didukung untuk:

• Tingkat komputasi yang dapat meledak

• Wilayah dengan ketersediaan zona tunggal

• Zonal. Pilih penyebaran zona ketika Anda ingin mencapai tingkat ketersediaan tertinggi dalam satu zona ketersediaan, tetapi dengan latensi jaringan terendah. Anda dapat memilih wilayah dan zona ketersediaan untuk menyebarkan server database utama Anda. Server replika siaga secara otomatis disediakan dan dikelola di zona ketersediaan yang sama - dengan komputasi, penyimpanan, dan konfigurasi jaringan serupa - sebagai server utama. Konfigurasi zonal melindungi database Anda dari kegagalan tingkat simpul dan juga membantu mengurangi waktu henti aplikasi selama peristiwa waktu henti yang direncanakan dan tidak direncanakan. Data dari server utama direplikasi ke replika siaga dalam mode sinkron. jika ada gangguan pada server utama, server secara otomatis beralih ke replika siaga.

  

Opsi penyebaran zona tersedia di semua wilayah Azure tempat Anda dapat menyebarkan Server Fleksibel.

Nota

Model penyebaran zonal dan redundan zona secara arsitektur berperilaku sama. Berbagai diskusi di bagian berikut berlaku untuk keduanya kecuali disebutkan sebaliknya.

Mengonfigurasi ketahanan zona di portal

Anda dapat mengonfigurasi ketersediaan tinggi (HA) dengan dua cara: ketersediaan tinggi zona-redundan, yang menempatkan server siaga di zona ketersediaan yang berbeda untuk ketahanan maksimum, atau ketersediaan tinggi zona yang sama, yang menyebarkan server siaga di zona yang sama dengan server utama untuk meminimalkan latensi.

Untuk menyederhanakan konfigurasi dan memastikan ketahanan zona, portal menyediakan opsi Ketahanan Zona dengan dua tombol radio: Diaktifkan dan Dinonaktifkan. Memilih Aktifkan berupaya untuk membuat server siaga di zona ketersediaan yang berbeda (mode HA yang tahan terhadap gangguan zona). Jika wilayah tidak mendukung HA (High Availability) zona redundan, Anda dapat memilih kotak centang fallback (disorot dalam gambar berikut) untuk mengaktifkan HA dalam zona yang sama.

Saat Anda memilih kotak centang fallback, sistem membuat server siaga di zona yang sama. Jika kapasitas zonal nantinya tersedia, Azure akan memberi tahu Anda sehingga Anda dapat memilih untuk bermigrasi ke konfigurasi HA zona-redundan menggunakan PITR atau replika baca. Jika Anda tidak memilih kotak centang dan kapasitas zonal tidak tersedia, pengaktifan KETERSEDIAAN TINGGI gagal. Desain ini menetapkan HA zone-redundansi sebagai default sambil menyediakan fallback terkontrol untuk HA dalam zona yang sama, memastikan beban kerja akhirnya mencapai ketahanan zona penuh tanpa intervensi manual.

Fitur ketersediaan tinggi

• Replika siaga disebarkan dalam konfigurasi VM yang sama dengan server utama, termasuk vCores, penyimpanan, dan pengaturan jaringan.

• Anda dapat menambahkan dukungan zona ketersediaan untuk server database yang sudah ada.

• Anda dapat menghapus replika siaga dengan menonaktifkan fitur ketersediaan tinggi.

• Anda dapat memilih zona ketersediaan untuk server database utama dan cadangan Anda guna memastikan ketersediaan zona yang redundant.

• Operasi seperti berhenti, memulai, dan memulai ulang dilakukan pada server database primer dan siaga pada saat yang bersamaan.

• Dalam model zona-redundan dan zonal, server database utama secara berkala melakukan pencadangan otomatis. Pada saat yang sama, replika siaga terus mengarsipkan log transaksi di penyimpanan cadangan. Jika wilayah mendukung zona ketersediaan, data cadangan disimpan di penyimpanan zona redundan (ZRS). Di wilayah yang tidak mendukung zona ketersediaan, data cadangan disimpan di penyimpanan redundan lokal (LRS).

• Klien selalu tersambung ke nama host akhir server database utama.

• Setiap perubahan pada parameter server juga diterapkan ke replika siaga.

• Anda dapat memulai ulang server untuk mengambil perubahan parameter server statis apa pun.

• Aktivitas perawatan berkala seperti peningkatan versi minor dilakukan terlebih dahulu pada sistem cadangan. Untuk mengurangi downtime, perangkat standby diangkat menjadi node utama agar beban kerja dapat terus berjalan saat tugas pemeliharaan diterapkan pada node lainnya.

Nota

Untuk memastikan fungsi high availability dengan benar, konfigurasikan nilai parameter server max_replication_slots dan max_wal_senders. Ketersediaan tinggi membutuhkan empat dari masing-masing sistem untuk menangani failover dan pembaruan yang mulus. Untuk pengaturan ketersediaan tinggi dengan lima replika baca dan 12 slot replikasi logis, atur nilai parameter max_replication_slots dan max_wal_senders ke 21. Konfigurasi ini diperlukan karena setiap replika baca dan setiap slot replikasi logis masing-masing memerlukan satu, ditambah empat yang diperlukan agar ketersediaan tinggi berfungsi dengan baik. Untuk informasi selengkapnya tentang max_replication_slots parameter dan max_wal_senders , lihat dokumentasi.

Memantau kesehatan ketersediaan tinggi

Pemantauan status kesehatan ketersediaan tinggi (HA) di Azure Database for PostgreSQL memberikan gambaran umum berkelanjutan tentang kesehatan dan kesiapan instans berkemampuan HA. Fitur pemantauan ini menerapkan kerangka kerja Pemeriksaan Kesehatan Sumber Daya (RHC) Azure untuk mendeteksi dan memperingatkan masalah apa pun yang mungkin memengaruhi kesiapan failover database Anda atau ketersediaan keseluruhan. Dengan menilai metrik utama seperti status koneksi, status failover, dan kesehatan replikasi data, pemantauan status kesehatan HA memungkinkan pemecahan masalah proaktif dan membantu mempertahankan waktu aktif dan performa database Anda.

Gunakan pemantauan status kesehatan HA untuk:

• Dapatkan wawasan real time tentang kesehatan replika primer dan siaga, dengan indikator status yang mengungkapkan potensi masalah, seperti performa yang terdegradasi atau pemblokiran jaringan.
• Siapkan pemberitahuan tepat waktu pada setiap perubahan status HA, sehingga Anda dapat segera mengambil tindakan untuk mengatasi potensi gangguan.
• Optimalkan kesiapan failover dengan mengidentifikasi dan mengatasi masalah sebelum memengaruhi operasi database.

Untuk panduan terperinci tentang mengonfigurasi dan menginterpretasikan status kesehatan HA, lihat Pemantauan status kesehatan Ketersediaan Tinggi (HA) untuk Azure Database for PostgreSQL.

Batasan ketersediaan tinggi

• Karena adanya replikasi sinkron ke server siaga, terutama dengan konfigurasi redundansi zona, aplikasi dapat mengalami peningkatan pada latensi tulis dan komit.

• Anda tidak dapat menggunakan replika siaga untuk kueri baca.

• Bergantung pada beban kerja dan aktivitas di server utama, proses failover mungkin memakan waktu lebih dari 120 detik karena replika siaga perlu pulih sebelum dapat dipromosikan.

• Server cadangan biasanya memulihkan file WAL pada kecepatan 40 MB per detik. Untuk versi yang lebih besar, tingkat ini dapat meningkat hingga sebanyak 200 MB/dtk. Jika beban kerja Anda melebihi batas ini, Anda mungkin mengalami waktu pemulihan yang lebih lama baik selama failover maupun setelah membuat siaga baru.

• Memulai ulang server database utama juga memulai ulang replika siaga.

• Anda tidak dapat mengonfigurasi siaga tambahan.

• Anda tidak dapat menjadwalkan tugas manajemen yang diinisiasi oleh pelanggan pada saat jendela pemeliharaan yang terkelola.

• Peristiwa yang direncanakan seperti komputasi skala dan penyimpanan skala terjadi pada server cadangan terlebih dahulu, baru kemudian di server utama. Saat ini, server tidak melakukan failover untuk operasi yang direncanakan ini.

• Jika Anda mengonfigurasi decoding logis atau replikasi logis pada server fleksibel berkemampuan HA:

  • Di PostgreSQL 16 dan versi sebelumnya, slot replikasi logis secara default tidak dipertahankan di server siaga setelah failover.
  • Untuk memastikan replikasi logis terus berfungsi setelah failover, Anda perlu mengaktifkan pg_failover_slots ekstensi dan mengonfigurasi pengaturan pendukung seperti hot_standby_feedback = on.
  • Dimulai dengan PostgreSQL 17, sinkronisasi slot didukung secara bawaan. Jika Anda mengaktifkan konfigurasi PostgreSQL yang benar (sync_replication_slots, hot_standby_feedback), slot replikasi logis dipertahankan secara otomatis setelah failover, dan tidak diperlukan ekstensi.
  • Untuk langkah-langkah penyiapan dan prasyarat, lihat dokumentasi ekstensi PG_Failover_Slots .

• Mengonfigurasi zona ketersediaan antara privat (jaringan virtual) dan akses publik dengan titik akhir privat tidak didukung. Anda harus mengonfigurasi zona ketersediaan dalam jaringan virtual (dilintasi di seluruh zona ketersediaan dalam satu wilayah) atau akses publik dengan titik akhir privat.

• Anda hanya dapat mengonfigurasi zona ketersediaan dalam satu wilayah. Anda tidak dapat mengonfigurasi zona ketersediaan di seluruh wilayah.

SLA

• Model Zonal menawarkan uptime SLA sekitar 99,95%.

• Model Zona-redundansi menawarkan waktu aktif untuk SLA sekitar 99,99%.

Membuat Azure Database for PostgreSQL dengan zona ketersediaan diaktifkan

Untuk mempelajari cara membuat Azure Database for PostgreSQL untuk ketersediaan tinggi dengan zona ketersediaan, lihat Mulai Cepat: Membuat Azure Database for PostgreSQL di portal Microsoft Azure.

Penyebaran dan migrasi ulang zona ketersediaan

Untuk mempelajari cara mengaktifkan atau menonaktifkan konfigurasi ketersediaan tinggi di server fleksibel Anda dalam model penyebaran zona-redundan dan zonal, lihat Mengelola ketersediaan tinggi di Server Fleksibel.

Komponen dan alur kerja ketersediaan tinggi

Penyelesaian transaksi

Transaksi aplikasi memicu penulisan dan komit yang pertama kali dicatat ke WAL di server utama. Server utama mengalirkan log ini ke server siaga dengan menggunakan protokol streaming Postgres. Ketika penyimpanan server siaga mempertahankan log, server utama mengakui penyelesaian tulis. Aplikasi melakukan transaksinya hanya setelah pengakuan ini. Round-trip tambahan ini menambah latensi pada aplikasi Anda. Persentase dampak tergantung pada aplikasi. Proses konfirmasi ini tidak menunggu log diterapkan ke server cadangan. Server cadangan tetap dalam mode pemulihan hingga diaktifkan.

Pemeriksaan kesehatan

Pemantauan kesehatan server yang fleksibel secara berkala memeriksa kesehatan server utama dan siaga. Setelah beberapa ping, jika pemantauan kesehatan mendeteksi bahwa server utama tidak dapat dijangkau, layanan memulai failover otomatis ke server siaga. Algoritma pemantauan kesehatan menggunakan beberapa titik data untuk menghindari situasi positif palsu.

Mode Pemulihan

Server fleksibel mendukung dua mode failover, Failover terencana dan Failover yang tidak direncanakan. Pada kedua mode, setelah replikasi berhenti, server siaga menjalankan pemulihan sebelum promosi dalam mode primer dan terbuka untuk baca/tulis. Dengan entri DNS otomatis yang diperbarui dengan titik akhir server utama baru, aplikasi dapat terhubung ke server dengan menggunakan titik akhir yang sama. Server siaga baru dibuat di latar belakang, sehingga aplikasi Anda dapat mempertahankan konektivitas.

Status ketersediaan tinggi

Sistem terus memantau kesehatan server primer dan siaga. Dibutuhkan tindakan yang tepat untuk memperbaiki masalah, termasuk memicu failover ke server siaga. Tabel berikut ini mencantumkan kemungkinan status ketersediaan tinggi:

Keadaan	Deskripsi
Initializing	Dalam proses membuat server siaga baru.
Mereplikasi Data	Setelah siaga dibuat, siaga tersebut akan menyusul ke primernya.
Sehat	Replikasi dalam status stabil dan sehat.
Pemindahan	Server database sedang dalam tahap berpindah ke server cadangan.
Menghapus Mode Siaga	Dalam proses menghapus server siaga.
Tidak Diaktifkan	Ketersediaan tinggi tidak diaktifkan.

Nota

Anda dapat mengaktifkan ketersediaan tinggi selama pembuatan server atau di lain waktu. Jika Anda mengaktifkan atau menonaktifkan ketersediaan tinggi selama tahap pasca-buat, lakukan saat aktivitas server utama rendah.

Operasi berstatus stabil

Aplikasi klien PostgreSQL terhubung ke server utama dengan menggunakan nama server DB. Server utama langsung melayani pembacaan aplikasi. Pada saat yang sama, aplikasi menerima konfirmasi komitmen dan penulisan hanya setelah data log tersimpan persisten di server utama dan replika siaga. Karena ekstra perjalanan pulang pergi ini, aplikasi dapat mengharapkan latensi yang ditingkatkan untuk penulisan dan penerapan. Anda dapat memantau status kesehatan ketersediaan tinggi di portal.

1. Klien tersambung ke server fleksibel dan melakukan operasi tulis.
2. Perubahan mereplikasi ke situs siaga.
3. Primer menerima pengakuan.
4. Penulisan data dan komit dikonfirmasi.

Pemulihan ke titik waktu tertentu untuk server dengan ketersediaan tinggi

Untuk server fleksibel yang dikonfigurasi dengan ketersediaan tinggi, sistem mereplikasi data log secara real time ke server siaga. Setiap kesalahan pengguna di server utama - seperti penurunan tabel yang tidak disengaja atau pembaruan data yang salah - direplikasi ke replika siaga. Jadi, Anda tidak dapat menggunakan mode siaga untuk memulihkan dari kesalahan logis tersebut. Untuk memulihkan dari kesalahan tersebut, Anda harus melakukan pemulihan dari titik waktu tertentu dari cadangan. Dengan menggunakan kemampuan pemulihan point-in-time server yang fleksibel, Anda dapat memulihkan ke waktu sebelum kesalahan terjadi. Server database baru dipulihkan sebagai server fleksibel zona tunggal dengan nama server baru yang disediakan pengguna untuk database yang dikonfigurasi dengan ketersediaan tinggi. Anda dapat menggunakan server yang dipulihkan untuk beberapa kasus penggunaan:

• Gunakan server yang dipulihkan untuk produksi dan secara opsional mengaktifkan ketersediaan tinggi dengan replika siaga pada zona yang sama atau zona lain di wilayah yang sama.

• Jika Anda ingin memulihkan objek, ekspor dari server database yang dipulihkan dan impor ke server database produksi Anda.

• Jika Anda ingin mengkloning server database Anda untuk tujuan pengujian dan pengembangan atau memulihkan untuk tujuan lain, Anda dapat melakukan pemulihan titik waktu.

Untuk mempelajari cara melakukan pemulihan pada titik waktu dari server fleksibel, lihat Pemulihan titik waktu server fleksibel.

Dukungan failover

Kegagalan terencana

Peristiwa waktu henti yang direncanakan mencakup pembaruan perangkat lunak berkala yang dijadwalkan dan peningkatan versi minor dari Azure. Anda juga dapat menggunakan failover yang direncanakan untuk mengembalikan server utama ke zona ketersediaan pilihan. Saat Anda mengonfigurasi ketersediaan tinggi, operasi ini terlebih dahulu berlaku untuk replika siaga sementara aplikasi terus mengakses server utama. Setelah proses memperbarui replika siaga, ia menguras koneksi server utama dan memicu failover yang mengaktifkan replika siaga sebagai server utama dengan nama server database yang sama. Aplikasi klien terhubung kembali dengan nama server database yang sama ke server utama baru dan dapat melanjutkan operasi mereka. Proses ini membuat server siaga baru di zona yang sama dengan primer lama.

Untuk operasi lain yang dimulai pengguna seperti menskalakan komputasi atau menskalakan penyimpanan, proses menerapkan perubahan pada sistem siaga terlebih dahulu, lalu pada sistem primer. Saat ini, layanan tidak beralih ke mode siaga. Oleh karena itu, saat operasi skala berjalan di server utama, aplikasi mengalami waktu henti yang singkat.

Anda juga dapat menggunakan fitur ini untuk failover ke server siaga dengan mengurangi waktu henti. Misalnya, server utama Anda dapat berada di zona ketersediaan yang berbeda dari aplikasi setelah failover yang tidak direncanakan. Anda ingin membawa server utama kembali ke zona sebelumnya untuk dikolokasikan dengan aplikasi Anda.

Ketika Anda menjalankan fitur ini, proses pertama-tama menyiapkan server siaga untuk memastikannya mengejar transaksi terbaru, memungkinkan aplikasi untuk terus melakukan baca dan tulis. Proses ini mengaktifkan cadangan dan memutuskan koneksi dengan yang utama. Aplikasi Anda dapat terus menulis ke server utama sementara proses membuat server siaga baru di latar belakang. Tabel berikut menjelaskan langkah-langkah yang terlibat dengan failover yang direncanakan:

Step	Deskripsi	Apakah waktu henti aplikasi diharapkan?
1	Tunggu hingga server siaga mengejar ketinggalan dengan server utama.	Tidak.
2	Sistem pemantauan internal memulai alur kerja pindah alih.	Tidak.
3	Penulisan aplikasi diblokir ketika server siaga dekat dengan nomor urutan log utama (LSN).	Yes
4	Server siaga dipromosikan menjadi server independen.	Yes
5	Catatan DNS diperbarui dengan alamat IP server siaga baru.	Yes
6	Aplikasi terhubung kembali dan melanjutkan baca/tulisnya dengan primer baru.	Tidak.
7	Server siaga baru di zona lain didirikan.	Tidak.
8	Server siaga mulai mengambil kembali log (dari Azure Blob) yang terlewatkan selama pembentukannya.	Tidak.
9	Kondisi stabil antara server utama dan server siaga telah tercipta.	Tidak.
10	Proses failover yang direncanakan sudah selesai.	Tidak.

Waktu henti aplikasi dimulai pada langkah 3 dan dapat melanjutkan operasi setelah langkah 5. Langkah-langkah lainnya terjadi di latar belakang tanpa memengaruhi penulisan dan penerapan aplikasi.

Tip

Dengan server fleksibel, Anda dapat secara opsional menjadwalkan aktivitas pemeliharaan yang dimulai Azure dengan memilih jendela 60 menit pada hari preferensi Anda ketika aktivitas pada database diperkirakan rendah. Tugas pemeliharaan Azure seperti patching atau peningkatan versi minor terjadi selama jendela tersebut. Jika Anda tidak memilih jendela kustom, sistem mengalokasikan jendela satu jam antara pukul 23.00 dan 07.00 waktu setempat untuk server Anda. Aktivitas pemeliharaan oleh Azure ini juga dilakukan pada replika siaga untuk server fleksibel yang dikonfigurasi dengan zona ketersediaan.

Untuk daftar kemungkinan peristiwa waktu henti yang direncanakan, lihat Peristiwa waktu henti yang direncanakan.

Kegagalan tidak terencana

Waktu henti yang tidak diencana dapat terjadi sebagai akibat dari gangguan tak terduga seperti kesalahan perangkat keras yang mendasarinya, masalah jaringan, dan bug perangkat lunak. Jika server database yang dikonfigurasi dengan ketersediaan tinggi tidak berfungsi secara tiba-tiba, proses mengaktifkan replika siaga dan klien dapat melanjutkan operasi mereka. Jika Anda tidak mengonfigurasi ketersediaan tinggi (HA), dan upaya hidupkan ulang gagal, proses secara otomatis menyediakan server database baru. Meskipun waktu henti yang tidak diencana tidak dapat dihindari, server fleksibel membantu mengurangi waktu henti dengan melakukan operasi pemulihan secara otomatis tanpa memerlukan intervensi manusia.

Untuk informasi tentang failover dan waktu henti yang tidak direncanakan, termasuk kemungkinan skenario, lihat Mitigasi Waktu Henti yang Tidak Direncanakan.

Pengujian failover (pemaksaan failover)

Dengan failover paksa, Anda dapat mensimulasikan skenario pemadaman yang tidak direncanakan saat menjalankan beban kerja produksi Anda dan mengamati waktu henti aplikasi Anda. Anda juga dapat menggunakan failover paksa saat server utama Anda menjadi tidak responsif.

Failover yang dipaksakan menyebabkan server utama offline dan memulai alur kerja failover di mana operasi promosi siaga dilakukan. Setelah server cadangan menyelesaikan proses pemulihan hingga data terakhir yang di-commit, statusnya diubah menjadi server utama. Catatan DNS diperbarui, dan aplikasi Anda bisa tersambung ke server utama yang dipromosikan. Aplikasi Anda dapat terus menulis ke server utama sementara server siaga baru dibuat di latar belakang, yang tidak memengaruhi waktu aktif.

Tabel berikut ini menjelaskan langkah-langkah selama failover paksa:

Step	Deskripsi	Apakah waktu henti aplikasi diharapkan?
1	Server utama berhenti segera setelah menerima permintaan failover.	Yes
2	Aplikasi mengalami downtime saat server utama sedang terhenti.	Yes
3	Sistem pemantauan internal mendeteksi kegagalan dan memulai failover ke server siaga.	Yes
4	Server siaga memasuki mode pemulihan sebelum sepenuhnya dipromosikan sebagai server independen.	Yes
5	Proses failover menunggu pemulihan sistem siaga selesai.	Yes
6	Setelah server aktif, proses memperbarui catatan DNS dengan nama host yang sama tetapi menggunakan alamat IP siaga.	Yes
7	Aplikasi dapat terhubung kembali ke server utama baru dan melanjutkan operasi.	Tidak.
8	Server siaga di zona pilihan didirikan.	Tidak.
9	Server siaga mulai mengambil kembali log (dari Azure Blob) yang terlewatkan selama pembentukannya.	Tidak.
10	Kondisi stabil antara server utama dan server siaga telah tercipta.	Tidak.
11	Proses failover paksa sudah selesai.	Tidak.

Waktu henti aplikasi dimulai setelah langkah 1 dan berlanjut hingga langkah 6 selesai. Langkah-langkah lain berjalan di latar belakang tanpa memengaruhi penulisan dan penerapan aplikasi.

Penting

Proses failover end-to-end mencakup (a) melakukan failover ke server siaga setelah kejadian kegagalan utama dan (b) menetapkan server siaga baru dalam keadaan stabil. Karena aplikasi Anda mengalami waktu henti hingga failover ke cadangan selesai, ukur waktu henti dari perspektif aplikasi/klien Anda daripada hanya proses failover end-to-end secara keseluruhan.

Pertimbangan saat melakukan failover paksa

• Durasi operasi end-to-end secara keseluruhan dapat lebih lama daripada waktu tidak beroperasi yang sebenarnya dialami oleh aplikasi.

  Penting

  Selalu amati waktu henti dari perspektif aplikasi!

• Jangan melakukan failover secara berturut-turut. Tunggu setidaknya 15-20 menit di antara failover, sehingga server siaga baru dapat sepenuhnya dibuat.

• Lakukan failover paksa selama periode aktivitas rendah untuk mengurangi waktu henti.

Praktik terbaik untuk statistik PostgreSQL setelah failover

Setelah failover PostgreSQL, mempertahankan performa database yang optimal melibatkan pemahaman peran pg_statistic dan tabel pg_stat_* . Tabel pg_statistic menyimpan statistik pengoptimal, yang sangat penting untuk perencana kueri. Statistik ini mencakup distribusi data dalam tabel dan tetap utuh setelah failover, memastikan bahwa perencana kueri dapat terus mengoptimalkan eksekusi kueri secara efektif berdasarkan informasi distribusi data historis yang akurat.

Sebaliknya, tabel pg_stat_*, yang merekam statistik aktivitas seperti jumlah pemindaian, tuple yang dibaca, dan pembaruan, akan ter-reset setelah failover. Contoh tabel seperti itu adalah pg_stat_user_tables, yang melacak aktivitas untuk tabel yang ditentukan pengguna. Reset ini secara akurat mencerminkan status operasional primer baru tetapi juga berarti hilangnya metrik aktivitas historis yang dapat menginformasikan proses autovacuum dan efisiensi operasional lainnya.

Mengingat perbedaan ini, jalankan ANALYZE setelah failover PostgreSQL. Tindakan ini memperbarui pg_stat_* tabel, seperti pg_stat_user_tables, dengan statistik aktivitas baru, membantu proses autovacuum dan memastikan bahwa performa database tetap optimal dalam peran barunya. Langkah proaktif ini menjejaki kesenjangan antara mempertahankan statistik pengoptimal penting dan me-refresh metrik aktivitas untuk selaras dengan status database saat ini.

Pengalaman penutupan zona

Zonal: Untuk memulihkan dari kegagalan tingkat zona, Anda dapat melakukan pemulihan ke titik waktu tertentu dengan menggunakan cadangan. Anda dapat memilih titik pemulihan kustom dengan waktu terbaru untuk memulihkan data terbaru. Server fleksibel baru disebarkan di zona lain yang tidak terpengaruh. Waktu yang dibutuhkan untuk melakukan pemulihan bergantung pada cadangan sebelumnya dan volume log transaksi yang perlu dipulihkan.

Untuk informasi selengkapnya tentang pemulihan point-in-time, lihat Pencadangan dan pemulihan di Azure Database for PostgreSQL-Flexible Server.

Redundansi Zona: Server Fleksibel secara otomatis beralih ke server siaga dalam waktu 60-120 detik tanpa kehilangan data.

Konfigurasi tanpa zona ketersediaan

Meskipun tidak disarankan, Anda dapat mengonfigurasi server fleksibel tanpa mengaktifkan ketersediaan tinggi. Untuk server fleksibel yang dikonfigurasi tanpa ketersediaan tinggi, layanan ini menyediakan penyimpanan redundan secara lokal dengan tiga salinan data, pencadangan zona-redundan (di wilayah tempat server didukung), dan ketahanan server bawaan untuk secara otomatis memulai ulang server yang mengalami crash dan memindahkan server ke simpul fisik lain. Konfigurasi ini menawarkan SLA waktu aktif sebesar 99,9%. Selama peristiwa failover yang direncanakan atau tidak direncanakan, jika server tidak berfungsi, layanan mempertahankan ketersediaan server dengan menggunakan prosedur otomatis berikut:

1. Sebuah komputer virtual Linux baru telah disediakan.
2. Penyimpanan dengan file data dipetakan ke komputer virtual baru.
3. Mesin database PostgreSQL dibawa secara online di komputer virtual baru.

Gambar berikut menunjukkan transisi antara VM dan kegagalan penyimpanan.

**

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Jika bencana di seluruh wilayah terjadi, Azure dapat memberikan perlindungan dari bencana geografi regional atau besar dengan pemulihan bencana dengan memanfaatkan wilayah lain. Untuk informasi selengkapnya tentang arsitektur pemulihan bencana Azure, lihat Arsitektur pemulihan bencana Azure ke Azure.

Server fleksibel menyediakan fitur yang melindungi data dan mengurangi waktu henti untuk database penting misi Anda selama peristiwa waktu henti yang direncanakan dan tidak direncanakan. Dibangun di atas infrastruktur Azure yang menawarkan ketahanan dan ketersediaan yang kuat, server fleksibel menawarkan fitur kelangsungan bisnis yang memberikan perlindungan kesalahan, mengatasi persyaratan waktu pemulihan, dan mengurangi paparan kehilangan data. Saat Anda merancang aplikasi Anda, pertimbangkan toleransi terhadap waktu henti - tujuan waktu pemulihan (RTO), dan risiko kehilangan data - tujuan titik pemulihan (RPO). Misalnya, database penting bisnis Anda memerlukan waktu aktif yang lebih ketat daripada database pengujian.

Pemulihan bencana dalam geografi multi-wilayah

Pencadangan dan pemulihan dengan redundansi geografis

Pencadangan dan pemulihan geo-redundan memberi Anda kemampuan untuk memulihkan server Anda di wilayah yang berbeda jika bencana terjadi. Ini juga memberikan setidaknya durabilitas objek cadangan sebesar 99,99999999999999% (16 angka sembilan) selama satu tahun.

Anda hanya dapat mengonfigurasi cadangan geo-redundan saat membuat server. Saat Anda mengonfigurasi server dengan cadangan geo-redundan, data cadangan dan log transaksi disalin ke wilayah yang dipasangkan secara asinkron melalui replikasi penyimpanan.

Untuk informasi selengkapnya tentang pencadangan dan pemulihan geo-redundant, lihat pencadangan dan pemulihan geo-redundant.

Replika Pembacaan

Anda dapat menyebarkan replika baca lintas wilayah untuk melindungi database Anda dari kegagalan tingkat wilayah. Replika baca diperbarui secara asinkron dengan menggunakan teknologi replikasi fisik PostgreSQL, dan replikasi fisiknya dapat tertinggal pada replikasi utama. Tujuan umum dan tingkat komputasi yang dioptimalkan memori mendukung replika baca.

Untuk informasi selengkapnya tentang fitur dan pertimbangan replika baca, lihat Membaca replika.

Deteksi, pemberitahuan, dan manajemen gangguan

Jika Anda mengonfigurasi server dengan cadangan geo-redundan, Anda dapat melakukan pemulihan geografis di wilayah yang dipasangkan. Sebuah server baru telah disiapkan dan dipulihkan ke data terbaru yang tersedia yang disalin ke wilayah ini.

Anda juga dapat menggunakan replika baca lintas wilayah. Jika terjadi kegagalan regional, Anda dapat melakukan operasi pemulihan bencana dengan mempromosikan replika baca Anda menjadi server mandiri yang bisa dibaca-tulis. RPO dapat diperkirakan hingga 5 menit (kemungkinan kehilangan data), kecuali jika kegagalan regional yang parah terjadi, ketika RPO dapat mendekati jeda replikasi pada saat kegagalan.

Untuk informasi selengkapnya tentang mitigasi dan pemulihan waktu henti yang tidak dijadwalkan setelah bencana regional, lihat mitigasi waktu henti yang tidak dijadwalkan.

Konten terkait

• Panduan Azure Database untuk PostgreSQL
• Keandalan di Azure