Ketersediaan tinggi (Keandalan) di Azure Database for PostgreSQL - Server Fleksibel
BERLAKU UNTUK: 
Azure Database for PostgreSQL - Server Fleksibel
Artikel ini menjelaskan ketersediaan tinggi di Azure Database for PostgreSQL - Server Fleksibel, 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 - Server Fleksibel menawarkan dukungan 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 jika terjadi kegagalan. Model ini juga 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 Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Azure Database for PostgreSQL - Server Fleksibel mendukung model zona-redundan dan zonal untuk konfigurasi ketersediaan tinggi. Kedua konfigurasi ketersediaan tinggi memungkinkan kemampuan failover otomatis dengan kehilangan data nol selama peristiwa yang direncanakan dan 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 mengharuskan Anda untuk 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.
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, alias WAL) disimpan di penyimpanan redundan lokal (LRS) di setiap zona ketersediaan, secara otomatis menyimpan tiga salinan data. Konfigurasi zona-redundan menyediakan isolasi fisik seluruh tumpukan antara server utama dan siaga.
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 terjadi gangguan pada server utama, server secara otomatis melakukan failover ke replika siaga.
Catatan
Model penyebaran zonal dan zona-redundan secara arsitektur berprilaku sama. Berbagai diskusi di bagian berikut berlaku untuk keduanya kecuali dipanggil sebaliknya.
Prasyarat
Redundansi zona:
Opsi zona-redundansi hanya tersedia di wilayah yang mendukung zona ketersediaan.
Redundansi zona tidak didukung untuk:
- Azure Database for PostgreSQL – SKU Server Tunggal.
- Tingkat komputasi yang dapat meledak.
- Wilayah dengan ketersediaan zona tunggal.
Zonal:
- Opsi penyebaran zona tersedia di semua wilayah Azure tempat Anda dapat menyebarkan Server Fleksibel.
Fitur ketersediaan tinggi
Replika siaga disebarkan dalam konfigurasi VM yang sama - termasuk vCore, penyimpanan, pengaturan jaringan - sebagai server utama.
Anda dapat menambahkan dukungan zona ketersediaan untuk server database yang sudah ada.
Anda dapat menghapus replika siaga dengan menonaktifkan ketersediaan tinggi.
Anda dapat memilih zona ketersediaan untuk server database utama dan siaga Anda untuk ketersediaan zona redundan.
Operasi seperti berhenti, memulai, dan memulai ulang dilakukan pada server database primer dan siaga pada saat yang bersamaan.
Dalam model zona-redundan dan zonal, pencadangan otomatis dilakukan secara berkala dari server database utama. Pada saat yang sama, log transaksi terus diarsipkan dalam penyimpanan cadangan dari replika siaga. 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.
Kemampuan untuk memulai ulang server guna menemukan perubahan parameter server statis.
Aktivitas pemeliharaan berkala seperti peningkatan versi minor terjadi pada siaga terlebih dahulu dan, untuk mengurangi waktu henti, siaga dipromosikan ke primer sehingga beban kerja dapat tetap aktif, sementara tugas pemeliharaan diterapkan pada simpul yang tersisa.
Memantau Kesehatan Ketersediaan Tinggi
Pemantauan status kesehatan Ketersediaan Tinggi (HA) di Azure Database for PostgreSQL - Server Fleksibel memberikan gambaran umum berkelanjutan tentang kesehatan dan kesiapan instans berkemampuan HA. Fitur pemantauan ini memanfaatkan kerangka kerja Pemeriksaan Kesehatan Sumber Daya (RHC) Azure untuk mendeteksi dan memperingatkan masalah apa pun yang dapat 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.
Pelanggan dapat menggunakan 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.
- Konfigurasikan pemberitahuan untuk pemberitahuan tepat waktu pada setiap perubahan status KETERSEDIAAN TINGGI, memastikan tindakan segera 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 artikel utama pemantauan status kesehatan Ketersediaan Tinggi (HA) untuk Azure Database for PostgreSQL - Server Fleksibel.
Batasan ketersediaan tinggi
Karena replikasi sinkron ke server siaga, terutama dengan konfigurasi zona-redundan, aplikasi dapat mengalami latensi tulis dan penerapan yang ditinggikan.
Replika siaga tidak dapat digunakan untuk membaca kueri.
Tergantung pada beban kerja dan aktivitas di server utama, proses failover mungkin memakan waktu lebih dari 120 detik karena pemulihan yang terlibat di replika siaga sebelum dapat dipromosikan.
Server siaga biasanya memulihkan file WAL pada 40 MB/dtk. Jika beban kerja Anda melebihi batas ini, Anda dapat menemukan waktu yang lama agar pemulihan selesai baik selama failover atau setelah membuat siaga baru.
Mengonfigurasi zona ketersediaan menginduksi beberapa latensi untuk menulis dan berkomitmen, meskipun tidak menghasilkan dampak apa pun pada kueri baca. Dampak kinerja bervariasi tergantung pada beban kerja Anda. Sebagai pedoman umum, dampak menulis dan menerapkan bisa sekitar 20-30% dampak.
Memulai ulang server database utama juga memulai ulang replika siaga.
Mengonfigurasi siaga tambahan tidak didukung.
Mengonfigurasi tugas manajemen yang dimulai pelanggan tidak dapat dijadwalkan selama jendela pemeliharaan terkelola.
Peristiwa yang direncanakan seperti komputasi skala dan penyimpanan skala terjadi pada siaga terlebih dahulu dan kemudian di server utama. Saat ini, server tidak melakukan failover untuk operasi yang direncanakan ini.
Jika decoding logis atau replikasi logis dikonfigurasi dengan Server Fleksibel yang dikonfigurasi ketersediaan, jika terjadi failover ke server siaga, slot replikasi logis tidak disalin ke server siaga. Untuk mempertahankan slot replikasi logis dan memastikan konsistensi data setelah failover, disarankan untuk menggunakan ekstensi Slot Failover PG. Untuk informasi selengkapnya tentang cara mengaktifkan ekstensi ini, silakan lihat dokumentasi.
Mengonfigurasi zona ketersediaan antara akses privat (VNET) dan publik dengan titik akhir privat tidak didukung. Anda harus mengonfigurasi zona ketersediaan dalam VNET (terbenam di seluruh zona ketersediaan dalam suatu wilayah) atau akses publik dengan titik akhir privat.
Zona ketersediaan hanya dikonfigurasi dalam satu wilayah. Zona ketersediaan tidak dapat dikonfigurasi di seluruh wilayah.
SLA
Model zonal menawarkan waktu aktif SLA sebesar 99,95%.
Model redundansi zona menawarkan SLA uptime 99,99%.
Membuat Azure Database for PostgreSQL - Server Fleksibel dengan zona ketersediaan diaktifkan
Untuk mempelajari cara membuat Azure Database for PostgreSQL - Server Fleksibel untuk ketersediaan tinggi dengan zona ketersediaan, lihat Mulai Cepat: Membuat Azure Database for PostgreSQL - Server Fleksibel di portal Azure.
Penyebaran ulang dan migrasi 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
Penulisan dan penerapan yang dipicu transaksi aplikasi pertama kali dicatat ke WAL di server utama. Ini kemudian dialirkan ke server siaga menggunakan protokol streaming Postgres. Setelah log disimpan pada penyimpanan server siaga, server utama diakui untuk penyelesaian tulis. Hanya kemudian aplikasi dikonfirmasi penerapan transaksinya. Perjalanan pulang pergi tambahan ini menambahkan lebih banyak latensi ke aplikasi Anda. Persentase dampak bergantung pada aplikasi. Proses pengakuan ini tidak menunggu log diterapkan ke server siaga. Server siaga secara permanen dalam mode pemulihan hingga dipromosikan.
Pemeriksaan kondisi
Pemantauan kesehatan server yang fleksibel secara berkala memeriksa kesehatan primer dan siaga. Setelah beberapa ping, jika pemantauan kesehatan mendeteksi bahwa server utama tidak dapat dijangkau, layanan kemudian memulai failover otomatis ke server siaga. Algoritma pemantauan kesehatan didasarkan pada beberapa titik data untuk menghindari situasi positif palsu.
Mode failover
Server fleksibel mendukung dua mode failover, Failover terencana dan Failover yang tidak direncanakan. Dalam kedua mode, setelah replikasi diputus, server siaga menjalankan pemulihan sebelum dipromosikan sebagai primer dan terbuka untuk baca/tulis. Dengan entri DNS otomatis yang diperbarui dengan titik akhir server utama baru, aplikasi dapat terhubung ke server menggunakan titik akhir yang sama. Server siaga baru dibuat di latar belakang, sehingga aplikasi Anda dapat mempertahankan konektivitas.
Status ketersediaan tinggi
Kesehatan server utama dan siaga terus dipantau, dan tindakan yang sesuai diambil untuk memulihkan masalah, termasuk memicu failover ke server siaga. Tabel di bawah ini mencantumkan kemungkinan status ketersediaan tinggi:
| Keadaan | Keterangan |
|---|---|
| Initializing | Dalam proses membuat server siaga baru. |
| Mereplikasi Data | Setelah siaga dibuat, siaga akan mengejar primer. |
| Sehat | Replikasi dalam status stabil dan sehat. |
| FailOver | Server database sedang dalam proses di-failover ke server siaga. |
| Menghapus Siaga | Dalam proses menghapus server siaga. |
| Tidak Diaktifkan | Ketersediaan tinggi tidak diaktifkan. |
Catatan
Anda dapat mengaktifkan ketersediaan tinggi selama pembuatan server atau di lain waktu juga. Jika Anda mengaktifkan atau menonaktifkan ketersediaan tinggi selama tahap pasca-buat, disarankan untuk beroperasi saat aktivitas server utama rendah.
Operasi berstatus stabil
Aplikasi klien PostgreSQL tersambung ke server utama menggunakan nama server DB. Pembacaan aplikasi dilayani langsung dari server utama. Pada saat yang sama, penerapan dan penulisan dikonfirmasi ke aplikasi hanya setelah data log disimpan 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 kesehatan ketersediaan tinggi di portal.
- Klien tersambung ke server fleksibel dan menjalankan operasi tulis.
- Perubahan direplikasi ke situs siaga.
- Primer menerima pengakuan.
- Proses tulis/penerapan dikonfirmasi.
Pemulihan point-in-time server ketersediaan tinggi
Untuk server fleksibel yang dikonfigurasi dengan ketersediaan tinggi, data log direplikasi 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 siaga untuk memulihkan dari kesalahan logis tersebut. Untuk memulihkan dari kesalahan tersebut, Anda harus melakukan pemulihan titik waktu 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:
Anda dapat menggunakan 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 point-in-time server fleksibel, lihat Pemulihan titik waktu server fleksibel.
Dukungan Failover
Kegagalan terencana
Peristiwa waktu henti yang direncanakan mencakup pembaruan perangkat lunak berkala dan peningkatan versi minor yang terjadwal dari Azure. Anda juga dapat menggunakan failover yang direncanakan untuk mengembalikan server utama ke zona ketersediaan pilihan. Jika dikonfigurasikan dalam ketersediaan tinggi, operasi ini akan diterapkan terlebih dahulu ke server replika siaga, sementara aplikasi tetap mengakses server utama. Setelah replika siaga diperbarui, koneksi server utama dikosongkan, dan failover dipicu, yang mengaktifkan replika siaga menjadi yang utama dengan nama server database yang sama. Aplikasi klien harus terhubung kembali dengan nama server database yang sama ke server utama baru dan dapat melanjutkan operasi mereka. Server siaga baru dibuat dalam zona yang sama dengan server utama yang lama.
Untuk operasi lain yang dimulai pengguna seperti komputasi skala atau penyimpanan skala, perubahan diterapkan pada siaga terlebih dahulu, diikuti oleh primer. Saat ini, layanan tidak gagal ke siaga, dan karenanya sementara operasi skala dilakukan di server utama, aplikasi mengalami waktu henti singkat.
Anda juga dapat menggunakan fitur ini untuk failover ke server siaga dengan mengurangi waktu henti. Misalnya, primer 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.
Saat menjalankan fitur ini, server siaga pertama-tama disiapkan untuk memastikannya terjebak dengan transaksi terbaru, memungkinkan aplikasi untuk terus melakukan baca/tulis. Siaga kemudian dipromosikan, dan koneksi ke primer terputus. Aplikasi Anda dapat terus menulis ke server utama sementara server siaga baru didirikan di latar belakang. Berikut ini adalah langkah-langkah yang terlibat dengan failover yang direncanakan:
| Langkah | Keterangan | Downtime aplikasi diharapkan? |
|---|---|---|
| 1 | Tunggu hingga server siaga tertangkap dengan server utama. | No |
| 2 | Sistem pemantauan internal memulai alur kerja failover. | No |
| 3 | Penulisan aplikasi diblokir ketika server siaga dekat dengan nomor urutan log utama (LSN). | Ya |
| 4 | Server siaga dipromosikan menjadi server independen. | Ya |
| 5 | Catatan DNS diperbarui dengan alamat IP server siaga baru. | Ya |
| 6 | Aplikasi untuk menyambungkan kembali dan melanjutkan baca/tulisnya dengan primer baru. | No |
| 7 | Server siaga baru di zona lain didirikan. | No |
| 8 | Server siaga mulai memulihkan log (dari Azure Blob) yang terlewatkan selama pendiriannya. | No |
| 9 | Status stabil antara server utama dan siaga dibuat. | No |
| 10 | Proses failover yang direncanakan sudah selesai. | No |
Waktu henti aplikasi dimulai pada langkah #3 dan dapat melanjutkan operasi pasca 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 di mana aktivitas pada database diperkirakan rendah. Tugas pemeliharaan Azure seperti patching atau peningkatan versi minor akan dilakukan pada rentang waktu tersebut. Jika Anda tidak memilih jendela kustom, sistem yang dialokasikan jendela 1 jam antara pukul 23.00 - 07.00 waktu setempat dipilih untuk server Anda. Aktivitas pemeliharaan yang dimulai 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 direncanakan dapat terjadi sebagai akibat dari gangguan yang tidak terduga seperti kesalahan perangkat keras yang mendasarinya, masalah jaringan, dan bug perangkat lunak. Jika server database yang dikonfigurasi dengan ketersediaan tinggi turun secara tiba-tiba, maka replika siaga diaktifkan dan klien dapat melanjutkan operasi mereka. Jika tidak dikonfigurasi dengan ketersediaan tinggi (HA), maka jika upaya restart gagal, server database baru secara otomatis diprovisikan. 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 (failover paksa)
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 paksa menurunkan server utama dan memulai alur kerja failover tempat operasi promosi siaga dilakukan. Setelah siaga menyelesaikan proses pemulihan hingga data terakhir yang diterapkan, siaga dipromosikan menjadi server utama. Catatan DNS diperbarui, dan aplikasi Anda bisa tersambung ke server utama yang dipromosikan. Aplikasi Anda dapat terus menulis ke primer sementara server siaga baru dibuat di latar belakang, yang tidak memengaruhi waktu aktif.
Berikut ini adalah langkah-langkah selama failover paksa:
| Langkah | Keterangan | Downtime aplikasi diharapkan? |
|---|---|---|
| 1 | Server utama dihentikan segera setelah menerima permintaan failover. | Ya |
| 2 | Aplikasi mengalami downtime saat server utama sedang terhenti. | Ya |
| 3 | Sistem pemantauan internal mendeteksi kegagalan dan memulai failover ke server siaga. | Ya |
| 4 | Server siaga memasuki mode pemulihan sebelum sepenuhnya dipromosikan sebagai server independen. | Ya |
| 5 | Proses failover menunggu pemulihan siaga selesai. | Ya |
| 6 | Setelah server aktif, catatan DNS diperbarui dengan nama host yang sama tetapi menggunakan alamat IP siaga. | Ya |
| 7 | Aplikasi dapat terhubung kembali ke server utama baru dan melanjutkan operasi. | No |
| 8 | Server siaga di zona pilihan didirikan. | No |
| 9 | Server siaga mulai memulihkan log (dari Azure Blob) yang terlewatkan selama pendiriannya. | No |
| 10 | Status stabil antara server utama dan siaga dibuat. | No |
| 11 | Proses failover paksa sudah selesai. | No |
Waktu henti aplikasi diperkirakan akan dimulai setelah langkah #1 dan berlanjut sampai langkah #6 selesai. Langkah-langkah lainnya terjadi di latar belakang tanpa memengaruhi penulisan dan penerapan aplikasi.
Penting
Proses failover end-to-end mencakup (a) failover ke server siaga setelah kegagalan utama dan (b) membuat server siaga baru dalam keadaan stabil. Karena aplikasi Anda mengalami waktu henti hingga failover ke siaga selesai, harap ukur waktu henti dari perspektif aplikasi/klien Anda alih-alih proses failover end-to-end secara keseluruhan.
Pertimbangan saat melakukan failover paksa
Keseluruhan waktu operasi end-to-end dapat dilihat lebih lama dari waktu henti aktual yang dialami oleh aplikasi.
Penting
Selalu amati waktu henti dari perspektif aplikasi!
Jangan langsung melakukan failover back-to-back. Tunggu setidaknya 15-20 menit di antara failover, memungkinkan server siaga baru sepenuhnya dibuat.
Disarankan agar Anda melakukan failover paksa selama periode aktivitas rendah untuk mengurangi waktu henti.
Praktik terbaik untuk statistik PostgreSQL setelah failover
Setelah failover PostgreSQL, mekanisme utama untuk mempertahankan performa database yang optimal melibatkan pemahaman peran pg_statistic dan tabel pg_stat_* yang berbeda. Tabel ini pg_statistic menampung 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, pg_stat_* tabel, yang merekam statistik aktivitas seperti jumlah pemindaian, tuple yang dibaca, dan pembaruan, diatur ulang setelah failover. Contoh tabel seperti itu adalah pg_stat_user_tables, yang melacak aktivitas untuk tabel yang ditentukan pengguna. Reset ini dirancang untuk 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, praktik terbaik setelah failover PostgreSQL adalah menjalankan ANALYZE. 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 zona tidak berfungsi
Zonal: Untuk memulihkan dari kegagalan tingkat zona, Anda dapat melakukan pemulihan titik waktu 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 diambil untuk memulihkan bergantung pada cadangan sebelumnya dan volume log transaksi untuk pulih.
Untuk informasi selengkapnya tentang pemulihan point-in-time, lihat Pencadangan dan pemulihan di Azure Database for PostgreSQL-Flexible Server.
Zona-redundan: Server fleksibel secara otomatis gagal ke server siaga dalam waktu 60-120 detik dengan tidak ada 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 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. Waktu aktif SLA sebesar 99,9% ditawarkan dalam konfigurasi ini. Selama peristiwa failover yang direncanakan atau tidak direncanakan, jika server tidak berfungsi, layanan mempertahankan ketersediaan server menggunakan prosedur otomatis berikut:
- Komputasi baru komputer virtual Linux tersedia.
- Penyimpanan dengan file data dipetakan ke komputer virtual baru.
- Mesin database PostgreSQL dibawa secara online di komputer virtual baru.
Gambar di bawah ini menunjukkan transisi antara VM dan kegagalan penyimpanan.
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Dalam kasus bencana di seluruh wilayah, 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 merancang aplikasi, Anda harus mempertimbangkan toleransi waktu henti - tujuan waktu pemulihan (RTO), dan paparan 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 geo-redundan
Pencadangan dan pemulihan geo-redundan memberikan kemampuan untuk memulihkan server Anda di wilayah yang berbeda jika terjadi bencana. Ini juga memberikan setidaknya durabilitas objek cadangan sebesar 99,99999999999999% (16 angka sembilan) selama satu tahun.
Cadangan Geo-redundan hanya dapat dikonfigurasi pada saat pembuatan server. Ketika server dikonfigurasi 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-redundan, lihat pencadangan dan pemulihan geo-redundan.
Replika baca
Replika baca lintas wilayah dapat disebarkan untuk melindungi database Anda dari kegagalan tingkat wilayah. Replika baca diperbarui secara asinkron menggunakan teknologi replikasi fisik PostgreSQL, dan dapat menunda yang utama. Replika baca didukung dalam tujuan umum dan tingkat komputasi memori yang dioptimalkan.
Untuk informasi selengkapnya tentang fitur dan pertimbangan replika baca, lihat Membaca replika.
Deteksi, pemberitahuan, dan manajemen pemadaman
Jika server Anda dikonfigurasi dengan cadangan geo-redundan, Anda dapat melakukan pemulihan geo di wilayah yang dipasangkan. Server baru disediakan dan dipulihkan ke data terakhir yang tersedia yang disalin ke wilayah ini.
Anda juga dapat menggunakan replika baca lintas wilayah. Jika terjadi kegagalan wilayah, Anda dapat melakukan operasi pemulihan bencana dengan mempromosikan replika baca Anda menjadi server yang dapat dibaca mandiri. RPO diperkirakan hingga 5 menit (kehilangan data mungkin terjadi) kecuali jika terjadi kegagalan regional yang parah 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 dienkripsi.