Ketersediaan tinggi untuk Azure SQL Database dan SQL Managed Instance

Berlaku untuk: Azure SQL Managed Instance Database Azure SQL

Artikel ini menjelaskan ketersediaan tinggi di Azure SQL Database dan Azure SQL Managed Instance.

Konfigurasi zona-redundan saat ini dalam pratinjau untuk SQL Managed Instance, dan hanya tersedia untuk tingkat layanan Business Critical.

Gambaran Umum

Tujuan dari arsitektur ketersediaan tinggi dalam Azure SQL Database dan SQL Managed Instance adalah untuk menjamin bahwa database Anda aktif dan berjalan minimal 99,99% waktu tanpa khawatir tentang efek operasi pemeliharaan dan pemadaman. Untuk informasi selengkapnya mengenai SLA tertentu untuk tingkat yang berbeda, lihat SLA untuk Azure SQL Database dan SLA untuk Azure SQL Managed Instance.

Azure otomatis menangani tugas layanan penting, seperti patching, pencadangan, peningkatan Windows dan Azure SQL, serta peristiwa yang tidak direncanakan seperti kegagalan perangkat keras, perangkat lunak, atau jaringan yang mendasari. Saat database yang mendasarinya di Azure SQL Database di-patch atau di-failover, waktu henti tidak terlihat jika Anda menggunakan logika coba lagi di aplikasi Anda. SQL Database dan SQL Managed Instance dapat pulih dengan cepat bahkan dalam keadaan paling penting dan memastikan bahwa data Anda selalu tersedia.

Solusi ketersediaan tinggi dirancang untuk memastikan bahwa data yang diterapkan tidak pernah hilang karena kegagalan, bahwa operasi pemeliharaan tidak memengaruhi beban kerja Anda, dan bahwa database tidak akan menjadi satu titik kegagalan dalam arsitektur perangkat lunak Anda. Tidak ada jendela atau waktu henti pemeliharaan yang mengharuskan Anda menghentikan beban kerja saat database ditingkatkan atau dipertahankan.

Ada dua model arsitektur ketersediaan tinggi:

  • Model ketersediaan standar yang didasarkan pada pemisahan komputasi dan penyimpanan. Ini bergantung pada ketersediaan tinggi dan keandalan tingkat penyimpanan jarak jauh. Arsitektur ini menargetkan aplikasi bisnis berorientasi anggaran yang dapat menoleransi beberapa penurunan performa selama aktivitas pemeliharaan.
  • Model ketersediaan premium yang didasarkan pada kluster proses mesin database. Ini bergantung pada fakta bahwa selalu ada kuorum node mesin database yang tersedia. Arsitektur ini menargetkan aplikasi yang penting untuk misi dengan performa IO tinggi, tingkat transaksi tinggi, dan menjamin dampak performa minimal terhadap beban kerja Anda selama aktivitas pemeliharaan.

SQL Database dan SQL Managed Instance keduanya berjalan pada versi stabil terbaru dari SQL Server Database Engine dan sistem operasi Windows, dan sebagian besar pengguna tidak akan melihat bahwa peningkatan dilakukan terus menerus.

Ketersediaan berlebih secara lokal tingkat layanan Dasar, Standar, dan Tujuan Umum

Tingkat layanan Basic, Standard, dan General Purpose memanfaatkan arsitektur ketersediaan standar untuk komputasi tanpa server dan yang diprovisikan. Gambar berikut menunjukkan empat node yang berbeda dengan lapisan komputasi dan penyimpanan yang dipisahkan.

Diagram memperlihatkan pemisahan komputasi dan penyimpanan.

Model ketersediaan standar mencakup dua lapisan:

  • Lapisan komputasi stateless yang menjalankan sqlservr.exe proses dan hanya berisi data sementara dan cache, seperti tempdb database dan model pada SSD yang terpasang, dan cache paket, kumpulan buffer, dan kumpulan penyimpanan kolom dalam memori. Node tanpa status ini dioperasikan oleh Microsoft Azure Service Fabric yang menginisialisasi sqlservr.exe, mengontrol kondisi node, dan melakukan kegagalan ke node lain jika perlu.
  • Lapisan data stateful dengan file database (.mdf dan .ldf) yang disimpan dalam Azure Blob Storage. Azure Blob Storage memiliki ketersediaan data bawaan dan fitur redundansi. Ini menjamin bahwa setiap rekaman dalam file log atau halaman dalam file data akan terlindungi bahkan jika sqlservr.exe proses mengalami crash.

