Memulihkan Azure SQL Database atau kegagalan Anda ke sekunder

  • Artikel
  • 5 menit untuk membaca

BERLAKU UNTUK: Azure SQL Database

Azure SQL Database menawarkan kemampuan berikut untuk pemulihan dari pemadaman:

Untuk mempelajari skenario kelangsungan bisnis dan fitur yang mendukung skenario ini, lihat Kelangsungan bisnis.

Catatan

Jika Anda menggunakan Premium zona redundan atau database atau kumpulan Bisnis Penting, proses pemulihannya adalah otomatis dan sisa materi ini tidak berlaku.

Database utama dan sekunder diperlukan untuk memiliki tingkat layanan yang sama. Juga sangat disarankan bahwa database sekunder dibuat dengan ukuran komputasi yang sama (DTU atau vCore) sebagai yang utama. Untuk informasi selengkapnya, lihat Meningkatkan atau menurunkan tingkat sebagai database utama.

Gunakan satu atau beberapa grup kegagalan untuk mengelola kegagalan dari beberapa database. Jika Anda menambahkan hubungan replikasi geo yang ada ke grup kegagalan, pastikan geo sekunder dikonfigurasikan dengan tingkat layanan dan ukuran komputasi yang sama dengan yang utama. Untuk informasi selengkapnya, lihat Menggunakan grup kegagalan otomatis untuk mengaktifkan kegagalan yang transparan dan terkoordinasi dari beberapa database.

Bersiap untuk peristiwa pemadaman

Agar berhasil dengan pemulihan ke wilayah data lain menggunakan grup kegagalan atau cadangan geo redundan, Anda perlu menyiapkan sebuah server di pusat data pemadaman lain untuk menjadi server utama baru dibutuhkan serta memiliki langkah-langkah yang ditentukan dengan baik yang didokumentasikan dan diuji untuk memastikan pemulihan yang lancar. Langkah-langkah persiapan ini meliputi:

  • Identifikasi server di wilayah lain untuk menjadi server utama baru. Untuk pemulihan geo, ini umumnya adalah server di wilayah yang dipasangkan untuk wilayah di mana database Anda berada. Ini menghilangkan biaya lalu lintas tambahan selama operasi pemulihan geo.
  • Identifikasi, dan secara opsional tentukan, aturan firewall IP tingkat server yang diperlukan bagi pengguna untuk mengakses database utama baru.
  • Tentukan bagaimana Anda akan mengalihkan pengguna ke server utama baru, seperti dengan mengubah string koneksi atau dengan mengubah entri DNS.
  • Identifikasi, dan buat secara opsional, login yang harus ada dalam database master di server utama baru, dan jika ada, pastikan login ini memiliki izin akses yang sesuai di database master. Untuk informasi selengkapnya, lihat Pemulihan setelah bencana pada keamanan SQL Database
  • Identifikasi aturan pemberitahuan yang perlu diperbarui untuk memetakan ke database utama baru.
  • Dokumentasikan konfigurasi pengauditan pada database utama saat ini
  • Jalankan latihan pemulihan bencana. Untuk melakukan simulasi pemadaman untuk pemulihan geo, Anda dapat menghapus atau mengganti nama database sumber untuk menyebabkan kegagalan konektivitas aplikasi. Untuk melakukan simulasi pemadaman menggunakan grup kegagalan, Anda dapat menonaktifkan aplikasi web atau komputer virtual yang tersambung ke database atau menggagalkan database untuk menyebabkan kegagalan konektivitas aplikasi.

Kapan saatnya memulai pemulihan

Operasi pemulihan berdampak pada aplikasi. Ini mengharuskan perubahan string koneksi SQL atau pengalihan menggunakan DNS dan dapat mengakibatkan kehilangan data secara permanen. Oleh karena itu, itu harus dilakukan hanya ketika pemadaman kemungkinan akan berlangsung lebih lama daripada tujuan waktu pemulihan aplikasi Anda. Ketika aplikasi disebarkan untuk produksi, Anda harus melakukan pemantauan rutin kesehatan aplikasi dan menggunakan poin data berikut untuk menegaskan bahwa pemulihan bersifat terjamin:

  1. Kegagalan konektivitas permanen dari tingkat aplikasi ke database.
  2. Portal Microsoft Azure memperlihatkan pemberitahuan tentang insiden di wilayah tersebut dengan dampak yang luas.

Catatan

