Keandalan di Azure Database for PostgreSQL

Azure Database for PostgreSQL adalah layanan database terkelola penuh yang dirancang untuk memberi Anda kontrol dan fleksibilitas terperinci atas fungsi manajemen database dan pengaturan konfigurasi. Layanan ini menyediakan ketersediaan tinggi dan kemampuan pemulihan bencana berdasarkan kebutuhan Anda.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat Azure Database for PostgreSQL tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Azure Database for PostgreSQL.

Rekomendasi penyebaran produksi

Untuk mempelajari tentang cara menyebarkan Azure Database for PostgreSQL untuk mendukung persyaratan keandalan solusi Anda, dan bagaimana keandalan memengaruhi aspek arsitektur Anda lainnya, lihat Praktik terbaik arsitektur untuk Azure Database for PostgreSQL di Azure Well-Architected Framework.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Saat Anda bekerja dengan Azure Database for PostgreSQL, Anda menyebarkan server, yang mewakili sumber daya komputasi dan penyimpanan yang diperlukan untuk mendukung server database Anda. Anda menyebarkan satu atau beberapa database ke server.

Server dapat disebarkan di beberapa tingkat komputasi: Burstable, General Purpose, dan Memory Optimized, yang masing-masing dioptimalkan untuk berbagai jenis beban kerja. Di beberapa wilayah Azure, Anda dapat menyebarkan server dengan Azure Confidential Computing.

Untuk informasi selengkapnya tentang arsitektur layanan umum dan model penyebaran, lihat Apa itu Azure Database for PostgreSQL?.

Arsitektur fisik

• Pemisahan komputasi dan penyimpanan: Azure Database for PostgreSQL menggunakan arsitektur pemisahan komputasi dan penyimpanan untuk mendukung ketersediaan tinggi. Mesin basis data beroperasi pada mesin virtual Linux, sementara file data disimpan di penyimpanan Azure, yang mempertahankan tiga salinan sinkron yang berlebihan secara lokal dari file basis data untuk memastikan durabilitas data.

• Ketersediaan tinggi: Anda dapat secara opsional mengaktifkan konfigurasi ketersediaan tinggi di server Anda. Saat Anda mengaktifkan konfigurasi ketersediaan tinggi, layanan menyediakan dan memelihara server siaga yang hangat. Perubahan data pada server utama direplikasi secara sinkron ke server siaga untuk memastikan tidak ada kehilangan data selama kegagalan server utama.

  Arsitektur memisahkan lapisan komputasi dari lapisan penyimpanan, memungkinkan layanan untuk menangani berbagai jenis kegagalan dengan tepat. Untuk ketahanan yang lebih tinggi, Anda dapat menyebarkan server di seluruh zona ketersediaan.

  

  Server siaga disebarkan dalam konfigurasi VM yang sama dengan server utama, termasuk pengaturan vCore, penyimpanan, dan jaringan.

  Anda dapat beralih antar server dengan melakukan failover. Ada dua jenis failover: failover paksa, yang digunakan ketika server utama gagal, dan failover yang direncanakan, yang digunakan selama beberapa operasi pemeliharaan dan dalam skenario lain di mana Anda perlu meminimalkan waktu henti aplikasi selama failover.

  Operasi seperti berhenti, memulai, dan memulai ulang dilakukan pada server database primer dan siaga pada saat yang bersamaan. 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.

  Untuk informasi selengkapnya, lihat Ketersediaan tinggi di Azure Database for PostgreSQL.

• Backup: Azure Database for PostgreSQL secara otomatis membuat cadangan server. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Aplikasi Anda harus menangani kesalahan konektivitas sementara yang dapat terjadi selama pemeliharaan, operasi penskalaan, atau gangguan jaringan. Ikuti rekomendasi berikut:

• Ketika aplikasi Anda mengalami kesalahan sementara, coba lagi operasi dengan menggunakan backoff eksponensial. Tingkatkan penundaan antara percobaan ulang dan batasi jumlah upaya. Jika operasi masih gagal setelah percobaan ulang maksimum, perlakukan sebagai kegagalan.
• Jika memungkinkan, gunakan pustaka klien (juga disebut driver) yang secara otomatis menangani percobaan ulang.
• Kesalahan sementara yang terjadi selama operasi tulis memerlukan pertimbangan yang lebih hati-hati. Pertimbangkan untuk membuat operasi tulis Anda idempoten, sehingga dapat dieksekusi dengan aman beberapa kali.