Setiap kali mesin database atau sistem operasi ditingkatkan, atau kegagalan terdeteksi, Azure Service Fabric akan memindahkan proses stateless sqlservr.exe ke node komputasi stateless lain dengan kapasitas bebas yang cukup. Data di penyimpanan Azure Blob tidak terpengaruh oleh pemindahan, dan file data/log dilampirkan ke proses yang baru diinisialisasi sqlservr.exe . Proses ini menjamin ketersediaan 99,99%, tetapi beban kerja yang berat mungkin mengalami beberapa penurunan kinerja selama transisi karena proses sqlservr.exe baru dimulai dengan cold cache.

Ketersediaan redundansi zona tingkat layanan Tujuan Umum

Konfigurasi zona redundan untuk tingkat layanan Tujuan Umum ditawarkan untuk komputasi tanpa server dan yang disediakan. Konfigurasi ini menggunakan Zona Ketersediaan Azure untuk mereplikasi database di beberapa lokasi fisik dalam wilayah Azure. Dengan memilih redundansi zona, Anda dapat membuat database tunggal dan kumpulan elastis tanpa server dan General Purpose diprovisikan yang baru dan yang sudah ada yang tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data besar-besaran, tanpa perubahan pada logika aplikasi.

Konfigurasi zona redundan untuk tingkat Tujuan Umum memiliki dua lapisan:

  • Lapisan data yang stateful dengan file database (.mdf/.ldf) yang disimpan dalam ZRS (penyimpanan redundansi zona). Dengan ZRS, data dan file log disalin secara sinkron di tiga zona ketersediaan Azure yang terisolasi secara fisik.
  • Lapisan komputasi stateless yang menjalankan proses sqlservr.exe dan hanya berisi data sementara dan cache, seperti tempdb database dan model pada SSD yang dilampirkan, dan cache paket, kumpulan buffer, dan kumpulan penyimpanan kolom dalam memori. Node tanpa status ini dioperasikan oleh Microsoft Azure Service Fabric yang menginisialisasi sqlservr.exe, mengontrol kondisi node, dan melakukan kegagalan ke node lain jika perlu. Untuk database Tujuan Umum tanpa server dan disediakan zona-redundan, simpul dengan kapasitas cadangan tersedia di Zona Ketersediaan lainnya untuk failover.

Versi zona redundan dari arsitektur ketersediaan tinggi untuk tingkat layanan Tujuan Umum diilustrasikan oleh diagram berikut:

Diagram konfigurasi zona redundan untuk Tujuan Umum.

  • Untuk tingkat Tujuan Umum, konfigurasi zona-redundan Umumnya Tersedia di wilayah berikut: Eropa Barat, Eropa Utara, US Barat 2, Prancis Tengah, US Timur 2, AS Timur, Asia & Tenggara Qatar Tengah. Ini dalam pratinjau di wilayah berikut: Australia Timur, Jepang Timur, dan UK Selatan.
  • Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.
  • Konfigurasi zona-redundan hanya tersedia di SQL Database ketika perangkat keras Gen5 dipilih. Konfigurasi zona-redundan saat ini dalam pratinjau untuk SQL Managed Instance, dan hanya tersedia untuk tingkat layanan Business Critical.

Ketersediaan redundan secara lokal tingkat layanan Premium dan Bisnis Penting

Tingkat layanan Premium dan Business Critical memanfaatkan model ketersediaan Premium, yang mengintegrasikan sumber daya komputasi (prose sqlservr.exe) dan penyimpanan (SSD yang terpasang secara lokal) pada satu node. Ketersediaan tinggi dicapai dengan mereplikasi komputasi dan penyimpanan ke node tambahan yang menciptakan kluster tiga hingga empat node.

Diagram kluster simpul mesin database.

