Ringkasan kelangsungan bisnis dengan Azure SQL Database
Berlaku untuk:
Azure SQL Database
Artikel ini memberikan gambaran umum tentang kemampuan kelangsungan bisnis dan pemulihan bencana Azure SQL Database, yang menjelaskan opsi dan rekomendasi untuk pulih dari peristiwa mengganggu yang dapat menyebabkan kehilangan data atau menyebabkan database dan aplikasi Anda menjadi tidak tersedia. Pelajari apa yang harus dilakukan saat kesalahan pengguna atau aplikasi memengaruhi integritas data, zona atau wilayah ketersediaan Azure mengalami pemadaman, atau aplikasi Anda memerlukan pemeliharaan.
Gambaran Umum
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.
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 bencana 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 komponen perangkat keras.
Ketersediaan
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%.
Ketersediaan Tinggi
Untuk mencapai ketersediaan tinggi di lingkungan cloud Azure, aktifkan redundansi zona sehingga database, atau kumpulan elastis, menggunakan zona ketersediaan untuk memastikan database, atau kumpulan elastis, tahan terhadap kegagalan zonal. 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 tetap tidak berubah sehingga memperbarui string koneksi aplikasi setelah failover tidak diperlukan.
- 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 | Grup failover | |
|---|---|---|
| Sinkronisasi data berkelanjutan antara primer dan sekunder | Ya | Ya |
| Kegagalan beberapa database secara bersamaan | Tidak | Ya |
| string Koneksi ion tetap tidak berubah setelah failover | Tidak | Ya |
| Mendukung skala-baca | Ya | Ya |
| Beberapa replika | Ya | Tidak |
| Dapat berada di wilayah yang sama dengan primer | Ya | Tidak |
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, SQL Database menyertakan arsitektur ketersediaan, yang menjamin pemulihan otomatis dari kegagalan ini dengan ketersediaan SLA 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 tingkat layanan kecuali 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 komponen perangkat keras. | Untuk mengurangi pemadaman tingkat pusat data atau zona ketersediaan, aktifkan redundansi zona untuk database atau kumpulan elastis untuk menggunakan Zona Ketersediaan Azure dan berikan redundansi di beberapa 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 yang jarang terjadi berdampak pada semua zona ketersediaan dan pusat data yang terdiri darinya, mungkin disebabkan oleh peristiwa bencana alam bencana. | 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. |
RTO dan RPO
Saat Anda mengembangkan rencana kelangsungan bisnis Anda, pahami waktu maksimum yang dapat diterima sebelum aplikasi sepenuhnya pulih setelah peristiwa yang mengganggu. Waktu yang diperlukan aplikasi untuk sepenuhnya pulih dikenal sebagai Tujuan Waktu Pemulihan (RTO). Pahami juga periode maksimum pembaruan data terbaru (interval waktu) aplikasi dapat mentolerir kehilangan saat pulih dari peristiwa disruptif yang tidak diencana. Potensi kehilangan data dikenal sebagai Tujuan Titik Pemulihan (RPO).
Tabel berikut membandingkan RPO dan RTO dari setiap opsi kelangsungan bisnis:
| Opsi kelangsungan bisnis | RTO (waktu henti) | RPO (kehilangan data) |
|---|---|---|
| Ketersediaan Tinggi (Mengaktifkan redundansi zona) |
Biasanya kurang dari 30 detik | 0 |
| Pemulihan Bencana (Mengaktifkan grup failover 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 | Biasanya menit atau jam |
Daftar periksa kelangsungan bisnis
Untuk rekomendasi preskriptif guna memaksimalkan ketersediaan dan mencapai kelangsungan bisnis yang lebih tinggi, lihat:
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, membuat aplikasi Anda online setelah failover atau pemulihan membutuhkan waktu tambahan dan kemungkinan juga memerlukan pemecahan masalah, yang dapat menunda RTO. Ikuti daftar periksa untuk menyiapkan 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 sebagian besar database, operasi pemulihan membutuhkan waktu kurang dari 12 jam. Dibutuhkan waktu lebih lama untuk memulihkan database yang sangat besar atau sangat aktif. Untuk informasi selengkapnya, lihat waktu pemulihan database.
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 database. Untuk mengetahui informasi selengkapnya, lihat Retensi cadangan jangka panjang.
Meningkatkan aplikasi dengan waktu henti minimal
Terkadang aplikasi harus diambil secara offline karena pemeliharaan seperti peningkatan aplikasi. Mengelola peningkatan aplikasi menjelaskan cara menggunakan geo-replikasi aktif untuk memungkinkan peningkatan bergulir aplikasi cloud Anda untuk meminimalkan waktu henti selama peningkatan dan menyediakan 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 siaga bebas lisensi untuk mempelajari lebih lanjut.
Langkah berikutnya
Untuk pertimbangan desain aplikasi, lihat Merancang aplikasi untuk pemulihan bencana cloud dan strategi pemulihan bencana kumpulan Elastis.
Tinjau panduan pemulihan bencana Azure SQL Database dan daftar periksa ketersediaan tinggi dan pemulihan bencana Azure SQL Database.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk