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.
Berlaku untuk:
Azure SQL DatabaseSQL Database dalam Fabric
Kelangsungan bisnis di Azure SQL Database mengacu pada mekanisme, kebijakan, dan prosedur yang memungkinkan bisnis Anda untuk terus beroperasi dalam menghadapi gangguan dengan menyediakan ketersediaan, ketersediaan tinggi, dan pemulihan bencana.
Untuk rekomendasi preskriptif guna memaksimalkan ketersediaan dan mencapai kelangsungan bisnis yang lebih tinggi, lihat:
Dalam kebanyakan kasus, SQL Database menangani peristiwa gangguan yang mungkin terjadi di lingkungan cloud dan menjaga aplikasi dan proses bisnis Anda tetap berjalan. Namun, ada beberapa peristiwa mengganggu di mana mitigasi mungkin memakan waktu, seperti:
- Pengguna secara tidak sengaja menghapus atau memperbarui baris dalam tabel.
- Penyerang berbahaya berhasil menghapus data atau menghilangkan database.
- Peristiwa bencana alam dahsyat dapat menghancurkan pusat data atau zona ketersediaan atau wilayah.
- Pusat data langka, zona ketersediaan, atau pemadaman di seluruh wilayah yang disebabkan oleh perubahan konfigurasi, bug perangkat lunak, atau kegagalan perangkat keras.
Ketersediaan Tinggi
Azure SQL Database hadir dengan janji ketahanan dan keandalan inti yang melindunginya dari kegagalan perangkat lunak atau perangkat keras. Pencadangan database diotomatisasi untuk melindungi data Anda dari kerusakan atau penghapusan yang tidak disengaja. Sebagai Platform-as-a-service (PaaS), layanan Azure SQL Database menyediakan ketersediaan sebagai fitur off-the-shelf dengan SLA ketersediaan terkemuka di industri sebesar 99,99%.
Untuk mencapai ketersediaan tinggi di lingkungan cloud Azure, aktifkan redundansi zona. Dengan redundansi zona, database atau kumpulan elastis menggunakan zona ketersediaan Azure untuk menjamin ketahanan terhadap kegagalan antar zona.
- Banyak wilayah Azure menyediakan zona ketersediaan, yang merupakan grup pusat data yang dipisahkan dalam wilayah yang memiliki infrastruktur daya, pendinginan, dan jaringan independen.
- Zona ketersediaan dirancang untuk menyediakan layanan regional, kapasitas, dan ketersediaan tinggi di zona yang tersisa jika satu zona mengalami pemadaman.
Dengan mengaktifkan redundansi zona, database atau kumpulan elastis tahan terhadap kegagalan perangkat keras dan perangkat lunak zonal dan pemulihannya transparan terhadap aplikasi. Ketika ketersediaan tinggi diaktifkan, layanan Azure SQL Database dapat menyediakan SLA ketersediaan yang lebih tinggi sebesar 99,995%.
Pemulihan dari bencana
Untuk mencapai ketersediaan dan redundansi yang lebih tinggi di seluruh wilayah, Anda dapat memungkinkan kemampuan pemulihan bencana untuk memulihkan database dengan cepat dari kegagalan regional bencana. Opsi untuk pemulihan bencana dengan Azure SQL Database adalah:
- Replikasi geografis aktif memungkinkan Anda membuat database sekunder yang dapat dibaca yang terus disinkronkan di wilayah mana pun untuk database utama.
- Grup failover, selain menyediakan sinkronisasi berkelanjutan antara database primer dan sekunder, juga memungkinkan Anda mengelola replikasi dan failover beberapa, atau semua, database di server logis ke server logis sekunder di wilayah lain. Grup failover menyediakan titik akhir pendengar baca-tulis dan baca-saja yang tidak berubah, sehingga tidak perlu memperbarui string koneksi aplikasi setelah failover.
- Pemulihan geografis memungkinkan Anda memulihkan dari pemadaman regional dengan memulihkan dari cadangan yang direplikasi secara geografis saat Anda tidak dapat mengakses database Anda di wilayah utama dengan membuat database baru di server yang ada di wilayah Azure mana pun.
Tabel berikut membandingkan grup replikasi geografis dan failover aktif, dua opsi pemulihan bencana untuk Azure SQL Database:
| Replikasi Geografis Aktif | Kelompok Pemulihan | |
|---|---|---|
| Sinkronisasi data berkelanjutan antara primer dan sekunder | Ya | Ya |
| Kegagalan beberapa database secara bersamaan | Tidak | Ya |
| String koneksi tetap tidak berubah setelah failover | Tidak | Ya |
| Mendukung peningkatan kapasitas pembacaan | Ya | Ya |
| Beberapa replika | Ya | Tidak |
| Dapat berada di wilayah yang sama dengan utama | Ya | Tidak |
RTO dan RPO
Saat Anda mengembangkan rencana kelangsungan bisnis Anda, pahami waktu maksimum yang dapat diterima sebelum aplikasi sepenuhnya pulih setelah peristiwa yang mengganggu. Dua cara umum untuk mengukur persyaratan bisnis sekeliling pemulihan bencana adalah:
- Tujuan Waktu Pemulihan (RTO): Waktu yang diperlukan aplikasi untuk sepenuhnya pulih setelah peristiwa disruptif yang tidak diencana.
- Tujuan Titik Pemulihan (RPO): Jumlah waktu kehilangan data yang dapat ditoleransi dari peristiwa disruptif yang tidak diencana.
Tabel berikut membandingkan RPO dan RTO dari setiap opsi kelangsungan bisnis:
| Opsi kelangsungan bisnis | RTO (waktu henti) | RPO (kehilangan data) |
|---|---|---|
| Ketersediaan Tinggi (Menggunakan redundansi zona) |
Biasanya kurang dari 30 detik | 0 |
| Pemulihan dari Bencana (Menggunakan grup failover dengan kebijakan failover yang dikelola oleh pelanggan atau replikasi geografis aktif) | Biasanya kurang dari 60 detik | Sama dengan atau lebih besar dari 0 (Tergantung pada perubahan data sebelum peristiwa gangguan yang belum direplikasi) |
| Pemulihan Bencana (Menggunakan pemulihan geografis) |
Biasanya menit atau jam, tergantung pada replikasi penyimpanan Azure | Biasanya menit atau jam, tergantung pada ukuran cadangan database |
Fitur yang memberikan kelangsungan bisnis
Dari perspektif database, ada empat skenario gangguan potensial utama. Tabel berikut ini mencantumkan fitur kelangsungan bisnis SQL Database yang bisa Anda gunakan untuk mengurangi skenario potensi gangguan bisnis:
| Skenario gangguan bisnis | Fitur kelangsungan bisnis |
|---|---|
| Kegagalan perangkat keras atau perangkat lunak lokal yang memengaruhi simpul database. | Untuk mengurangi kegagalan perangkat keras dan perangkat lunak lokal, Azure SQL Database menyertakan arsitektur ketersediaan, yang menjamin pemulihan otomatis dari kegagalan ini dengan SLA ketersediaan hingga 99,99%. |
| Kerusakan atau penghapusan data biasanya disebabkan oleh bug aplikasi atau kesalahan manusia. Kegagalan tersebut terbatas pada aplikasi dan biasanya tidak dapat dideteksi oleh layanan database. | Untuk melindungi bisnis Anda dari kehilangan data, SQL Database secara otomatis membuat cadangan database lengkap setiap minggu, cadangan database diferensial setiap 12 atau 24 jam, dan pencadangan log transaksi setiap 5 - 10 menit. Secara default, cadangan disimpan dalam penyimpanan geo-redundan selama tujuh hari untuk semua tingkat layanan. Semua peringkat layanan kecuali tingkat layanan Dasar mendukung periode retensi cadangan yang dapat dikonfigurasi untuk pemulihan titik waktu (PITR) hingga 35 hari. Anda dapat memulihkan database yang dihapus ke titik saat database dihapus jika server belum dihapus, atau jika Anda telah mengonfigurasi retensi jangka panjang (LTR). |
| Pemadaman pusat data atau zona ketersediaan yang jarang terjadi, mungkin disebabkan oleh peristiwa bencana alam, perubahan konfigurasi, bug perangkat lunak, atau kegagalan perangkat keras. | Untuk mengurangi pemadaman tingkat pusat data atau zona ketersediaan, aktifkan redundansi zona untuk database atau kumpulan elastis agar menggunakan Zona Ketersediaan Azure dan memberikan redundansi di banyak zona fisik dalam wilayah Azure. Mengaktifkan redundansi zona memastikan database atau kumpulan elastis tahan terhadap kegagalan zonal dengan ketersediaan tinggi SLA hingga 99,995%. |
| Pemadaman regional langka yang memengaruhi semua zona ketersediaan dan pusat data yang terdiri darinya, mungkin disebabkan oleh peristiwa bencana bencana alam. | Untuk mengurangi pemadaman di seluruh wilayah, aktifkan pemulihan bencana menggunakan salah satu opsi: - Opsi sinkronisasi data berkelanjutan seperti grup failover (disarankan) atau replikasi geografis aktif yang memungkinkan Anda membuat replika di wilayah sekunder untuk failover. - Mengatur redundansi penyimpanan cadangan ke penyimpanan cadangan geo-redundan untuk menggunakan pemulihan geografis. |
Bersiap untuk pemadaman wilayah
Terlepas dari fitur kelangsungan bisnis mana yang Anda gunakan, Anda harus menyiapkan database sekunder di wilayah lain. Jika Anda tidak mempersiapkan dengan benar, membawa aplikasi Anda online setelah terjadinya failover atau pemulihan membutuhkan waktu tambahan dan kemungkinan juga diperlukan pemecahan masalah, yang dapat menunda waktu pemulihan RTO. Ikuti daftar periksa untuk menyiapkan sistem sekunder untuk pemadaman wilayah.
Memulihkan database dalam wilayah Azure yang sama
Anda bisa menggunakan pencadangan database otomatis untuk memulihkan database ke titik waktu di masa lalu. Dengan cara ini Anda dapat memulihkan dari kerusakan data yang disebabkan oleh kesalahan manusia. Pemulihan titik waktu (PITR) memungkinkan Anda membuat database baru di server yang sama yang mewakili status data sebelum peristiwa yang rusak. Untuk waktu pemulihan, lihat RTO dan RPO.
Jika periode retensi cadangan maksimum yang didukung untuk pemulihan point-in-time tidak cukup untuk aplikasi Anda, Anda dapat memperpanjangnya dengan mengonfigurasi kebijakan retensi jangka panjang (LTR). Untuk mengetahui informasi selengkapnya, lihat Retensi jangka panjang.
Memperbarui aplikasi dengan waktu henti minimal
Terkadang aplikasi harus diambil secara offline karena pemeliharaan seperti peningkatan aplikasi. Anda dapat mengelola peningkatan bergulir aplikasi cloud dengan menggunakan replikasi geografis aktif SQL Database. Replikasi geografis juga dapat memberikan jalur pemulihan jika terjadi kesalahan.
Menghemat biaya dengan replika siaga
Jika replika sekunder Anda hanya digunakan untuk pemulihan bencana (DR) dan tidak memiliki beban kerja baca atau tulis, Anda dapat menghemat biaya lisensi dengan menunjuk database untuk siaga saat Anda mengonfigurasi hubungan geo-replikasi aktif baru.
Tinjau replika cadangan siaga bebas lisensi untuk mempelajari lebih lanjut.