File database yang mendasari (.mdf/.ldf) ditempatkan pada penyimpanan SSD yang dilampirkan untuk menyediakan IO latensi yang sangat rendah ke beban kerja Anda. Ketersediaan tinggi diimplementasikan menggunakan teknologi yang mirip dengan Grup Ketersediaan AlwaysOn SQL Server. Kluster ini mencakup satu replika utama yang dapat diakses untuk beban kerja pelanggan baca-tulis, dan hingga tiga replika sekunder (komputasi dan penyimpanan) yang berisi salinan data. Node utama terus-menerus mendorong perubahan ke node sekunder secara berurutan dan memastikan bahwa data dipertahankan ke setidaknya satu replika sekunder sebelum menerapkan setiap transaksi. Proses ini menjamin bahwa jika node utama mengalami crash karena alasan apa pun, selalu ada node yang sepenuhnya disinkronkan untuk gagal. Kegagalan dimulai oleh Azure Service Fabric. Setelah replika sekunder menjadi node primer baru, replika sekunder lain dibuat untuk memastikan kluster memiliki node yang cukup (set kuorum). Setelah kegagalan selesai, koneksi Azure SQL secara otomatis dialihkan ke node utama baru.

Sebagai manfaat tambahan, model ketersediaan premium mencakup kemampuan untuk mengalihkan koneksi Azure SQL baca-saja ke salah satu replika sekunder. Fitur ini disebut Read Scale-Out. Ini menyediakan 100% kapasitas komputasi tambahan tanpa biaya tambahan untuk operasi baca-saja off-load, seperti beban kerja analitis, dari replika utama.

Ketersediaan redundan zona tingkat layanan Premium dan Bisnis Penting

Secara default, kluster node untuk model ketersediaan premium dibuat di pusat data yang sama. Dengan diperkenalkannya Zona Ketersediaan Azure, SQL Database dapat menempatkan replika database Bisnis Penting yang berbeda ke zona ketersediaan yang berbeda di wilayah yang sama. Untuk menghilangkan satu titik kegagalan, cincin kontrol juga diduplikasi di beberapa zona sebagai tiga cincin gateway (GW). Perutean ke cincin gateway tertentu dikendalikan oleh Azure Traffic Manager (ATM). Karena konfigurasi zona-redundan di tingkat layanan Premium atau Business Critical tidak membuat redundansi database tambahan, Anda dapat mengaktifkannya tanpa biaya tambahan. Dengan memilih konfigurasi redundan zona, Anda dapat membuat database Premium atau Business Critical Anda tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat besar-besaran, tanpa perubahan pada logika aplikasi. Anda juga dapat mengonversi database atau kumpulan database Premium atau Business Critical yang ada ke konfigurasi redundan zona.

Karena database zona-redundan memiliki replika di pusat data yang berbeda dengan beberapa jarak di antara mereka, latensi jaringan yang meningkat dapat meningkatkan waktu penerapan, dan dengan demikian berdampak pada performa beberapa beban kerja OLTP. Anda selalu bisa kembali ke konfigurasi zona tunggal dengan menonaktifkan pengaturan redundansi zona. Proses ini adalah operasi daring yang mirip dengan peningkatan tingkat layanan reguler. Di akhir proses, database atau kumpulan dimigrasikan dari wilayah redundan zona ke wilayah zona tunggal atau sebaliknya.

Penting

Fitur ini saat ini dalam Pratinjau untuk SQL Managed Instance. Di SQL Database, saat menggunakan tingkat Business Critical, konfigurasi zona-redundan hanya tersedia saat perangkat keras seri standar (Gen5) dipilih. Untuk informasi terkini tentang kawasan yang mendukung database redundan zona, lihat Dukungan layanan menurut kawasan.

Versi redundan zona dari arsitektur ketersediaan tinggi digambarkan oleh diagram berikut:

Diagram arsitektur ketersediaan tinggi zona-redundan.

  • Fitur ini saat ini dalam pratinjau untuk SQL Managed Instance, dan hanya tersedia di tingkat layanan Business Critical. Di SQL Database, saat menggunakan tingkat Business Critical, konfigurasi zona-redundan hanya tersedia ketika perangkat keras komputasi Gen5 dipilih. Untuk informasi terkini tentang kawasan yang mendukung database redundan zona, lihat Dukungan layanan menurut kawasan.
  • Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.

