Ringkasan kelangsungan bisnis dengan Azure Database for PostgreSQL - Server tunggal

  • Artikel

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Tunggal

Penting

Azure Database for PostgreSQL - Server Tunggal berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke Azure Database for PostgreSQL - Server Fleksibel. Untuk informasi selengkapnya tentang migrasi ke Azure Database for PostgreSQL - Server Fleksibel, lihat Apa yang terjadi pada Server Tunggal Azure Database for PostgreSQL?.

Ringkasan ini menjelaskan kemampuan yang disediakan Azure Database for PostgreSQL untuk kelangsungan bisnis dan pemulihan bencana. Pelajari tentang pemulihan dari peristiwa mengganggu yang dapat menyebabkan kehilangan data atau menyebabkan database dan aplikasi Anda menjadi tidak tersedia. Pelajari tindakan yang harus dilakukan saat kesalahan pengguna atau aplikasi memengaruhi integritas data, wilayah Azure mengalami pemadaman, atau aplikasi Anda memerlukan pemeliharaan.

Fitur yang bisa Anda gunakan untuk menyediakan kelangsungan bisnis

Saat Anda mengembangkan rencana kelangsungan bisnis, Anda perlu memahami waktu maksimum yang dapat diterima sebelum aplikasi pulih sepenuhnya setelah peristiwa yang mengganggu - ini adalah Tujuan Waktu Pemulihan (RTO) Anda. Anda juga perlu memahami jumlah maksimum pembaruan data terbaru (interval waktu) aplikasi dapat mentolerir kehilangan saat pulih setelah peristiwa yang mengganggu - ini adalah Tujuan Titik Pemulihan (RPO) Anda.

Azure Database for PostgreSQL menyediakan fitur kelangsungan bisnis yang mencakup cadangan geo-redundan dengan kemampuan untuk memulai pemulihan geografis, dan menyebarkan replika baca di wilayah yang berbeda. Masing-masing memiliki karakteristik yang berbeda untuk waktu pemulihan dan potensi kehilangan data. Dengan fiturGeo-restore, server baru dibuat menggunakan data cadangan yang direplikasi dari wilayah lain. Waktu keseluruhan yang diperlukan untuk pemulihan dan pulih total tergantung ukuran database dan jumlah log yang akan dipulihkan. Waktu keseluruhan untuk membuat server bervariasi berkisar dari menit hingga jam. Dengan replika baca, log transaksi dari primer dialirkan ke replika secara asinkron. Jika terjadi pemadaman database utama karena kesalahan tingkat zona atau tingkat wilayah, pengalihan ke replika memberikan RTO yang lebih pendek dan mengurangi kehilangan data.

Catatan

Lag antara primer dan replika tergantung pada latensi antarsitus, jumlah data yang akan dikirimkan, dan yang paling penting, beban kerja tulis server utama. Penulisan beban kerja yang berat dapat menimbulkan jeda yang signifikan.

Karena sifat asinkron replikasi yang digunakan untuk replika baca, maka tidak boleh dianggap sebagai solusi Ketersediaan Tinggi (HA) karena semakin lama lag-nya dapat berarti RTO dan RPO yang semakin tinggi. Hanya untuk beban kerja di mana kelambatan tetap lebih kecil melalui waktu puncak dan non-puncak beban kerja, replika baca dapat bertindak sebagai alternatif HA. Jika tidak, replika baca ditujukan untuk skala baca sejati untuk beban kerja berat yang siap dan untuk skenario DR (Pemulihan Bencana).

Tabel berikut membandingkan RTO dan RPO dalam beban kerja umum skenario:

Kemampuan Dasar Tujuan Umum Memori Dioptimalkan
Pemulihan Titik Waktu dari cadangan Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt		 Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt		 Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt
Geo-pemulihan dari cadangan yang direplikasi secara geografis Tidak didukung RTO - Bervariasi
RPO < 1 j		 RTO - Bervariasi
RPO < 1 j
Replika baca RTO - Menit*
RPO < 5 mnt*		 RTO - Menit*
RPO < 5 mnt*		 RTO - Menit*
RPO < 5 mnt*

