Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Kelangsungan bisnis di Azure Database for PostgreSQL mengacu pada mekanisme, kebijakan, dan prosedur yang memungkinkan bisnis Anda untuk terus beroperasi dalam menghadapi gangguan, terutama pada infrastruktur komputasinya. Dalam sebagian besar kasus, Azure Database for PostgreSQL menangani peristiwa disruptif yang mungkin terjadi di lingkungan cloud dan menjaga aplikasi dan proses bisnis Anda tetap berjalan. Namun, ada beberapa peristiwa yang tidak dapat ditangani secara otomatis seperti:
- Pengguna secara tidak sengaja menghapus atau memperbarui baris dalam tabel.
- Gempa bumi menyebabkan pemadaman listrik dan menonaktifkan zona ketersediaan atau wilayah untuk sementara waktu.
- Patching database diperlukan untuk memperbaiki masalah bug atau keamanan.
Azure Database for PostgreSQL menyediakan fitur yang melindungi data dan mengurangi downtime untuk database yang kritis bagi misi Anda selama kejadian downtime yang terencana dan tidak terencana. Dibangun di atas infrastruktur Azure yang menawarkan ketahanan dan ketersediaan yang kuat, Azure Database for PostgreSQL memiliki fitur kelangsungan bisnis yang memberikan perlindungan kesalahan lain, mengatasi persyaratan waktu pemulihan, dan mengurangi paparan kehilangan data. Saat Anda merancang aplikasi, Anda sebaiknya mempertimbangkan toleransi terhadap waktu henti (tujuan waktu pemulihan/RTO) dan potensi kehilangan data (tujuan titik pemulihan/RPO). Misalnya, database penting bisnis Anda memerlukan waktu aktif yang lebih ketat daripada database pengujian.
Tabel di bawah ini mengilustrasikan fitur yang ditawarkan Azure Database for PostgreSQL.
| Feature | Deskripsi | Pertimbangan |
|---|---|---|
| Pencadangan otomatis | Instans server fleksibel Azure Database for PostgreSQL secara otomatis melakukan pencadangan harian file database Anda dan terus mencadangkan log transaksi. Cadangan dapat dipertahankan dari 7 hari hingga 35 hari. Anda dapat memulihkan server database Anda ke titik waktu mana pun dalam periode retensi cadangan Anda. RTO bergantung pada ukuran data untuk memulihkan + waktu untuk melakukan pemulihan log. Hal ini dapat memakan waktu hingga 12 jam. Untuk detail selengkapnya, lihat Konsep - Pencadangan dan Pemulihan. | Data cadangan tetap berada di dalam wilayah. |
| Zona redundan dengan ketersediaan tinggi | Instans server fleksibel Azure Database for PostgreSQL dapat disebarkan dengan konfigurasi ketersediaan tinggi (HA) redundan zona di mana server utama dan siaga disebarkan di dua zona ketersediaan yang berbeda dalam suatu wilayah. Konfigurasi HA ini melindungi database Anda dari kegagalan tingkat zona 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. RTO dalam kebanyakan kasus diperkirakan kurang dari 120-an. RPO diperkirakan nol (tidak ada kehilangan data). Untuk informasi selengkapnya, lihat [Konsep - Ketersediaan tinggi]/azure/keandalan/keandalan-postgresql-flexible-server. | Didukung dalam tujuan umum dan tingkat komputasi yang dioptimalkan memori. Ketersediaan tinggi hanya didukung di wilayah tempat beberapa zona tersedia. |
| Ketersediaan Tinggi dalam Zona yang Sama | Instans server fleksibel Azure Database for PostgreSQL dapat disebarkan dengan konfigurasi ketersediaan tinggi (HA) zona yang sama di mana server utama dan siaga disebarkan di zona ketersediaan yang sama di suatu wilayah. Konfigurasi high availability ini melindungi database Anda dari kegagalan tingkat node 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. RTO dalam kebanyakan kasus diperkirakan kurang dari 120-an. RPO diperkirakan nol (tidak ada kehilangan data). Untuk informasi selengkapnya, lihat [Konsep - Ketersediaan tinggi]/azure/keandalan/keandalan-postgresql-flexible-server. | Didukung dalam tujuan umum dan tingkat komputasi yang dioptimalkan memori. |
| Disk yang dikelola premium | File database disimpan dalam penyimpanan yang sangat tahan lama dan andal yang dikelola premium. Redundansi data diberikan dengan tiga salinan replika yang disimpan dalam zona ketersediaan dengan kemampuan pemulihan data otomatis. Untuk informasi selengkapnya, lihat Dokumentasi Disk Terkelola. | Data yang disimpan dalam zona ketersediaan. |
| Pencadangan zona redundan | Cadangan instans server fleksibel Azure Database for PostgreSQL disimpan secara otomatis dan aman di penyimpanan zona redundan dalam suatu wilayah, jika wilayah mendukung zona ketersediaan. Selama kegagalan tingkat zona di mana server Anda disediakan, dan jika server Anda tidak dikonfigurasi dengan redundansi zona, Anda masih dapat memulihkan database Anda menggunakan titik pemulihan terbaru di zona yang berbeda. Untuk informasi selengkapnya, lihat Konsep - Pencadangan dan Pemulihan. | Hanya berlaku di wilayah tempat beberapa zona tersedia. |
| Pencadangan redundan geografis | Cadangan instans server jenis fleksibel Azure Database for PostgreSQL disalin ke wilayah jarak jauh. yang membantu situasi pemulihan bencana jika wilayah server utama tidak berfungsi. | Fitur ini saat ini diaktifkan di wilayah yang dipilih. Dibutuhkan RTO yang lebih lama dan RPO yang lebih tinggi bergantung pada ukuran data yang akan dipulihkan dan jumlah pemulihan yang harus dilakukan. |
| 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 menyebabkan lag pada primer. Untuk informasi selengkapnya, lihat Konsep - Baca Replika. | Didukung dalam tujuan umum dan tingkat komputasi yang dioptimalkan memori. |
Tabel berikut membandingkan RTO dan RPO dalam skenario beban kerja umum :
| Kemampuan | Mudah meledak | SKU untuk Produk (Serbaguna/Optimalisasi Memori) |
|---|---|---|
| Pemulihan Titik Waktu dari cadangan | Titik pemulihan apa pun dalam periode retensi RTO - Bervariasi RPO < 5 Menit |
Titik pemulihan apa pun dalam periode retensi RTO - Bervariasi RPO < 5 Menit |
| Geo-pemulihan dari cadangan yang direplikasi secara geografis | RTO - Bervariasi RPO < 1 j |
RTO - Bervariasi RPO < 1 j |
| Replika Pembacaan | Tidak Berlaku | RTO - Menit* RPO - Biasanya berkisar dari 30 detik hingga 5 Menit* |
| Ketersediaan Tinggi | Tidak Berlaku | RTO < 120 detik RPO = 0 |
Acara waktu henti yang direncanakan
Di bawah ini adalah beberapa skenario pemeliharaan terencana. Peristiwa ini biasanya terjadi hingga beberapa menit waktu henti dan tanpa kehilangan data.
| Skenario | Proses |
|---|---|
| Penskalaan komputasi (Dimulai pengguna) | Selama operasi penskalaan komputasi, titik pemeriksaan aktif diizinkan untuk diselesaikan, koneksi klien dikosongkan, setiap transaksi yang tidak dilakukan dibatalkan, penyimpanan dilepaskan, dan kemudian dimatikan. Instans server fleksibel Azure Database for PostgreSQL baru dengan nama server database yang sama disediakan dengan konfigurasi komputasi berskala. Penyimpanan kemudian dilampirkan ke server baru dan database dimulai yang melakukan pemulihan, jika perlu, sebelum menerima koneksi klien. |
| Menskalakan penyimpanan (Dimulai pengguna) | Ketika operasi penyimpanan peningkatan skala dimulai, titik pemeriksaan aktif diizinkan untuk diselesaikan, koneksi klien dikosongkan, dan setiap transaksi yang tidak dilakukan dibatalkan. Setelah itu server dimatikan. Penyimpanan diskalakan ke ukuran yang diinginkan dan kemudian dilampirkan ke server baru. Pemulihan dilakukan jika diperlukan sebelum menerima koneksi klien. Perhatikan bahwa penurunan skala ukuran penyimpanan tidak didukung. |
| Penyebaran perangkat lunak baru (dimulai Azure) | Peluncuran fitur baru atau perbaikan bug secara otomatis terjadi sebagai bagian dari pemeliharaan terencana layanan dan Anda dapat menjadwalkan kapan aktivitas tersebut terjadi. Untuk informasi selengkapnya, periksa portal Anda. |
| Peningkatan versi minor (dimulai Azure) | Azure Database for PostgreSQL secara otomatis melakukan patching server database ke versi minor yang ditentukan oleh Azure. Ini terjadi sebagai bagian dari pemeliharaan terencana layanan. Server database secara otomatis dimulai ulang dengan versi minor baru. Untuk informasi selengkapnya, lihat dokumentasi. Anda juga dapat memeriksa portal Anda. |
Ketika instans server fleksibel Azure Database for PostgreSQL dikonfigurasi dengan ketersediaan tinggi, layanan melakukan penskalaan dan operasi pemeliharaan di server siaga terlebih dahulu. Untuk informasi selengkapnya, lihat [Konsep - Ketersediaan tinggi]/azure/keandalan/keandalan-postgresql-flexible-server.
Mitigasi waktu henti 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, Azure Database for PostgreSQL membantu mengurangi waktu henti dengan melakukan operasi pemulihan secara otomatis tanpa memerlukan intervensi manusia.
Meskipun kami terus berusaha untuk memberikan ketersediaan tinggi, ada kalanya Azure Database for PostgreSQL melakukan pemadaman yang menyebabkan tidak tersedianya database dan dengan demikian berdampak pada aplikasi Anda. Ketika pemantauan layanan kami mendeteksi masalah yang menyebabkan kesalahan konektivitas, kegagalan, atau masalah performa yang luas, layanan secara otomatis menyatakan pemadaman agar Anda mendapatkan informasi.
Gangguan Layanan
Jika terjadi pemadaman instans server fleksibel Azure Database for PostgreSQL, Anda dapat melihat detail selengkapnya yang terkait dengan pemadaman di tempat-tempat berikut:
- Banner portal Microsoft Azure: Jika langganan Anda diidentifikasi terpengaruh, akan ada pemberitahuan pemadaman dari Masalah Layanan di Pemberitahuan portal Microsoft Azure Anda.
- Bantuan + dukungan atau Dukungan + pemecahan masalah: Saat Anda membuat tiket dukungan dari Bantuan + dukungan atau Dukungan + pemecahan masalah, akan ada informasi tentang masalah apa pun yang memengaruhi sumber daya Anda. Pilih Tampilkan detail pemadaman untuk informasi selengkapnya dan ringkasan dampak. Juga akan ada pemberitahuan di halaman Permintaan dukungan baru.
- Bantuan Layanan: Halaman Service Health di portal Microsoft Azure berisi informasi tentang status pusat data Azure secara global. Cari "kesehatan layanan" di bilah pencarian di portal Azure, lalu lihat Masalah layanan dalam kategori Peristiwa aktif. Anda juga dapat melihat kesehatan setiap sumber daya di halaman Kesehatan sumber daya untuk sumber daya apa pun dalam menu Bantuan. Cuplikan layar sampel halaman Service Health mengikuti, dengan informasi tentang masalah layanan aktif di Asia Tenggara.
- Pemberitahuan email: Jika Anda telah menyiapkan pemberitahuan, pemberitahuan email akan tiba saat pemadaman layanan memengaruhi langganan dan sumber daya Anda. Email tiba dari "azure-noreply@microsoft.com". Isi email dimulai dengan "Pemberitahuan log aktivitas ... dipicu oleh masalah layanan untuk langganan Azure...". Untuk informasi selengkapnya tentang pemberitahuan kesehatan layanan, lihat Menerima pemberitahuan log aktivitas di pemberitahuan layanan Azure menggunakan portal Microsoft Azure.
Penting
Seperti namanya, ruang tabel sementara di PostgreSQL digunakan untuk objek sementara, serta operasi database internal lainnya, seperti pengurutan. Oleh karena itu, kami tidak menyarankan untuk membuat objek skema pengguna di ruang tabel sementara, karena kami tidak menjamin durabilitas objek tersebut setelah Server dimulai ulang, failover HA, dll.
Waktu henti yang tidak direncanakan: skenario kegagalan dan pemulihan layanan
Di bawah ini adalah beberapa skenario kegagalan yang tidak direncanakan dan proses pemulihan.
| Skenario |
Proses pemulihan [Server dikonfigurasi tanpa HA zona-redundansi] |
Proses pemulihan [Server dikonfigurasi dengan HA Zona-redundansi] |
|---|---|---|
| Kegagalan server database | Jika server database mati, Azure akan mencoba memulai ulang server database. Jika proses ini gagal, server database akan dimulai ulang pada node fisik lain. Waktu pemulihan (RTO) tergantung pada berbagai faktor termasuk aktivitas pada saat kesalahan, seperti transaksi besar, dan volume pemulihan yang akan dilakukan selama proses startup server database. Aplikasi yang menggunakan database PostgreSQL perlu dibangun dengan cara yang mereka deteksi dan coba lagi koneksi yang dijatuhkan dan transaksi yang gagal. |
Jika kegagalan server database terdeteksi, server melakukan failover server siaga, sehingga mengurangi waktu henti. Untuk informasi selengkapnya, lihat [halaman konsep HA]/azure/keandalan/keandalan-postgresql-flexible-server. RTO diperkirakan 60-120-an, tanpa kehilangan data. |
| Kegagalan penyimpanan | Aplikasi tidak melihat dampak apa pun untuk masalah terkait penyimpanan seperti kegagalan disk atau kerusakan blok fisik. Karena data disimpan dalam tiga salinan, salinan data dilayani oleh penyimpanan yang masih ada. Blok data yang rusak secara otomatis diperbaiki dan salinan data baru secara otomatis dibuat. | Untuk kesalahan langka dan tidak dapat dipulihkan seperti seluruh penyimpanan tidak dapat diakses, instans server fleksibel Azure Database for PostgreSQL gagal ke replika siaga untuk mengurangi waktu henti. Untuk informasi selengkapnya, lihat [halaman konsep HA]/azure/keandalan/keandalan-postgresql-flexible-server. |
| Kesalahan logis atau pengguna | Untuk memulihkan dari kesalahan pengguna, seperti tabel yang terhapus secara tidak sengaja atau data yang diperbarui secara keliru, Anda harus melakukan pemulihan titik waktu (PITR). Saat melakukan operasi pemulihan, Anda menentukan titik pemulihan kustom, yang merupakan waktu tepat sebelum kesalahan terjadi. Jika Anda hanya ingin memulihkan subset database atau tabel tertentu daripada semua database di server database, Anda dapat memulihkan server database dalam instans baru, mengekspor tabel melalui pg_dump, lalu menggunakan pg_restore untuk memulihkan tabel tersebut ke database Anda. |
Kesalahan pengguna ini tidak dilindungi dengan ketersediaan tinggi karena semua perubahan direplikasi ke replika siaga secara sinkron. Anda harus melakukan pemulihan titik waktu untuk memulihkan dari kesalahan tersebut. |
| Kegagalan zona ketersediaan | Untuk memulihkan dari kegagalan tingkat zona, Anda dapat melakukan pemulihan titik waktu menggunakan cadangan dan memilih titik pemulihan kustom dengan waktu terbaru untuk memulihkan data terbaru. Instans server fleksibel Azure Database for PostgreSQL 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. | Instans server fleksibel Azure Database for PostgreSQL secara otomatis beralih ke server siaga dalam waktu 60-120 detik tanpa kehilangan data. Untuk informasi selengkapnya, lihat [halaman konsep HA]/azure/keandalan/keandalan-postgresql-flexible-server. |
| Kegagalan wilayah | Jika server Anda dikonfigurasi dengan cadangan redundan geografis, Anda dapat melakukan pemulihan geo di wilayah yang berpasangan. Server baru akan 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 diharapkan hingga 5 menit (kehilangan data mungkin terjadi) kecuali jika terjadi kegagalan regional yang parah di mana RPO dapat mendekati keterlambatan replikasi pada saat kegagalan. |
Proses yang sama. |
Mengonfigurasi database Anda setelah pemulihan dari kegagalan regional
- Jika Anda menggunakan pemulihan geografis atau geo-replika untuk memulihkan dari pemadaman, Anda harus memastikan bahwa konektivitas ke server baru dikonfigurasi dengan benar sehingga fungsi aplikasi normal dapat dilanjutkan. Anda dapat mengikuti tugas Pasca-pemulihan.
- Jika sebelumnya Anda telah menyiapkan pengaturan diagnostik di server asli, pastikan untuk melakukan hal yang sama di server target jika perlu seperti yang dijelaskan dalam Mengonfigurasi dan Mengakses Log di Azure Database for PostgreSQL.
- Menyiapkan pemberitahuan telemetri, Anda perlu memastikan pengaturan aturan pemberitahuan yang ada diperbarui untuk memetakan ke server baru. Untuk informasi selengkapnya tentang aturan pemberitahuan, lihat Menggunakan portal Microsoft Azure untuk menyiapkan pemberitahuan tentang metrik untuk Azure Database for PostgreSQL.
Penting
Server yang dihapus dapat dipulihkan. Jika Anda menghapus server, Anda dapat mengikuti panduan kami Memulihkan database Azure yang dihilangkan untuk dipulihkan. Gunakan kunci sumber daya Azure untuk membantu mencegah penghapusan server secara tidak disengaja.