Penting

Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.

Selama pratinjau, redundansi zona untuk SQL Managed Instance tersedia di tingkat layanan Business Critical dan didukung di wilayah berikut:

Geografi Wilayah yang mendukung redundansi zona untuk tingkat layanan Business Critical
Eropa, Timur Tengah, Afrika Eropa Utara, Norwegia Timur, Afrika Selatan Utara, Swedia Tengah, Swiss Utara, Eropa Barat, UEA Utara, Inggris Selatan
Amerika Brasil Selatan, Kanada Tengah, US Timur, US Tengah Selatan, US Barat 3
Asia Pasifik Australia Timur, Asia Timur, India Tengah, Jepang Timur, Korea Tengah

Ketersediaan redundan secara lokal tingkat layanan Hyperscale

Arsitektur tingkat layanan Hyperscale dijelaskan dalam arsitektur fungsi Terdistribusi dan saat ini hanya tersedia untuk SQL Database, bukan SQL Managed Instance.

Diagram memperlihatkan arsitektur fungsional Hyperscale.

Model ketersediaan di Hyperscale mencakup empat lapisan:

  • Lapisan komputasi stateless yang menjalankan sqlservr.exe proses dan hanya berisi data sementara dan cache, seperti cache RBPEX yang tidak mencakup, tempdb dan model database, dll. pada SSD yang terpasang, dan cache paket, kumpulan buffer, dan kumpulan penyimpanan kolom dalam memori. Lapisan stateless ini mencakup replika komputasi utama, dan secara opsional sejumlah replika komputasi sekunder, yang dapat berfungsi sebagai target failover.
  • Lapisan penyimpanan stateless yang dibentuk oleh server halaman. Lapisan ini adalah mesin penyimpanan terdistribusi untuk sqlservr.exe proses yang berjalan pada replika komputasi. Setiap server halaman hanya berisi data sementara dan cache, seperti mencakup cache RBPEX pada SSD yang dilampirkan, dan halaman data yang di-cache di memori. Setiap server halaman memiliki server halaman yang dipasangkan dalam konfigurasi aktif-aktif untuk memberikan keseimbangan beban, redundansi, dan ketersediaan tinggi.
  • Lapisan penyimpanan log transaksi berstatus yang dibentuk oleh node komputasi yang menjalankan proses layanan Log, zona landasan log transaksi, dan penyimpanan jangka panjang log transaksi. Zona landasan dan penyimpanan jangka panjang menggunakan Azure Storage, yang menyediakan ketersediaan dan redundansi untuk log transaksi, sehingga memastikan durabilitas data untuk transaksi yang diterapkan.
  • Lapisan penyimpanan data stateful dengan file database (.mdf/.ndf) yang disimpan di Azure Storage dan diperbarui oleh server halaman. Lapisan ini menggunakan fitur ketersediaan data dan redundansi Azure Storage. Ini menjamin bahwa setiap halaman dalam file data akan dipertahankan bahkan jika proses di lapisan lain dari arsitektur Hyperscale mengalami crash, atau jika node komputasi gagal.

Node komputasi di semua lapisan Hyperscale berjalan pada Azure Service Fabric, yang mengontrol kondisi setiap node dan melakukan kegagalan ke node sehat yang tersedia jika perlu.

Untuk informasi selengkapnya tentang ketersediaan tinggi di Hyperscale, lihat Ketersediaan Tinggi Database di Hyperscale.

Ketersediaan redundan zona tingkat layanan Hyperscale

Aktivasi konfigurasi ini memastikan ketahanan tingkat zona melalui replikasi di seluruh Zona Ketersediaan untuk semua lapisan Hyperscale. Dengan memilih zona-redundansi, Anda dapat membuat database Hyperscale Anda tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data yang fatal, tanpa perubahan apa pun pada logika aplikasi. Semua wilayah Azure yang memiliki Zona Ketersediaan mendukung database Hyperscale zona redundan.