Untuk informasi selengkapnya, lihat Menangani kesalahan konektivitas sementara di Azure Database for PostgreSQL.

Ketahanan terhadap kegagalan zona ketersediaan

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

Anda dapat memilih jenis dukungan zona ketersediaan Anda melalui konfigurasi ketersediaan tinggi . Mengaktifkan ketersediaan tinggi akan menjalankan server siaga yang ditempatkan bersama server utama Anda. Model ketersediaan tinggi ini membantu memastikan bahwa data yang diterapkan tidak pernah hilang selama kegagalan. Model penyebaran ketersediaan tinggi mana pun yang digunakan server Anda, data diterapkan secara sinkron ke server utama dan siaga. Jika gangguan terjadi pada server utama, server secara otomatis beralih ke server siaga.

File data dan log write-ahead (WAL) disimpan pada disk terkelola premium di setiap zona ketersediaan, dengan penyimpanan redundan lokal (LRS) yang secara otomatis menyimpan tiga salinan data di setiap zona.

Azure Database for PostgreSQL mendukung dua jenis konfigurasi zona ketersediaan saat Anda menggunakan ketersediaan tinggi:

• Ketersediaan tinggi redundansi zona: Redundansi zona memberikan tingkat ketahanan tertinggi dengan menempatkan server utama di satu zona ketersediaan dan server siaga di zona ketersediaan lainnya. Server siaga menggunakan komputasi, penyimpanan, dan konfigurasi jaringan yang serupa dengan konfigurasi utama. Konfigurasi yang redundan antar zona menyediakan isolasi fisik dari seluruh tumpukan antara server primer dan server siaga.

  Anda dapat memilih zona ketersediaan untuk server utama dan siaga atau membiarkan Microsoft memilihnya.

  Kami merekomendasikan penerapan redundan zona untuk server produksi.

  

  Operasi tulis dapat mengalami sedikit peningkatan dalam latensi penyelesaian karena layanan mereplikasi data secara sinkron ke server siaga. Dampaknya bervariasi menurut beban kerja, SKU, dan wilayah yang dipilih.

• Ketersediaan tinggi zonal (zona yang sama): Server utama dan siaga menggunakan zona ketersediaan yang sama. Jika gangguan terjadi pada server utama, tetapi zona masih sehat, server secara otomatis beralih ke server siaga. Penyebaran zona memberi Anda ketersediaan tinggi dalam satu zona ketersediaan. Ini melindungi Anda dari kegagalan pada tingkat node dan juga membantu mengurangi waktu henti aplikasi selama kejadian waktu henti yang direncanakan dan tidak terduga. Namun, itu tidak melindungi dari pemadaman di zona itu.

  

  Ketersediaan tinggi zonal (zona yang sama) hanya tersedia dalam situasi berikut:

  • Wilayah tidak mendukung zona ketersediaan. Wilayah ini secara efektif berfungsi sebagai satu zona, sehingga satu-satunya konfigurasi ketersediaan tinggi yang dapat Anda pilih adalah zona yang sama.
  • Jika wilayah tidak memiliki kapasitas yang memadai untuk penyebaran zona-redundan, layanan awalnya dapat menempatkan kedua server di zona ketersediaan yang sama dan secara otomatis memigrasikannya ke zona terpisah ketika kapasitas tersedia. Opsi ini tersedia saat Anda menggunakan portal Microsoft Azure atau Azure CLI untuk menyebarkan server. Untuk informasi selengkapnya, lihat Mengonfigurasi opsi Business Critical (Ketersediaan Tinggi).

  Karena server berada di zona yang sama, ini dapat mengurangi latensi penulisan ke aplikasi yang Anda terapkan dalam zona yang sama.

Jika Anda mengonfigurasi server tanpa ketersediaan tinggi, server berjalan pada satu server. Jika server atau zonanya tidak berfungsi, server Anda tidak tersedia. Untuk informasi selengkapnya, lihat Konfigurasi tanpa zona ketersediaan.

Persyaratan

• Dukungan wilayah: Dukungan Azure Database for PostgreSQL untuk konfigurasi zona ketersediaan berbeda antar wilayah Azure. Untuk daftar lengkap wilayah, dan jenis dukungan zona ketersediaan dan pertimbangan khusus apa pun untuk wilayah tersebut, lihat Wilayah Azure.

