Pemulihan bencana untuk aplikasi SaaS multi-penyewa menggunakan replikasi geo database

Berlaku untuk: Azure SQL Database

Dalam tutorial ini, Anda mengeksplorasi skenario pemulihan bencana penuh untuk aplikasi SaaS multi-penyewa yang diterapkan menggunakan model database-per-penyewa. Untuk melindungi aplikasi dari pemadaman, Anda menggunakan replikasi geografis untuk membuat replika untuk katalog dan database penyewa di wilayah pemulihan alternatif. Jika pemadaman terjadi, Anda segera mengalihkan ke replika ini untuk melanjutkan operasi bisnis normal. Pada failover, database di wilayah asli menjadi replika sekunder database di wilayah pemulihan. Setelah replika ini kembali online, mereka secara otomatis mengejar keadaan database di wilayah pemulihan. Setelah pemadaman teratasi, Anda gagal kembali ke database di wilayah produksi asli.

Tutorial ini mengeksplorasi alur kerja failover dan failback. Anda akan mempelajari cara:

• Menyinkronkan database dan info konfigurasi kumpulan elastis ke dalam katalog penyewa
• Menyiapkan lingkungan pemulihan di wilayah alternatif, yang terdiri dari aplikasi, server, dan kumpulan
• Menggunakan replikasi geografis untuk mereplikasi database katalog dan penyewa ke wilayah pemulihan
• Melakukan fail over aplikasi dan katalog dan database penyewa ke wilayah pemulihan
• Kemudian, melakukan fail over aplikasi, katalog, dan database penyewa kembali ke wilayah asli setelah pemadaman diselesaikan
• Memperbarui katalog karena setiap database penyewa di-fail over untuk melacak lokasi utama database setiap penyewa
• Memastikan aplikasi dan database penyewa utama selalu berada di wilayah Azure yang sama untuk mengurangi latensi

Sebelum memulai tutorial ini, pastikan prasyarat berikut ini diselesaikan:

• Database SaaS Tiket Wingtip per aplikasi penyewa diterapkan. Untuk menerapkan dalam waktu kurang dari lima menit, lihat Menerapkan dan menjelajahi aplikasi Database Multi-penyewa Wingtip Tickets SaaS
• Azure PowerShell dipasang. Untuk detailnya, lihat Mulai menggunakan Azure PowerShell

Pengenalan pola pemulihan replikasi geografis

Pemulihan bencana (DR) menjadi pertimbangan penting bagi banyak aplikasi, baik karena alasan kepatuhan maupun kelangsungan bisnis. Jika terjadi pemadaman layanan yang berkepanjangan, rencana DR yang disiapkan dengan baik dapat meminimalisir gangguan bisnis. Menggunakan replikasi geografis menyediakan RPO dan RTO terendah dengan mempertahankan replika database di wilayah pemulihan yang dapat gagal pada pemberitahuan singkat.

Rencana DR berdasarkan replikasi geografis terdiri dari tiga bagian yang berbeda:

• Penyiapan - pembuatan dan pemeliharaan lingkungan pemulihan
• Pemulihan - failover aplikasi dan database ke lingkungan pemulihan jika pemadaman terjadi,
• Repatriasi - failover aplikasi dan database kembali ke wilayah asli setelah aplikasi diselesaikan

Semua bagian harus dipertimbangkan dengan hati-hati, terutama jika beroperasi dalam skala besar. Secara keseluruhan, rencana tersebut harus mencapai beberapa tujuan:

• Setup
  • Membangun dan memelihara lingkungan gambar cermin di wilayah pemulihan. Membuat kumpulan elastis dan mereplikasi database apa pun di lingkungan pemulihan ini mencadangkan kapasitas di wilayah pemulihan. Memelihara lingkungan ini termasuk mereplikasi database penyewa baru saat disediakan.
• Pemulihan
  • Di mana lingkungan pemulihan yang diperkecil digunakan untuk meminimalkan biaya sehari-hari, kumpulan dan database harus ditingkatkan skalanya untuk memperoleh kapasitas operasional penuh di wilayah pemulihan
  • Aktifkan penyediaan penyewa baru di wilayah pemulihan sesegera mungkin
  • Dioptimalkan untuk memulihkan penyewa dalam urutan prioritas
  • Dioptimalkan untuk mendapatkan penyewa online secepat mungkin dengan melakukan langkah-langkah secara paralel jika praktis
  • Tahan terhadap kegagalan, dapat dimulai ulang, dan idempoten
  • Dimungkinkan untuk membatalkan proses di pertengahan penerbangan jika wilayah asal kembali on-line.