Pertimbangkan batasan berikut:

  • Konfigurasi redundan zona hanya dapat ditentukan selama pembuatan database. Pengaturan ini tidak dapat dimodifikasi setelah sumber daya disediakan. Gunakan Salinan Database, pemulihan titik waktu, atau buat replika-geografis untuk memperbarui konfigurasi redundan zona pada database Hyperscale yang ada. Ketika menggunakan salah satu opsi pembaruan ini, jika database target berada di wilayah yang berbeda dari sumber atau jika redundansi penyimpanan pencadangan database dari target berbeda dengan database sumber, operasi penyalinan akan menjadi ukuran operasi data.
  • Hanya perangkat keras seri standar (Gen5) yang didukung.
  • Replika bernama saat ini tidak didukung.
  • Redundansi zona saat ini tidak dapat ditentukan saat memigrasikan database yang ada dari tingkat layanan database Azure SQL lain ke Hyperscale.
  • Setidaknya 1 replika komputasi ketersediaan tinggi dan penggunaan penyimpanan cadangan redundan zona atau geo-zona-redundan diperlukan untuk mengaktifkan konfigurasi redundan zona untuk Hyperscale.

Penting

Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.

Membuat database Hyperscale redundan zona

Gunakan Azure PowerShell atau CLI Azure untuk membuat database Hyperscale redundan zona. Pastikan bahwa Anda memiliki versi terbaru API untuk memastikan dukungan terhadap perubahan terbaru apa pun.

Tentukan parameter -ZoneRedundant untuk mengaktifkan redundansi zona pada database Hyperscale Anda dengan menggunakan Azure PowerShell. Database harus memiliki setidaknya 1 replika high availability dan penyimpanan cadangan zona-redundan harus ditentukan.

Untuk mengaktifkan redundansi zona menggunakan Azure PowerShell, gunakan perintah contoh berikut:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone -RequestedServiceObjectiveName HS_Gen5_2'

Buat database Hyperscale redundan zona dengan membuat replika-geografis

Untuk membuat zona database Hyperscale yang ada redundan, gunakan Azure PowerShell atau CLI Azure untuk membuat database Hyperscale redundan zona menggunakan replikasi-geografis aktif. Replika-geografis dapat berada di wilayah yang sama atau berbeda dengan database Hyperscale yang ada.

Tentukan parameter -ZoneRedundant untuk mengaktifkan redundansi zona pada database sekunder Hyperscale Anda. Database sekunder harus memiliki setidaknya 1 replika high availability dan penyimpanan cadangan zona-redundan harus ditentukan.

Untuk membuat database redundan zona menggunakan Azure PowerShell, gunakan contoh perintah berikut:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

Membuat database Hyperscale redundan zona dengan membuat salinan database

Untuk membuat zona database Hyperscale yang sudah ada menjadi redundan, gunakan Azure PowerShell atau Azure CLI untuk membuat database Hyperscale zona redundan menggunakan salinan database. Salinan database dapat berada di wilayah yang sama atau berbeda dengan database Hyperscale yang ada.

Tentukan parameter -ZoneRedundant guna mengaktifkan redundansi zona untuk salinan database Hyperscale Anda. Salinan database harus memiliki setidaknya 1 replika high availability dan penyimpanan cadangan zona-redundan harus ditentukan.

Untuk membuat database redundan zona menggunakan Azure PowerShell, gunakan contoh perintah berikut:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone

master ketersediaan redundan zona database

Dalam Azure SQL Database, server adalah konstruksi logis yang bertindak sebagai titik administratif pusat untuk kumpulan database. Di tingkat server, Anda dapat mengelola login, autentikasi Azure Active Directory, aturan firewall, aturan audit, kebijakan deteksi ancaman, dan grup failover otomatis. Data yang terkait dengan beberapa fitur ini, seperti login dan aturan firewall, disimpan dalam master database. Demikian pula, data untuk beberapa DMV, misalnya sys.resource_stats, juga disimpan dalam master database.