• Tingkat komputasi: Tabel berikut mencantumkan dukungan tingkat komputasi untuk setiap jenis dukungan zona ketersediaan:

  Tingkatan harga	Zone-redundant	Zonal (zona yang sama)
  Dapat meledak	Tidak didukung	Dukungan
  General Purpose	Dukungan	Dukungan
  Memory Optimized	Dukungan	Dukungan

• Tingkat layanan: Redundansi zona memerlukan tingkat Tujuan Umum atau Memori yang Dioptimalkan.

  Penyebaran zona (zona yang sama) didukung pada semua tingkat harga.

Pertimbangan

Kapasitas wilayah: Jika wilayah tidak memiliki kapasitas yang memadai untuk penyebaran zona-redundan, layanan awalnya dapat menempatkan kedua server di zona ketersediaan yang sama dan secara otomatis memigrasikannya ke zona terpisah ketika kapasitas tersedia. Opsi ini tersedia saat Anda menggunakan portal Microsoft Azure atau Azure CLI untuk menyebarkan server. Untuk informasi selengkapnya, lihat Mengonfigurasi opsi Business Critical (Ketersediaan Tinggi).

Biaya

Saat Anda mengaktifkan ketersediaan tinggi, server siaga dibuat dan ditagih dengan tarif yang sama dengan yang utama. Konfigurasi zona ketersediaan tidak memengaruhi biaya. Tidak ada biaya untuk replikasi data di dalam atau di antara zona ketersediaan. Bergantung pada volume penyimpanan cadangan, Anda mungkin juga ditagih untuk penyimpanan cadangan. Untuk informasi harga terperinci, lihat Harga Azure Database for PostgreSQL.

Mengonfigurasi dukungan zona ketersediaan

Untuk mengonfigurasi dukungan zona ketersediaan untuk server, Anda mengonfigurasi pengaturan ketersediaan tinggi.

• Buat server dengan redundansi zona: Untuk mempelajari cara membuat server dengan ketersediaan tinggi dan redundansi zona yang diaktifkan, lihat Panduan Awal: Membuat Azure Database for PostgreSQL di portal Azure.

• Ubah konfigurasi zona ketersediaan untuk server yang ada: Anda dapat mengubah konfigurasi zona ketersediaan untuk server yang ada dengan mengubah pengaturan ketersediaan tinggi. Untuk langkah-langkah mendetail, lihat Mengaktifkan ketersediaan tinggi untuk server yang sudah ada.

  Anda tidak dapat mengubah zona yang digunakan untuk server utama atau siaga setelah dibuat. Anda perlu membuat ulang server.

  Petunjuk / Saran

  Sebaiknya tunggu hingga aktivitas server rendah sebelum Anda mengubah konfigurasi ketersediaan tinggi.

• Nonaktifkan ketersediaan tinggi: Menonaktifkan ketersediaan tinggi menghapus server siaga, sehingga server Anda tidak tahan terhadap pemadaman di zona ketersediaannya. Untuk informasi selengkapnya, lihat Menonaktifkan ketersediaan tinggi.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika server dikonfigurasi dengan dukungan ketersediaan tinggi dan zona ketersediaan dan semua zona ketersediaan beroperasi.

• Operasi lintas zona: Aplikasi klien PostgreSQL terhubung ke server utama dengan menggunakan nama server database. Azure Database for PostgreSQL menggunakan konfigurasi aktif/pasif di mana semua koneksi dan kueri database ditangani oleh server utama di zona ketersediaan utama. Server siaga tidak melayani lalu lintas klien selama operasi normal.

• Replikasi data lintas zona: Perubahan pada data direplikasi secara sinkron antara server utama dan siaga. Transaksi dianggap belum selesai sampai server utama dan siaga mengonfirmasi penulisan.

  Penulisan yang dipicu transaksi aplikasi dan menerapkan log pertama 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. Proses konfirmasi ini tidak menunggu log diterapkan ke server cadangan.

  Efek replikasi berbeda tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda:

  • Zona-redundan: Karena server berada di zona terpisah, pendekatan ini memastikan tidak ada kehilangan data selama kegagalan zona. Situasi ini juga terkadang disebut mencapai tujuan titik pemulihan (RPO) nol untuk kegagalan zona.

    Namun, replikasi lintas zona mungkin memperkenalkan sejumlah kecil latensi tambahan. Dampak latensi tergantung pada aplikasi, dan untuk sebagian besar aplikasi, latensi tersebut dapat diabaikan.

  • Zonal: Karena kedua server berada di zona yang sama, tidak ada lalu lintas yang direplikasi antar zona.

  Nota

  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 server siaga. Jadi, Anda tidak dapat menggunakan sistem siaga untuk memulihkan dari jenis kesalahan ini, dan Anda harus melakukan pemulihan ke titik waktu tertentu dari cadangan. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika server dikonfigurasi untuk mendukung ketersediaan tinggi dan zona ketersediaan, serta ada pemadaman zona ketersediaan.