* RTO dan RPO bisa jauh lebih tinggi dalam beberapa kasus bergantung pada berbagai faktor termasuk latensi antar situs, jumlah data yang akan dikirim, dan yang terpenting beban kerja penulisan database utama.

Memulihkan server setelah kesalahan pengguna atau aplikasi

Anda dapat menggunakan cadangan layanan untuk memulihkan server dari berbagai peristiwa yang mengganggu. Pengguna mungkin tidak sengaja menghapus beberapa data, tidak sengaja menghilangkan tabel penting, atau bahkan menghapus seluruh database. Suatu aplikasi mungkin tidak sengaja menimpa data baik dengan data buruk karena cacat aplikasi, dan sebagainya.

Anda dapat melakukan point-in-time-restore untuk membuat salinan server ke titik waktu yang baik yang diketahui. Titik waktu ini harus berada dalam periode retensi cadangan yang telah dikonfigurasi untuk server Anda. Setelah data dipulihkan ke server baru, Anda dapat mengganti server asli dengan server yang baru dipulihkan atau menyalin data yang diperlukan dari server yang dipulihkan ke server asli.

Gunakan kunci sumber daya Azure untuk membantu mencegah penghapusan server secara tidak disengaja. Jika Anda secara tidak sengaja menghapus server, Anda mungkin dapat memulihkannya jika penghapusan terjadi dalam 5 hari terakhir. Untuk informasi lebih lanjut, lihat Memulihkan server Azure Database for PostgreSQL yang dihentikan.

Pulih dari pemadaman pusat data Azure

Meskipun jarang, pusat data Azure dapat mengalami pemadaman. Ketika pemadaman terjadi, akan menyebabkan gangguan bisnis yang mungkin hanya berlangsung beberapa menit atau bisa juga berjam-jam.

Salah satu opsinya adalah menunggu server Anda kembali daring saat pemadaman pusat data berakhir. Ini berfungsi untuk aplikasi yang mampu memiliki server offline selama jangka waktu tertentu, misalnya lingkungan pengembangan. Ketika pusat data mengalami pemadaman, Anda tidak tahu berapa lama pemadaman mungkin berlangsung, jadi opsi ini hanya berfungsi jika Anda tidak memerlukan server Anda untuk sementara waktu.

Pemulihan Geo

Fitur pemulihan geografis memulihkan server menggunakan cadangan geo-redundan. Cadangan di-hosting di wilayah berpasangan server Anda. Anda dapat memulihkan dari cadangan ini ke wilayah lain. Pemulihan geografis membuat server baru dengan data dari cadangan. Pelajari selengkapnya tentang pemulihan geografis di artikel konsep pencadangan dan pemulihan.

Penting

Pemulihan geo hanya dimungkinkan jika Anda memprovisikan server dengan penyimpanan cadangan geo-redundan. Jika ingin beralih dari pencadangan yang berlebihan secara lokal ke cadangan geo-redundan untuk server yang ada, Anda harus mengambil cadangan menggunakan pg_dump server yang ada dan memulihkannya ke server yang baru dibuat, yang dikonfigurasi dengan cadangan geo-redundan.

Replika baca lintas wilayah

Anda bisa menggunakan replika baca lintas wilayah untuk meningkatkan kelangsungan bisnis dan perencanaan pemulihan bencana Anda. Replika baca diperbarui secara asinkron menggunakan teknologi replikasi fisik PostgreSQL, dan dapat menyebabkan lag pada primer. Pelajari selengkapnya tentang replika baca, wilayah yang tersedia, dan cara mengalihkan dari artikel konsep replika baca.

FAQ

Di mana Azure Database for PostgreSQL menyimpan data pelanggan?

Secara default, Azure Database for PostgreSQL tidak memindahkan atau menyimpan data pelanggan ke luar wilayah tempat data disebarkan. Akan tetapi, pelanggan dapat memilih untuk mengaktifkan cadangan geo-redundan atau membuat replika baca lintas wilayah untuk menyimpan data di wilayah lain.

Langkah berikutnya