• Pemulangan
  • Failover database dari wilayah pemulihan ke replika di wilayah asli dengan dampak minimal ke penyewa: tidak ada kehilangan data dan periode minimum off-line per penyewa.

Dalam tutorial ini, tantangan ini diatasi menggunakan fitur Azure SQL Database dan platform Azure:

• Template Azure Resource Manager, untuk mencadangkan semua kapasitas yang diperlukan secepat mungkin. Template Azure Resource Manager digunakan untuk menyediakan gambar cermin server produksi dan kumpulan elastis di wilayah pemulihan.
• Geo-replikasi, untuk membuat sekunder baca-saja yang direplikasi secara asinkron untuk semua database. Selama pemadaman, Anda failover ke replika di wilayah pemulihan. Setelah pemadaman teratasi, Anda akan kembali ke database di wilayah produksi asli tanpa kehilangan data.
• Operasi failover asinkron dikirim dalam urutan prioritas penyewa, untuk meminimalkan waktu failover untuk sejumlah besar database.
• Fitur pemulihan manajemen Shard, untuk mengubah entri database dalam katalog selama pemulihan dan repatriasi. Fitur-fitur ini memungkinkan aplikasi untuk terhubung ke database penyewa terlepas dari lokasi tanpa mengonfigurasi ulang aplikasi.
• Alias DNS server SQL, untuk memungkinkan penyediaan penyewa baru yang mulus terlepas dari wilayah mana aplikasi beroperasi. Alias DNS juga digunakan untuk memungkinkan proses sinkronisasi katalog terhubung ke katalog aktif terlepas dari lokasinya.

Dapatkan skrip pemulihan bencana

Penting

Seperti semua skrip manajemen Tiket Wingtip, skrip DR berkualitas sampel dan tidak digunakan dalam produksi.

Skrip pemulihan yang digunakan dalam tutorial ini dan kode sumber aplikasi Wingtip tersedia dalam database Wingtip Tickets SaaS per penyewa repositori GitHub. Lihat panduan umum untuk langkah-langkah mengunduh dan membuka blokir skrip manajemen Tiket Wingtip.

Ikhtisar tutorial

Dalam tutorial ini, Anda pertama-tama menggunakan geo-replikasi untuk membuat replika aplikasi Tiket Wingtip dan databasenya di wilayah yang berbeda. Kemudian, Anda failover ke wilayah ini untuk mensimulasikan pemulihan dari pemadaman. Ketika selesai, aplikasi berfungsi penuh di wilayah pemulihan.

Kemudian, dalam langkah repatriasi terpisah, Anda failover database katalog dan penyewa di wilayah pemulihan ke wilayah asli. Aplikasi dan database tetap tersedia selama repatriasi. Ketika selesai, aplikasi berfungsi penuh di wilayah aslinya.

Catatan

Aplikasi ini dipulihkan ke wilayah yang dipasangkan di wilayah tempat aplikasi diterapkan. Untuk informasi selengkapnya, lihat Wilayah berpasangan Azure.

Tinjau keadaan aplikasi yang sehat

Sebelum Anda memulai proses pemulihan, tinjau keadaan aplikasi yang sehat normal.