• Deteksi dan respons: Azure 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.

  Jika terjadi kegagalan zona, perilakunya berbeda tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda:

  • Redundansi Zona: Azure Database for PostgreSQL secara otomatis mendeteksi kegagalan di zona ketersediaan. Untuk melihat kemungkinan jenis status ketersediaan tinggi, lihat Jenis status ketersediaan tinggi. Saat zona gagal, Azure memulai failover paksa ke server siaga tanpa mengharuskan Anda mengambil tindakan.

  • Zonal: Jika zona ketersediaan yang menghosting server zona menjadi tidak tersedia, server utama dan siaga tidak tersedia. Dalam skenario ini, layanan tidak menyediakan failover otomatis. Anda bertanggung jawab untuk mendeteksi pemadaman zona dan melakukan tindakan pemulihan, seperti memulihkan cadangan redundan zona ke server terpisah di zona atau wilayah ketersediaan lain.

• Pemberitahuan: Pemantauan status kesehatan ketersediaan tinggi (HA) di Azure Database for PostgreSQL memberikan gambaran umum berkelanjutan tentang kesehatan dan kesiapan instans berkemampuan HA. Fitur pemantauan dibangun di atas Azure Resource Health, dan dapat mendeteksi dan memperingatkan masalah apa pun yang mungkin memengaruhi kesiapan failover database Anda atau ketersediaan keseluruhan. Menilai metrik utama seperti status koneksi, status failover, dan kesehatan replikasi data, untuk mengaktifkan pemecahan masalah proaktif dan membantu mempertahankan waktu aktif dan performa database Anda.

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

• Permintaan aktif: Ketika zona ketersediaan menjadi tidak tersedia, permintaan yang sedang berlangsung ke server di zona yang terpengaruh mungkin dihentikan. Aplikasi harus mencoba kembali permintaan ini. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

• Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

  • Redundansi zona: Tidak ada kehilangan data yang diharapkan selama penyelesaian kegagalan zona karena replikasi sinkron antara server utama dan server cadangan di zona yang berbeda.

  • Zonal: Data pada server di zona yang terpengaruh tidak tersedia hingga zona pulih.

• Waktu henti yang diharapkan: Jumlah waktu henti tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

  • Zona-redundan: Failover biasanya selesai dalam waktu 60-120 detik. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Zonal: Server di zona yang terkena dampak tidak tersedia hingga zona ketersediaan pulih.

• Redistribusi: Perilaku pengalihan lalu lintas tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

  • Zona-redundan: Setelah failover, server siaga sebelumnya menjadi primer baru dan mulai menerima koneksi baru. Azure secara otomatis membuat server siaga baru di zona utama asli setelah pulih. Untuk detail selengkapnya, lihat Failover paksa.

  • Zonal: Jika zona tidak tersedia, server Anda juga tidak akan tersedia. Jika Anda memiliki server terpisah yang Anda buat sebelumnya di zona ketersediaan atau wilayah lain, Anda bertanggung jawab untuk mengalihkan lalu lintas ke server tersebut.

Pemulihan Zona

Perilaku pemulihan zona tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

• Zona-redundan: Saat zona ketersediaan pulih, Azure Database for PostgreSQL secara otomatis membangun kembali server siaga di zona yang dipulihkan dan menyinkronkannya dengan primer saat ini. Zona yang dipulihkan kemudian berfungsi sebagai lokasi siaga. Layanan tidak secara otomatis memindahkan peran utama kembali ke zona asli untuk menghindari gangguan yang tidak perlu. Anda dapat memulai failover yang direncanakan secara manual jika Anda ingin mengembalikan primer ke zona asli.

• Zonal: Setelah zona sehat, server di zona tersedia lagi. Anda bertanggung jawab atas prosedur pemulihan zona dan sinkronisasi data apa pun yang diperlukan beban kerja Anda.

Uji kegagalan zona