Jika Anda menggunakan grup kegagalan dan memilih kegagalan otomatis, proses pemulihan bersifat otomatis dan transparan untuk aplikasi.

Bergantung pada toleransi aplikasi Anda terhadap waktu henti dan kemungkinan tanggung jawab bisnis, Anda dapat mempertimbangkan opsi pemulihan berikut.

Gunakan Dapatkan Database yang Dapat Dipulihkan(LastAvailableBackupDate) untuk mendapatkan titik pemulihan yang direplikasi geo yang terbaru.

Tunggu pemulihan layanan

Tim Azure bekerja dengan tekun untuk memulihkan ketersediaan layanan secepat mungkin tetapi tergantung pada akar penyebabnya bisa memakan waktu berjam-jam atau berhari-hari. Jika aplikasi Anda dapat menoleransi waktu henti secara signifikan, Anda cukup menunggu pemulihan selesai. Dalam hal ini, Anda tidak perlu melakukan tindakan apa pun. Anda dapat melihat status layanan saat ini pada Dasbor Azure Service Health. Setelah pemulihan wilayah tersebut, ketersediaan aplikasi Anda telah dipulihkan.

Kegagalan ke server sekunder yang direplikasi geo dalam grup kegagalan

Jika waktu henti aplikasi Anda dapat mengakibatkan tanggung jawab bisnis, Anda harus menggunakan grup kegagalan. Ini memungkinkan aplikasi untuk dengan cepat memulihkan ketersediaan di wilayah yang berbeda jika terjadi pemadaman. Untuk tutorial, lihat Menerapkan database yang didistribusikan secara geo.

Untuk memulihkan ketersediaan database, Anda perlu memulai kegagalan ke server sekunder menggunakan salah satu metode yang didukung.

Gunakan salah satu panduan berikut untuk menggagalkan ke database sekunder yang direplikasi secara geo:

Memulihkan menggunakan pemulihan geo

Jika waktu henti aplikasi Anda tidak mengakibatkan tanggung jawab bisnis, Anda dapat menggunakan pemulihan geo sebagai metode untuk memulihkan database aplikasi Anda. Ini membuat sebuah salinan database dari cadangan geo berlebih terbarunya.

Konfigurasikan database Anda setelah pemulihan

Jika Anda menggunakan pemulihan geo untuk memulihkan dari pemadaman, Anda harus memastikan bahwa konektivitas ke database baru telah dikonfigurasi dengan benar sehingga fungsi aplikasi normal dapat dilanjutkan. Ini adalah daftar periksa tugas untuk menyiapkan produksi database Anda yang telah dipulihkan.

Perbarui string koneksi

Karena database Anda yang dipulihkan berada di server yang berbeda, Anda perlu memperbarui string koneksi aplikasi Anda untuk mengarahkan ke server tersebut.

Untuk informasi selengkapnya tentang mengubah string koneksi, lihat bahasa komputer pengembangan yang sesuai untuk pustaka koneksi.

Konfigurasikan aturan firewall

Anda perlu memastikan bahwa aturan firewall yang dikonfigurasikan di server dan di database cocok dengan yang dikonfigurasikan pada server utama dan database utama. Untuk informasi selengkapnya, lihat Cara mengonfigurasi pengaturan firewall (Azure SQL Database).

Mengonfigurasi pengguna login dan database

Anda perlu memastikan bahwa semua login yang digunakan oleh aplikasi Anda ada di server yang menghosting database Anda yang telah dipulihkan. Untuk informasi selengkapnya, lihat Konfigurasi Keamanan untuk replikasi geo.

Catatan

Anda harus mengonfigurasi dan menguji aturan firewall server dan login Anda (dan izin aksesnya) selama latihan pemulihan bencana. Objek tingkat server dan konfigurasinya ini mungkin tidak tersedia selama pemadaman.

Penyiapan pemberitahuan telemetri

Anda perlu memastikan pengaturan aturan pemberitahuan yang ada telah diperbarui untuk memetakan ke database yang telah dipulihkan dan server yang berbeda.

Untuk informasi selengkapnya tentang aturan pemberitahuan database, lihat Menerima Pemberitahuan Peringatan dan Melacak Azure Service Health.

Mengaktifkan pengauditan

Jika pengauditan diperlukan untuk mengakses database Anda, Anda perlu mengaktifkan Pengauditan setelah pemulihan database. Untuk informasi selengkapnya, lihat Pengauditan database.

Langkah berikutnya