1. Di browser web Anda, buka Events Hub Tiket Wingtip (http://events.wingtip-dpt.<user>.trafficmanager.net - ganti <user> dengan nilai pengguna penyebaran Anda).

   • Gulir ke bagian bawah halaman dan perhatikan nama dan lokasi server katalog di footer. Lokasi adalah wilayah tempat Anda menerapkan aplikasi. TIPS: Arahkan mouse ke lokasi untuk memperbesar tampilan.

2. Klik penyewa Contoso Concert Hall dan buka halaman acaranya.

   • Di footer, perhatikan nama server penyewa. Lokasi akan sama dengan lokasi server katalog.

3. Di portal Azure, buka grup sumber daya tempat aplikasi digunakan

   • Perhatikan wilayah tempat server digunakan.

Sinkronkan konfigurasi penyewa ke dalam katalog

Dalam tugas ini, Anda memulai proses yang menyinkronkan konfigurasi server, kumpulan elastis, dan database ke dalam katalog penyewa. Proses ini terus memperbarui informasi ini dalam katalog. Proses ini bekerja dengan katalog aktif, baik di wilayah asli atau di wilayah pemulihan. Informasi konfigurasi digunakan sebagai bagian dari proses pemulihan untuk memastikan lingkungan pemulihan konsisten dengan lingkungan asli, dan kemudian selama repatriasi untuk memastikan wilayah asli dibuat konsisten dengan perubahan apa pun yang dilakukan di lingkungan pemulihan. Katalog ini juga digunakan untuk melacak status pemulihan sumber daya penyewa

Penting

Untuk kesederhanaan, proses sinkronisasi dan proses pemulihan dan repatriasi jangka panjang lainnya diterapkan dalam tutorial ini sebagai pekerjaan atau sesi PowerShell lokal yang berjalan di bawah login pengguna klien Anda. Token autentikasi yang dikeluarkan ketika Anda login akan kedaluwarsa setelah beberapa jam dan pekerjaan kemudian akan gagal. Dalam skenario produksi, proses jangka panjang harus diimplementasikan sebagai layanan Azure yang andal dari beberapa jenis, berjalan di bawah perwakilan layanan. Lihat Menggunakan Azure PowerShell untuk membuat perwakilan layanan dengan sertifikat.

1. Dalam ISE PowerShell, buka file ...\Learning Modules\UserConfig.psm1. Ganti <resourcegroup> dan <user> pada baris 10 dan 11 dengan nilai yang digunakan saat Anda menyebarkan aplikasi. Simpan file!

2. Dalam ISE PowerShell, buka skrip ...\Modul Pembelajaran\Kelangsungan Bisnis dan Pemulihan Bencana\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 dan setel:

   • $DemoScenario = 1, Mulai pekerjaan latar belakang yang menyinkronkan server penyewa, dan info konfigurasi kumpulan ke dalam katalog

3. Tekan F5 untuk menjalankan skrip sinkronisasi. Sesi PowerShell dibuka untuk menyinkronkan konfigurasi sumber daya penyewa.

Biarkan jendela PowerShell berjalan di latar belakang dan lanjutkan sisa tutorial.

Catatan

Proses sinkronisasi tersambung ke katalog melalui alias DNS. Alias ini dimodifikasi selama pemulihan dan repatriasi untuk menunjuk ke katalog aktif. Proses sinkronisasi membuat katalog selalu diperbarui dengan perubahan konfigurasi database atau kumpulan yang dibuat di wilayah pemulihan. Selama repatriasi, perubahan ini diterapkan pada sumber daya yang setara di wilayah asli.

Membuat replika database sekunder di wilayah pemulihan

Dalam tugas ini, Anda memulai proses yang menerapkan contoh aplikasi duplikat dan mereplikasi katalog dan semua database penyewa ke wilayah pemulihan.

Catatan

Tutorial ini menambahkan perlindungan geo-replikasi ke aplikasi sampel Tiket Wingtip. Dalam skenario produksi untuk aplikasi yang menggunakan replikasi geografis, setiap penyewa akan disediakan database yang direplikasi geografis sejak awal. Lihat Mendesain layanan yang sangat tersedia menggunakan Azure SQL Database

1. Dalam ISE PowerShell, buka skrip ...\Modul Pembelajaran\Kelangsungan Bisnis dan Pemulihan Bencana\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 dan setel nilai berikut:

   • $DemoScenario = 2, Buat lingkungan pemulihan gambar cermin dan replikasi katalog dan database penyewa

2. Tekan F5 untuk menjalankan skrip. Sesi PowerShell dibuka untuk membuat replika.

Tinjau status aplikasi normal

Pada titik ini, aplikasi berjalan normal di wilayah asli dan sekarang dilindungi oleh replikasi geografis. Replika sekunder baca-saja, ada di wilayah pemulihan untuk semua database.

1. Di portal Azure, lihat grup sumber daya Anda dan perhatikan bahwa grup sumber daya telah dibuat dengan akhiran pemulihan di wilayah pemulihan.

2. Jelajahi sumber daya dalam grup sumber daya pemulihan.

3. Klik pada database Contoso Concert Hall pada server penyewa1-dpt- < pengguna > -recovery. Klik Geo-Replication di sisi kiri.

   

Di peta wilayah Azure, perhatikan link replikasi geografis antara utama di wilayah asli dan sekunder di wilayah pemulihan.

Failover aplikasi ke wilayah pemulihan

Gambaran umum proses pemulihan replikasi geografis

Skrip pemulihan mengerjakan tugas-tugas berikut:

1. Menonaktifkan endpoint Traffic Manager untuk aplikasi web di wilayah asli. Menonaktifkan titik akhir mencegah pengguna terhubung ke aplikasi dalam keadaan tidak valid jika wilayah asli online selama pemulihan.

2. Menggunakan failover paksa database katalog di wilayah pemulihan untuk menjadikannya database utama, dan memperbarui alias activecatalog untuk menunjuk ke server katalog pemulihan.

3. Memperbarui alias newtenant untuk mengarahkan ke server penyewa di wilayah pemulihan. Mengubah alias ini memastikan bahwa database untuk penyewa baru disediakan di wilayah pemulihan.

4. Menandai semua penyewa yang ada dalam katalog pemulihan sebagai offline untuk mencegah akses ke database penyewa sebelum failover.

5. Memperbarui konfigurasi semua kumpulan elastis dan mereplikasi database tunggal di wilayah pemulihan untuk mencerminkan konfigurasinya di wilayah asli. (Tugas ini hanya diperlukan jika kumpulan atau database yang direplikasi di lingkungan pemulihan diperkecil selama operasi normal untuk mengurangi biaya).

6. Mengaktifkan endpoint Traffic Manager untuk aplikasi web di wilayah asli. Mengaktifkan endpoint ini memungkinkan aplikasi untuk menyediakan penyewa baru. Pada tahap ini, penyewa yang ada masih offline.

7. Mengirimkan batch permintaan untuk memaksa failover database dalam urutan prioritas.

   • Batch diatur sehingga database di-failover secara paralel di semua kumpulan.
   • Permintaan failover diajukan menggunakan operasi asinkron sehingga diajukan dengan cepat dan beberapa permintaan dapat diproses secara bersamaan.

   Catatan

   Dalam skenario pemadaman, database utama di wilayah asli sedang offline. Failover paksa pada sekunder memutus koneksi ke primer tanpa mencoba menerapkan sisa transaksi antrian. Dalam skenario drill DR seperti tutorial ini, jika ada aktivitas pembaruan pada saat failover mungkin ada beberapa kehilangan data. Kemudian, selama repatriasi, ketika Anda failover database di wilayah pemulihan kembali ke wilayah asal, failover normal digunakan untuk memastikan tidak ada kehilangan data.

8. Memantau layanan untuk menentukan kapan database telah di-failover. Setelah database penyewa di-failover, ia memperbarui katalog untuk merekam status pemulihan database penyewa dan menandai penyewa sebagai online.

   • Database penyewa dapat diakses oleh aplikasi segera setelah ditandai secara online di katalog.
   • Sejumlah nilai rowversion dalam database penyewa disimpan di katalog. Nilai ini bertindak sebagai sidik jari yang memungkinkan proses repatriasi untuk menentukan apakah database telah diperbarui di wilayah pemulihan.

Menjalankan skrip untuk failover ke wilayah pemulihan

Sekarang bayangkan ada pemadaman di wilayah di mana aplikasi diterapkan dan menjalankan skrip pemulihan:

1. Dalam ISE PowerShell, buka skrip ...\Modul Pembelajaran\Kelangsungan Bisnis dan Pemulihan Bencana\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 dan setel nilai berikut:

   • $DemoScenario = 3, Pulihkan aplikasi ke wilayah pemulihan dengan gagal ke replika

2. Tekan F5 untuk menjalankan skrip.

   • Skrip terbuka di jendela PowerShell baru dan kemudian memulai serangkaian pekerjaan PowerShell yang berjalan secara paralel. Pekerjaan ini gagal atas database penyewa ke wilayah pemulihan.
   • Wilayah pemulihan adalah wilayah yang dipasangkan yang terkait dengan wilayah Azure tempat Anda menerapkan aplikasi. Untuk informasi selengkapnya, lihat Wilayah berpasangan Azure.

3. Pantau status proses pemulihan di jendela PowerShell.

Catatan

Untuk menjelajahi kode untuk pekerjaan pemulihan, tinjau skrip PowerShell di folder ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs.

Tinjau status aplikasi selama pemulihan

Sementara endpoint aplikasi dinonaktifkan di Traffic Manager, aplikasi tidak tersedia. Setelah katalog di-failover ke wilayah pemulihan dan semua penyewa ditandai offline, aplikasi dibawa kembali online. Meskipun aplikasi tersedia, setiap penyewa muncul offline di hub peristiwa sampai databasenya di-failover. Penting untuk merancang aplikasi Anda untuk menangani database penyewa offline.

1. Segera setelah database katalog dipulihkan, refresh Hub Acara Tiket Wingtip di browser web Anda.

   • Di footer, perhatikan bahwa nama server katalog sekarang memiliki akhiran pemulihan dan terletak di wilayah pemulihan.

   • Perhatikan bahwa penyewa yang belum dipulihkan, ditandai sebagai offline, dan tidak dapat dipilih.

     Catatan

     Dengan hanya beberapa database untuk dipulihkan, Anda mungkin tidak dapat me-refresh browser sebelum pemulihan selesai, sehingga Anda mungkin tidak melihat penyewa saat mereka offline.

     

   • Jika Anda membuka halaman Acara penyewa offline secara langsung, maka akan menampilkan notifikasi 'penyewa offline'. Misalnya, jika Contoso Concert Hall offline, coba buka http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>

Menyediakan penyewa baru di wilayah pemulihan

Bahkan sebelum semua database penyewa yang ada di-failover, Anda dapat menyediakan penyewa baru di wilayah pemulihan.

1. Dalam ISE PowerShell, buka skrip ...\Modul Pembelajaran\Kelangsungan Bisnis dan Pemulihan Bencana\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 dan setel nilai berikut:

   • $DemoScenario = 4, Menyediakan penyewa baru di wilayah pemulihan

2. Tekan F5 untuk menjalankan skrip dan menyediakan penyewa baru.

3. Halaman acara Hawthorn Hall terbuka di browser ketika selesai. Perhatikan dari footer bahwa database Hawthorn Hall disediakan di wilayah pemulihan.

4. Di browser, refresh halaman Hub Acara Tiket Wingtip untuk melihat Hawthorn Hall disertakan.

   • Jika Anda menyediakan Hawthorn Hall tanpa menunggu penyewa lain memulihkan, penyewa lain mungkin masih offline.

Tinjau status aplikasi yang dipulihkan

Ketika proses pemulihan selesai, aplikasi dan semua penyewa berfungsi penuh di wilayah pemulihan.

1. Setelah tampilan di jendela konsol PowerShell menunjukkan semua penyewa dipulihkan, refresh Hub Peristiwa. Semua penyewa akan muncul secara online, termasuk penyewa baru, Hawthorn Hall.

   

2. Di portal Azure, buka daftar grup sumber daya.

   • Perhatikan grup sumber daya yang Anda terapkan, ditambah grup sumber daya pemulihan, dengan akhiran -recovery. Grup sumber daya pemulihan berisi semua sumber daya yang dibuat selama proses pemulihan, ditambah sumber daya baru yang dibuat selama pemadaman.

3. Buka grup sumber daya pemulihan dan perhatikan item berikut:

   • Versi pemulihan katalog dan penyewa1 server, dengan akhiran pemulihan. Katalog yang dipulihkan dan database penyewa di server ini semuanya memiliki nama yang digunakan di wilayah asli.

   • Penyewa2-dpt- < pengguna > -recovery SQL server. Server ini digunakan untuk menyediakan penyewa baru selama pemadaman.

   • App Service bernama, events-wingtip-dpt-recoveryregion-user<<>>, yang merupakan instans pemulihan aplikasi Peristiwa.

     

4. Buka penyewa2-dpt- < pengguna > -recovery SQL server. Perhatikan hal itu berisi database hawthornhall dan kolam elastis, Pool1. Database hawthornhall dikonfigurasi sebagai database elastis di pool1 elastic pool.

5. Navigasi kembali ke grup sumber daya dan klik database Contoso Concert Hall di server tenants1-dpt- < user > -recovery. Klik Geo-Replication di sisi kiri.

   

Mengubah data penyewa

Dalam tugas ini, Anda memperbarui salah satu database penyewa.

1. Di browser Anda, temukan daftar acara untuk Contoso Concert Hall dan catat nama acara terakhir.
2. Di PowerShell ISE, dalam skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1, atur nilai berikut:
   • $DemoScenario = 5 Menghapus acara dari penyewa di wilayah pemulihan
3. Tekan F5 untuk menjalankan skrip
4. Refresh halaman acara Contoso Concert Hall (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall - ganti <user> dengan nilai pengguna penyebaran Anda) dan perhatikan bahwa acara terakhir telah dihapus.

Repatriasi aplikasi ke wilayah produksi aslinya

Tugas ini merepatriasi aplikasi ke wilayah asalnya. Dalam skenario nyata, Anda akan memulai repatriasi ketika pemadaman diselesaikan.

Gambaran umum proses repatriasi

Proses repatriasi:

1. Membatalkan permintaan pemulihan database yang beredar atau dalam penerbangan.
2. Memperbarui alias newtenant untuk mengarahkan ke server penyewa di wilayah pemulihan. Mengubah alias ini memastikan bahwa database untuk penyewa baru disediakan di wilayah pemulihan.
3. Menumbuhkan setiap data penyewa yang diubah ke wilayah asli
4. Melakukan failover database penyewa dalam urutan prioritas.

Failover memindahkan database secara efektif ke wilayah aslinya. Ketika database failover, koneksi terbuka apa pun akan dijatuhkan dan database tidak tersedia selama beberapa detik. Aplikasi harus ditulis dengan logika coba lagi untuk memastikan mereka terhubung lagi. Meskipun pemutusan singkat ini sering tidak diperhatikan, Anda dapat memilih untuk merepatriasi database dari jam kerja.

Menjalankan skrip repatriasi

Sekarang mari kita bayangkan pemadaman diselesaikan dan jalankan skrip repatriasi.

1. Dalam ISE PowerShell, buka skrip ...\Modul Pembelajaran\Kelangsungan Bisnis dan Pemulihan Bencana\DR-FailoverToReplica\Demo-FailoverToReplica.ps1.

2. Pastikan bahwa proses Sinkronisasi Katalog masih berjalan dalam contoh PowerShell-nya. Jika perlu, mulai ulang dengan mengatur:

   • $DemoScenario = 1, Mulai sinkronisasi server penyewa, kumpulan, dan info konfigurasi database ke dalam katalog
   • Tekan F5 untuk menjalankan skrip.

3. Kemudian untuk memulai proses repatriasi, setel:

   • $DemoScenario = 6, Repatriasi aplikasi ke wilayah asalnya
   • Tekan F5 untuk menjalankan skrip pemulihan di jendela PowerShell baru. Repatriasi akan memakan waktu beberapa menit dan dapat dipantau di jendela PowerShell.

4. Saat skrip berjalan, refresh halaman Events Hub (http://events.wingtip-dpt.<user>.trafficmanager.net)

   • Perhatikan bahwa semua penyewa online dan dapat diakses selama proses ini.

5. Setelah repatriasi selesai, refresh hub Acara dan buka halaman acara untuk Hawthorn Hall. Perhatikan bahwa database ini telah direpatriasi ke wilayah asal.

Merancang aplikasi untuk memastikan aplikasi dan database dikolokasi

Aplikasi ini dirancang agar selalu terhubung dari instance di wilayah yang sama dengan database penyewa. Desain ini mengurangi latensi antara aplikasi dan database. Pengoptimalan ini mengasumsikan interaksi aplikasi ke database lebih komunikatif daripada interaksi pengguna ke aplikasi.

Database penyewa dapat tersebar di seluruh wilayah pemulihan dan asli untuk beberapa waktu selama repatriasi. Untuk setiap database, aplikasi mencari wilayah di mana database berada dengan melakukan pencarian DNS pada nama server penyewa. Dalam Database SQL, nama server adalah alias. Nama server alias berisi nama kawasan. Jika aplikasi tidak berada di wilayah yang sama dengan database, aplikasi akan dialihkan ke contoh di wilayah yang sama dengan server. Mengalihkan ke contoh di wilayah yang sama dengan database meminimalkan latensi antara aplikasi dan database.

Langkah berikutnya

Dalam tutorial ini, Anda akan mempelajari cara:

• Menyinkronkan database dan info konfigurasi kumpulan elastis ke dalam katalog penyewa
• Menyiapkan lingkungan pemulihan di wilayah alternatif, yang terdiri dari aplikasi, server, dan kumpulan
• Menggunakan replikasi geografis untuk mereplikasi database katalog dan penyewa ke wilayah pemulihan
• Melakukan fail over aplikasi dan katalog dan database penyewa ke wilayah pemulihan
• Kemudian, melakukan fail over aplikasi, katalog, dan database penyewa kembali ke wilayah asli setelah pemadaman diselesaikan

Anda dapat mempelajari selengkapnya tentang teknologi yang disediakan Azure SQL Database untuk memungkinkan kelangsungan bisnis dalam dokumentasi Gambaran Umum Kelangsungan Bisnis.

Sumber Daya Tambahan:

• Tutorial tambahan yang dibangun di aplikasi Wingtip SaaS