Opsi untuk pengujian kegagalan zona bergantung pada konfigurasi zona ketersediaan yang digunakan instans Anda.

• Zona-redundan: Anda dapat menguji ketahanan aplikasi Anda terhadap failover dengan memulai failover paksa. Failover paksa memungkinkan Anda mensimulasikan skenario pemadaman yang tidak direncanakan saat menjalankan beban kerja Anda dan mengamati waktu henti aplikasi Anda. Sebaiknya jalankan simulasi di lingkungan non-produksi, atau pada waktu yang tenang. Untuk informasi selengkapnya, lihat Memulai failover paksa.

• Zonal: Meskipun Anda tidak dapat mensimulasikan pemadaman zona penuh, Anda dapat mensimulasikan server Anda tidak tersedia dengan cara yang sama dengan apa yang terjadi selama pemadaman zona. Untuk informasi selengkapnya, lihat Menghentikan komputasi server.

Ketahanan terhadap kegagalan di seluruh wilayah

Azure Database for PostgreSQL mendukung replika baca lintas wilayah, yang dapat Anda gunakan untuk mempertahankan salinan database yang disinkronkan di wilayah yang berbeda untuk pemulihan yang lebih cepat.

Anda juga dapat menggunakan cadangan geo-redundan, di wilayah yang didukung, untuk menyediakan pemulihan lintas wilayah. Namun, pencadangan biasanya melibatkan lebih banyak waktu henti dan kehilangan data daripada replikasi. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Replika baca lintas wilayah

Anda dapat menyebarkan replika baca untuk melindungi database Anda dari kegagalan tingkat wilayah. Setiap replikasi baca adalah server Azure Database for PostgreSQL yang terpisah. Saat Anda menempatkan replika baca di wilayah Azure kedua, server database Anda dapat memberikan ketahanan terhadap masalah di seluruh wilayah. Anda dapat menyebarkan hingga lima replika baca, yang secara opsional dapat berada di wilayah Azure yang berbeda. Teknologi replikasi fisik PostgreSQL memperbarui replika baca secara asinkron, dan dapat menjeda replika utama. Replika baca lintas wilayah dapat secara opsional menangani beban kerja baca-saja untuk mengurangi latensi aplikasi yang didistribusikan secara global atau untuk mengalihkan lalu lintas baca dari server utama. Untuk informasi selengkapnya tentang fitur dan pertimbangan replika baca, lihat Membaca replika.

Titik akhir virtual menyediakan titik akhir baca-tulis dan baca-saja, serta secara otomatis mengarahkan lalu lintas saat replika dinaikkan statusnya, yang membantu meminimalkan gangguan layanan selama peristiwa failover. Sebaiknya gunakan titik akhir virtual dengan replika baca lintas wilayah untuk meningkatkan ketahanan aplikasi. Untuk informasi selengkapnya, lihat Titik akhir virtual untuk replika baca di Azure Database for PostgreSQL.

Jika wilayah utama gagal, Anda dapat memicu promosi agar replika sekunder Anda menjadi replika utama. Ada berbagai jenis failover yang dapat Anda picu tergantung pada cara Anda menggunakan replika baca. Saat Anda menggunakan replika baca untuk memberikan ketahanan terhadap kegagalan wilayah, Anda biasanya menggunakan pendekatan promosi ke server utama , yang memperbarui titik akhir virtual Anda. Selama pemadaman wilayah, Anda perlu melakukan promosi paksa, yang dapat mengakibatkan beberapa kehilangan data untuk data yang tidak direplikasi. Dalam skenario yang direncanakan di mana wilayah utama sehat, Anda dapat memilih untuk melakukan promosi yang direncanakan untuk menghindari kehilangan data. Untuk informasi lebih lanjut, lihat Mengaktifkan replika baca di Azure Database untuk PostgreSQL.

Nota

Bagian ini merangkum beberapa informasi penting tentang bagaimana replika baca dapat mendukung ketahanan terhadap gangguan secara regional. Anda juga dapat menggunakan replika baca untuk meningkatkan performa dan mendukung basis pengguna yang didistribusikan secara geografis skala tinggi. Untuk informasi selengkapnya, lihat Membaca replika.

Persyaratan

• Dukungan wilayah: Anda dapat membuat replika baca lintas wilayah di wilayah mana pun yang mendukung Azure Database for PostgreSQL. Anda tidak terbatas pada wilayah berpasangan Azure.