Ketika database dengan konfigurasi zona-redundan dibuat di server logis, master database yang terkait dengan server juga secara otomatis dibuat zona-redundan. Ini memastikan bahwa dalam pemadaman zona, aplikasi yang menggunakan database tetap tidak terpengaruh karena fitur yang bergantung pada master database, seperti login dan aturan firewall, masih tersedia. master Membuat zona-redundan database adalah proses asinkron dan akan memakan waktu untuk menyelesaikan di latar belakang.

Ketika tidak ada database di server yang zona-redundan, atau ketika Anda membuat server kosong, maka database yang master terkait dengan server tidak zona-redundan.

Anda dapat menggunakan Azure PowerShell atau Azure CLI atau REST API untuk memeriksa ZoneRedundant properti untuk master database:

Gunakan perintah contoh berikut untuk memeriksa nilai properti "ZoneRedundant" untuk master database.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Pemulihan Database Dipercepat (ADR)

Accelerated Database Recovery (ADR) adalah fitur mesin database yang sangat meningkatkan ketersediaan database, terutama di hadapan transaksi yang berjalan lama. ADR saat ini tersedia untuk Azure SQL Database, Azure SQL Managed Instance, dan Azure Synapse Analytics.

Menguji ketahanan kesalahan aplikasi

Ketersediaan tinggi adalah bagian mendasar dari platform SQL Database dan SQL Managed Instance yang berfungsi secara transparan untuk aplikasi database Anda. Namun, kami menyadari bahwa Anda mungkin ingin menguji bagaimana operasi kegagalan otomatis yang dimulai selama acara yang direncanakan atau tidak direncanakan akan berdampak pada aplikasi sebelum Anda menyebarkannya ke produksi. Anda dapat memicu kegagalan secara manual dengan memanggil API khusus untuk memulai ulang database, kumpulan elastis, dan instans terkelola. Dalam kasus database atau kumpulan elastis General Purpose tanpa server atau diprovisikan yang bersifat redundan zona, panggilan API akan mengalihkan koneksi klien ke primer baru di Zona Ketersediaan yang berbeda dari Zona Ketersediaan primer lama. Jadi, selain menguji dampak kegagalan pada sesi database yang ada, Anda juga dapat memverifikasi apakah itu mengubah kinerja menyeluruh karena adanya perubahan latensi jaringan. Karena operasi hidupkan ulang bersifat mengganggu dan sejumlah besar operasi tersebut dapat membebani platform, hanya satu panggilan kegagalan yang diizinkan setiap 15 menit untuk setiap database, kumpulan elastis, atau instans terkelola.

Kegagalan dapat dimulai menggunakan PowerShell, REST API, atau Azure CLI:

Jenis penyebaran PowerShell REST API Azure CLI
Database Invoke-AzSqlDatabaseFailover Kegagalan database az rest dapat digunakan untuk memanggil panggilan REST API dari Azure CLI
Kumpulan elastis Invoke-AzSqlElasticPoolFailover Kegagalan kumpulan elastis az rest dapat digunakan untuk memanggil panggilan REST API dari Azure CLI
Instans Terkelola SQL Invoke-AzSqlInstanceFailover SQL Managed Instance - Failover failover az sql mi dapat digunakan untuk meminta panggilan REST API dari CLI Azure

Penting

Perintah Kegagalan tidak tersedia untuk replika sekunder database Hyperscale yang dapat dibaca.

Kesimpulan

Azure SQL Database dan Azure SQL Managed Instance memiliki solusi ketersediaan tinggi bawaan yang terintegrasi secara mendalam dengan platform Azure. Ini tergantung pada Service Fabric untuk deteksi dan pemulihan kegagalan pada penyimpanan Azure Blob untuk perlindungan data dan pada Zona Ketersediaan untuk toleransi kesalahan yang lebih tinggi (seperti yang disebutkan sebelumnya dalam dokumen yang belum berlaku untuk Azure SQL Managed Instance). Selain itu, SQL Database dan SQL Managed Instance memanfaatkan teknologi grup ketersediaan Always On dari instans SQL Server untuk replikasi dan failover. Kombinasi teknologi ini memungkinkan aplikasi untuk sepenuhnya mewujudkan manfaat dari model penyimpanan campuran dan mendukung SLA yang paling intensif.

Langkah berikutnya