• Tingkat komputasi: Tingkat komputasi General Purpose dan Memory Optimized mendukung replika baca. Tingkat Burstable ini tidak mendukung replika baca.

Pertimbangan

• Perbedaan konfigurasi: Replika baca mungkin tidak mewarisi semua pengaturan konfigurasi dari server utama. Rencanakan untuk mengonfigurasi pengaturan yang diperlukan pasca-failover. Server utama dan replika Anda harus simetris, yang berarti mereka harus memiliki tingkat, ukuran penyimpanan, dan nilai yang sama untuk beberapa pengaturan. Selama kegagalan wilayah, persyaratan server simetris dapat dilepaskan untuk promosi paksa, tetapi ini adalah praktik yang baik untuk memiliki konfigurasi simetris jika memungkinkan untuk menghindari masalah yang tidak terduga. Untuk informasi selengkapnya, lihat Manajemen konfigurasi.

• Memantau lag replikasi: Proses replikasi asinkron memerlukan jeda replikasi, yang dapat bervariasi tergantung pada sejumlah faktor. Ketika lag replikasi sangat tinggi, server Anda mungkin mengalami masalah. Penting untuk memantau jeda replikasi sehingga Anda dapat mengurangi masalah sebelum meningkat. Untuk informasi selengkapnya, silahkan lihat Memantau replikasi.

• Ketersediaan tinggi: Replika baca tidak dapat mengaktifkan ketersediaan tinggi, dan saat dipromosikan, replika baca juga tidak memiliki ketersediaan tinggi. Anda bertanggung jawab untuk mengonfigurasi ketersediaan yang tinggi setelah mempromosikan replika.

Untuk pertimbangan tambahan yang berlaku untuk proses promosi, lihat Mempromosikan replika baca di Azure Database for PostgreSQL - Pertimbangan.

Biaya

Replika baca dikenakan biaya komputasi dan penyimpanan, serta biaya transfer data lintas wilayah untuk replikasi. Untuk informasi harga terperinci, lihat Harga Azure Database for PostgreSQL dan Harga Bandwidth.

Mengonfigurasi dukungan multiregional

• Buat replika baca: Untuk mempelajari cara membuat replika baca, lihat Membuat replika baca. Replika dapat dikonfigurasi setelah server utama dibuat, selama server utama berjalan dan dapat diakses.

  Untuk membuat titik akhir virtual, lihat Membuat titik akhir virtual.

• Menghapus replika baca: Untuk mempelajari cara menghapus replika baca, lihat Menghapus replika baca.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang dapat diharapkan ketika server Anda dikonfigurasi dengan replika baca di wilayah lain dan titik akhir virtual, serta ketika semua wilayah beroperasi.

• Perutean lalu lintas antar wilayah: Dalam operasi normal, titik akhir virtual Anda mengarahkan lalu lintas untuk titik akhir baca-tulis ke server utama di wilayah utama. Jika Anda juga menggunakan titik akhir baca-saja pada titik akhir virtual, maka titik akhir virtual tersebut mengarahkan lalu lintas ke replika mana pun yang Anda konfigurasi.

• Replikasi data antar wilayah: Replika baca lintas wilayah menggunakan replikasi asinkron untuk meminimalkan dampak pada performa server utama. Jumlah lag replikasi tergantung pada sejumlah faktor, termasuk beban tulis dan latensi antara server utama dan replika. Lag replikasi biasanya setidaknya beberapa menit, tetapi bisa lebih lama lagi. Untuk informasi selengkapnya, lihat Pemantauan replikasi.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika server Anda dikonfigurasi dengan replika baca di wilayah lain dan titik akhir virtual, dan ada pemadaman di wilayah utama:

• Deteksi dan respons: Anda bertanggung jawab untuk mendeteksi pemadaman di wilayah utama, dan mempromosikan replika baca secara manual untuk menjadi server utama baru. Selama gangguan wilayah, Anda harus melakukan pemaksaan promosi, yang mengakibatkan hilangnya data yang tidak direplikasi.

  Penting

  Anda bertanggung jawab untuk mengaktifkan promosi. Azure tidak meningkatkan replika baca secara otomatis, meskipun ada kegagalan wilayah.

  Untuk langkah-langkah terperinci untuk memulai promosi, lihat Mengalihkan replika baca ke primer.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Semua koneksi aktif ke wilayah utama dihilangkan. Aplikasi perlu mencoba kembali membuat koneksi ke replika yang dipromosikan setelah proses promosi selesai.

• Kehilangan data yang diperhitungkan: Selama pemadaman wilayah, Anda harus melakukan promosi paksa, yang mengakibatkan hilangnya data yang tidak direplikasi secara permanen.

  Jumlah kehilangan data tergantung pada jeda replikasi pada saat pemadaman. Lag replikasi biasanya setidaknya beberapa menit, tetapi bisa lebih lama lagi. Untuk informasi selengkapnya, lihat Pemantauan replikasi.

• Waktu henti yang diharapkan: Promosi paksa biasanya selesai dalam waktu 1-3 menit setelah dipicu. Aplikasi mungkin juga perlu terhubung kembali ke titik akhir yang benar. Titik akhir virtual diperbarui sebagai bagian dari proses promosi paksa. Aplikasi harus menghormati time-to-live (TTL) dari catatan DNS titik akhir agar mereka dapat dengan cepat terhubung kembali ke replika yang benar setelah penyelesaian promosi.

• Pengalihan lalu lintas: Titik akhir virtual untuk server secara otomatis mengalihkan lalu lintas aplikasi ke replika utama baru.

  Nota

  Setelah replika baca dipromosikan menjadi server utama, server baru tersebut tidak memiliki konfigurasi ketersediaan tinggi yang diaktifkan. Anda perlu mengaktifkan konfigurasi ketersediaan tinggi secara manual, atau menambahkannya ke proses otomatisasi Anda sendiri.

Pemulihan wilayah

Saat Anda menggunakan titik akhir virtual, setelah wilayah utama pulih, server utama lama secara otomatis dikonfigurasi sebagai replika baca. Anda dapat melakukan promosi lain untuk mengembalikan operasi utama ke wilayah utama pilihan Anda.

Pengujian untuk mendeteksi kegagalan wilayah

Secara teratur menguji prosedur promosi baca replika untuk memastikan bahwa proses Anda valid, dan kapabilitasnya memenuhi persyaratan RTO dan RPO Anda.

Anda dapat mempromosikan replika pembacaan untuk menjadi server primer kapan saja, bahkan ketika semua wilayah berfungsi normal. Untuk pengujian:

• Anda dapat melakukan pengujian promosi secara paksa. Kami sarankan Anda melakukan pengujian ini di lingkungan non-produksi karena dapat mengakibatkan kehilangan data. Pengujian promosi paksa membantu mensimulasikan perilaku yang Anda lihat selama pemadaman wilayah.
• Untuk pemeliharaan terencana, atau skenario pengujian di mana Anda ingin menghindari kehilangan data, gunakan promosi yang direncanakan sebagai gantinya. Ketahuilah bahwa promosi yang direncanakan mengikuti proses yang berbeda dari promosi selama pemadaman wilayah.

Untuk instruksi langkah demi langkah, lihat Mengalihkan replika baca ke primer.

Sebagai bagian dari strategi pemulihan bencana Anda, jalankan latihan pemulihan penuh secara teratur. Latihan ini harus mencakup validasi data, pengujian fungsionalitas aplikasi, dan prosedur putar kembali yang didokumenkan.

Pencadangan dan pemulihan

Azure Database for PostgreSQL secara otomatis melakukan pencadangan yang menyediakan kemampuan pemulihan tepat waktu, dan membantu melindungi Anda dari kerusakan dan penghapusan data yang tidak disengaja. Pencadangan dikelola sepenuhnya oleh Microsoft, tidak mengganggu ketersediaan server, dan menyertakan cadangan penuh dan pencadangan log transaksi.

• Penyimpanan cadangan: Jika server dikonfigurasi dengan ketersediaan tinggi zona-redundan, cadangan disimpan di penyimpanan zona redundan (ZRS). Untuk server yang dikonfigurasi tanpa ketersediaan tinggi, atau dengan ketersediaan tinggi zonal (zona tunggal), cadangan disimpan dalam penyimpanan redundan lokal (LRS).

  Di wilayah Azure yang berpasangan, Anda dapat mengonfigurasi penyimpanan cadangan geo-redundan (GRS) selama pembuatan server untuk mereplikasi cadangan ke wilayah Azure berpasangan untuk perlindungan tambahan terhadap kegagalan wilayah. Pencadangan direplikasi secara asinkron.

  Periode retensi cadangan default adalah 7 hari, dengan opsi untuk memperpanjang retensi hingga 35 hari. Anda juga dapat menggunakan Azure Backup untuk penyimpanan jangka panjang cadangan manual hingga 10 tahun. Semua cadangan dienkripsi.

• Mengembalikan: Pemulihan titik waktu memungkinkan Anda memulihkan database kapan saja dalam periode retensi cadangan. Proses pemulihan membuat server database baru dengan nama server baru yang disediakan pengguna, yang kemudian dapat Anda gunakan as-is atau menyalin data.

  Saat memulihkan cadangan geo-redundant, Anda membuat server baru di wilayah pasangan.

  Kemampuan ini berguna untuk memulihkan dari modifikasi data yang tidak disengaja, kesalahan aplikasi, atau skenario pengujian.

Untuk sebagian besar solusi, Anda tidak boleh mengandalkan cadangan secara eksklusif. Sebagai gantinya, gunakan kemampuan lain yang dijelaskan dalam panduan ini untuk mendukung persyaratan ketahanan Anda. Namun, pencadangan melindungi dari beberapa risiko yang tidak dapat dicegah oleh pendekatan lain. Untuk informasi selengkapnya, lihat Apa itu redundansi, replikasi, dan cadangan?.

Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan di Azure Database for PostgreSQL.

Ketahanan terhadap pemeliharaan layanan

Azure Database for PostgreSQL secara otomatis menangani tugas layanan penting termasuk patching perangkat keras, sistem operasi, dan mesin database yang mendasarinya. Layanan ini mencakup pembaruan keamanan, pembaruan perangkat lunak, dan peningkatan versi minor sebagai bagian dari pemeliharaan terencana.

Untuk memastikan server Anda tetap tersedia selama jendela pemeliharaan, ikuti rekomendasi berikut:

• Aktifkan ketersediaan tinggi: Selama pemeliharaan, server mungkin perlu dimulai ulang sebagai bagian dari proses pembaruan. Jika Anda mengaktifkan ketersediaan tinggi, operasi pemeliharaan biasanya menggunakan pembaruan bergulir untuk meminimalkan waktu henti. Aktivitas pemeliharaan berkala seperti peningkatan versi minor terjadi pada replika siaga terlebih dahulu. Untuk mengurangi downtime, perangkat standby diangkat menjadi node utama agar beban kerja dapat terus berjalan saat tugas pemeliharaan diterapkan pada node lainnya. Urutan ini berlaku apakah server Anda menggunakan ketersediaan tinggi zona-redundan atau zonal.

  Untuk server yang tidak memiliki ketersediaan tinggi diaktifkan, dapat mengharapkan adanya waktu henti singkat selama operasi pemeliharaan. Dengan pengaktifan ketersediaan tinggi, operasi pemeliharaan biasanya selesai dengan waktu henti yang sangat sedikit atau bahkan tanpa waktu henti sama sekali.

• Mengonfigurasi jendela pemeliharaan kustom: Anda dapat mengonfigurasi jadwal pemeliharaan agar dikelola sistem atau menentukan jendela pemeliharaan kustom untuk meminimalkan dampak pada operasi bisnis Anda. Jadwalkan pemeliharaan selama periode aktivitas rendah untuk meminimalkan dampak bisnis. Untuk informasi selengkapnya, lihat Menjadwalkan pemeliharaan.

• Terapkan logika coba lagi: Pastikan aplikasi Anda dapat menangani gangguan konektivitas singkat yang mungkin terjadi selama pemeliharaan dimulai ulang. Untuk membuat aplikasi Anda tahan terhadap jenis masalah ini, lihat Panduan ketahanan terhadap kesalahan sementara .

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Azure Database for PostgreSQL menyediakan SLA ketersediaan yang berbeda berdasarkan konfigurasi server:

• Server-server dikonfigurasi dengan ketersediaan tinggi yang redundan antar zona.
• Server dikonfigurasi dengan ketersediaan tinggi zonal (satu zona).
• Server dikonfigurasi tanpa ketersediaan tinggi.

Konten terkait

• Keandalan Azure
• Panduan praktik terbaik arsitektur untuk Azure Database for PostgreSQL
• Gambaran umum kelangsungan bisnis dengan Azure Database for PostgreSQL
• Pemulihan bencana geografis di Azure Database for PostgreSQL
• Azure Database for PostgreSQL Resiliency Solution Accelerator - skrip Terraform untuk mengimplementasikan banyak prinsip ketahanan dan pemulihan yang dijelaskan dalam artikel ini.