Tanya Jawab Umum Azure SQL Database Hyperscale

Database Hyperscale adalah database dalam SQL Database yang didukung oleh teknologi penyimpanan skala besar Hyperscale. Database Hyperscale mendukung hingga 100 TB data dan menyediakan throughput dan performa tinggi, serta penskalaan cepat untuk beradaptasi dengan persyaratan beban kerja. Koneksi ivitas, pemrosesan kueri, fitur mesin database, dan sebagainya, berfungsi seperti database lain di Azure SQL Database.

Tingkat layanan Hyperscale hanya tersedia untuk database tunggal yang menggunakan model pembelian berbasis vCore di Azure SQL Database. Ini tidak tersedia dalam model pembelian berbasis DTU.

Tingkat layanan berbasis vCore dibedakan berdasarkan ketersediaan database dan jenis penyimpanan, performa, dan ukuran penyimpanan maksimum, seperti yang dijelaskan dalam perbandingan batas sumber daya.

Tingkat layanan Hyperscale ditujukan untuk semua pelanggan yang membutuhkan performa dan ketersediaan lebih tinggi, pencadangan dan pemulihan cepat, dan/atau penyimpanan cepat serta skalabilitas komputasi. Termasuk pelanggan yang beralih ke cloud untuk memodernisasi aplikasi mereka dan pelanggan yang sudah menggunakan tingkat layanan lain di Azure SQL Database. Dengan Hyperscale, Anda mendapatkan:

• Ukuran database hingga 100 TB.
• Pencadangan database cepat terlepas dari ukuran database (cadangan didasarkan pada rekam jepret penyimpanan).
• Pemulihan database cepat terlepas dari ukuran database (pemulihan berasal dari rekam jepret penyimpanan).
• Throughput log yang lebih tinggi terlepas dari ukuran database dan jumlah vCore.
• Baca Peluasan skala menggunakan satu atau beberapa replika baca-saja, digunakan untuk membongkar beban kerja baca-saja atau sebagai database siaga panas.
• Meningkatkan skala komputasi dengan cepat, dalam waktu yang konstan, agar lebih mampu untuk mengakomodasi beban kerja yang berat dan kemudian menurunkan skala, dalam waktu yang konstan. Operasi penskalaan membutuhkan waktu satu digit menit untuk komputasi yang disediakan, dan kurang dari satu detik untuk komputasi tanpa server, terlepas dari ukuran database.

Tingkat layanan Hyperscale tersedia di semua wilayah tempat Azure SQL Database tersedia.

Ya. Untuk informasi selengkapnya dan batas jumlah database setiap server, lihat Batas sumber daya SQL Database untuk database tunggal dan kumpulan di server.

Arsitektur Hyperscale memberikan performa dan throughput tinggi sekaligus mendukung ukuran database yang besar.

Hyperscale memberikan skalabilitas yang cepat berdasarkan permintaan beban kerja Anda.

• Meningkatkan/Menurunkan Skala

  Dengan Hyperscale, Anda dapat meningkatkan ukuran komputasi utama pada aspek sumber daya seperti CPU dan memori, lalu menurunkan skala, dalam waktu konstan. Karena penyimpanan bersifat jarak jauh, meningkatkan dan menurunkan skala bukanlah ukuran operasi data.

  Dukungan untuk komputasi tanpa server menyediakan peningkatan dan penurunan skala otomatis, dan komputasi ditagih berdasarkan penggunaan.

• Mempersempit/Memperluas Skala

  Dengan Hyperscale, Anda dapat menggunakan tiga jenis replika sekunder untuk memenuhi persyaratan peluasan skala, ketersediaan tinggi, dan replikasi geografis. Drive ini termasuk:

  • Hingga empat replika ketersediaan tinggi yang memiliki ukuran komputasi yang sama dengan yang utama. Ini berfungsi sebagai replika siaga panas untuk dengan cepat melakukan failover dari primer. Anda juga dapat menggunakannya untuk mengosongkan beban kerja pembacaan dari yang utama.
  • Hingga 30 replika bernama yang memiliki ukuran komputasi yang sama atau berbeda dari replika utama, untuk memenuhi berbagai skenario peluasan skala baca.
  • Replika geo di wilayah Azure yang berbeda untuk melindungi dari pemadaman regional dan untuk mengaktifkan peluasan skala pembacaan geografis.

Ya, Anda bisa.

Tidak, model pemrograman aplikasi Anda tetap sama seperti database MSSQL lainnya. Gunakan string koneksi Anda seperti biasa dan cara reguler lainnya untuk berinteraksi dengan database Hyperscale Anda. Setelah aplikasi Anda menggunakan database Hyperscale, aplikasi Anda dapat memanfaatkan fitur seperti replika sekunder.

Pada replika utama, tingkat isolasi transaksi default adalah RCSI (Read Committed Snapshot Isolation). Pada replika sekunder Peluasan Skala Baca, tingkat isolasi default adalah Rekam Jepret. Ini sama seperti di database Azure SQL lainnya.

Dengan harga baru yang disederhanakan berlaku sejak 15 Desember 2023, harga komputasi untuk database Hyperscale yang baru dibuat, semua database Hyperscale tanpa server dan semua kumpulan elastis Hyperscale telah berkurang. Dengan harga baru yang disederhanakan, Tidak perlu menerapkan Azure Hybrid Benefit (AHB) untuk mendapatkan penghematan yang setara. Azure Hybrid Benefit (AHB) hanya dapat diterapkan ke database tunggal Hyperscale yang lebih lama (dibuat sebelum 15 Desember 2023) hyperscale dengan komputasi yang disediakan. Untuk database lama tersebut, AHB hanya berlaku hingga Desember 2026, setelah itu database tersebut juga akan ditagih sesuai harga baru yang disederhanakan. Untuk informasi selengkapnya, lihat Blog harga Hyperscale dan Azure SQL Database Hyperscale - harga yang lebih rendah dan disederhanakan!.

Hyperscale berfungsi dengan baik untuk semua jenis beban kerja, termasuk beban kerja OLTP, Hibrid (HTAP), dan Analitis (pasar data).

Jika saat ini Anda menjalankan kueri analitik interaktif menggunakan SQL Server sebagai gudang data, Hyperscale adalah opsi yang bagus karena Anda dapat menghosting gudang data kecil dan menengah (seperti beberapa TB hingga 100 TB) dengan biaya yang lebih rendah, dan Anda dapat memigrasikan beban kerja gudang data SQL Server Anda ke Hyperscale dengan perubahan kode T-SQL minimal.

Jika Anda menjalankan analitik data dalam skala besar dengan kueri kompleks dan tingkat penyerapan berkelanjutan yang lebih tinggi dari 100 MB/dtk atau menggunakan Gudang Data Paralel (PDW), Teradata, atau gudang data Pemrosesan Paralel Besar-Besaran (MPP), Azure Synapse Analytics, atau Microsoft Fabric bisa menjadi pilihan terbaik.

Tidak untuk saat ini. Namun, Anda dapat menskalakan komputasi dan jumlah replika turun untuk mengurangi biaya selama waktu nonpeak, atau menggunakan tanpa server untuk menskalakan komputasi secara otomatis berdasarkan penggunaan.

Untuk beban kerja pembacaan, Anda dapat membuat replika bernama dengan ukuran komputasi yang lebih tinggi (lebih banyak core dan memori) daripada yang utama. Untuk informasi selengkapnya tentang ukuran komputasi yang tersedia, lihat Penyimpanan Hyperscale dan ukuran komputasi.

Untuk beban kerja pembacaan, hal ini dapat dicapai dengan menggunakan replika bernama.

Anda dapat menskalakan jumlah replika sekunder high availability antara 0 dan 4 menggunakan portal Microsoft Azure atau REST API. Selain itu, Anda dapat membuat hingga 30 replika bernama untuk banyak skenario peluasan skala pembacaan.

Dalam database Hyperscale, ketahanan data disediakan pada tingkat penyimpanan. Anda hanya perlu satu replika (utama) untuk memberikan ketahanan. Ketika replika komputasi mati, replika baru dibuat secara otomatis tanpa kehilangan data.

Namun, jika hanya ada replika utama, diperlukan waktu satu atau dua menit untuk membuat replika baru setelah failover, vs. detik dalam kasus ketika replika sekunder HA tersedia. Replika baru awalnya akan memiliki cache dingin, yang dapat mengakibatkan latensi penyimpanan yang lebih tinggi dan mengurangi performa kueri segera setelah failover.

Untuk aplikasi penting misi yang memerlukan ketersediaan tinggi dengan dampak failover minimal, Anda harus menyediakan setidaknya satu replika sekunder HA untuk memastikan replika siaga panas tersedia untuk berfungsi sebagai target failover.

100 TB.

Di Hyperscale, log transaksi praktis tidak terbatas, dengan batasan bahwa bagian aktif log tidak boleh melebihi 1 TB. Bagian aktif log dapat tumbuh karena transaksi yang berjalan lama, atau karena pemrosesan Change Data Capture tidak mengikuti tingkat perubahan data. Hindari transaksi panjang dan besar yang tidak perlu untuk tetap di bawah batas ini. Selain pembatasan ini, Anda tidak perlu khawatir kehabisan ruang log pada sistem yang memiliki throughput log tinggi. Namun, laju pembuatan log mungkin akan dibatasi saat terus menulis beban kerja secara agresif. Tingkat pembuatan log berkelanjutan tertinggi adalah 100 MB/dtk.

Database tempdb Anda berada di penyimpanan SSD lokal dan berukuran proporsional dengan ukuran komputasi (jumlah core) yang Anda sediakan. Ukuran tempdb tidak dapat dikonfigurasi dan dikelola untuk Anda. Untuk menentukan ukuran tempdb maksimum untuk database Anda, lihat Penyimpanan dan ukuran komputasi Hyperscale.

Ukuran database Anda secara otomatis bertambah saat Anda menyisipkan/menyerap lebih banyak data.

10 GB. Database Hyperscale dibuat dengan ukuran awal 10 GB dan tumbuh sesuai kebutuhan dalam potongan 10 GB.

Setiap file data tumbuh sebesar 10 GB. Beberapa file data dapat tumbuh secara bersamaan.

Di Hyperscale, file data disimpan di penyimpanan standar Azure. Data sepenuhnya disimpan di penyimpanan SSD lokal, di server halaman yang bersifat jarak jauh untuk menghitung replika. Selain itu, replika komputasi memiliki cache data pada SSD lokal dan memori, untuk mengurangi frekuensi pengambilan data dari server halaman jarak jauh.

Tidak. File data ditambahkan secara otomatis ke grup file PRIMARY. Alasan umum untuk membuat grup file tambahan tidak berlaku di arsitektur penyimpanan Hyperscale, atau di Azure SQL Database secara lebih luas.

Tidak.

Tidak untuk saat ini.

Ya, sama seperti di database Azure SQL DB lainnya. Ini termasuk pemadatan baris, halaman, dan penyimpanan kolom.

Ya. Halaman data yang terkait dengan tabel tertentu dapat disebar ke beberapa file data, yang semuanya merupakan bagian dari grup file yang sama. Mesin database MSSQL menggunakan strategi pengisian proporsional untuk mendistribusikan data melalui file data.

Ya. Anda bisa memindahkan database yang sudah ada di Azure SQL Database ke Hyperscale. Untuk bukti konsep (POC), kami sarankan Anda membuat salinan database Anda dan memigrasikan salinan tersebut ke Hyperscale.

Waktu yang diperlukan untuk memindahkan database yang ada ke Hyperscale terdiri dari waktu untuk menyalin data, dan waktu untuk memutar ulang perubahan yang dibuat di database sumber saat menyalin data. Waktu penyalinan data disesuaikan dengan ukuran data. Waktu untuk memutar ulang perubahan akan lebih singkat jika pemindahan dilakukan selama periode aktivitas tulis rendah.

Dapatkan kode sampel untuk memigrasikan Azure SQL Database yang ada ke Hyperscale di portal Azure, Azure CLI, PowerShell, dan Transact-SQL di Memigrasikan database yang sudah ada ke Hyperscale.

Migrasi terbalik ke tingkat layanan Tujuan Umum memungkinkan pelanggan yang baru saja memigrasikan database yang ada di Azure SQL Database ke tingkat layanan Hyperscale untuk membatalkan migrasi, jika Hyperscale tidak memenuhi kebutuhan mereka. Sementara migrasi terbalik dimulai oleh perubahan tingkat layanan, pada dasarnya ini merupakan operasi ukuran data antara arsitektur yang berbeda. Demikian pula dengan migrasi ke Hyperscale, migrasi terbalik lebih cepat jika dilakukan selama periode aktivitas tulis rendah. Pelajari batasan untuk migrasi balik.

Jika sebelumnya Anda telah memigrasikan Azure SQL Database yang ada ke tingkat layanan Hyperscale, Anda dapat melakukan migrasi terbalik ke tingkat layanan Tujuan Umum dalam waktu 45 hari sejak migrasi awal ke Hyperscale. Jika Anda ingin memigrasikan database ke tingkat layanan lain, seperti Business Critical, lakukan migrasi balik terlebih dahulu ke tingkat layanan Tujuan Umum, lalu modifikasi tingkat layanan. Migrasi terbalik adalah ukuran operasi data.

Database yang dibuat di tingkat layanan Hyperscale tidak dapat dipindahkan ke tingkat layanan lain.

Pelajari cara membalikkan migrasi dari Hyperscale, termasuk batasan untuk migrasi terbalik dan kebijakan cadangan yang terpengaruh.

Ya. Beberapa fitur Azure SQL Database belum didukung di Hyperscale. Jika beberapa fitur ini diaktifkan untuk database Anda, migrasi ke Hyperscale dapat diblokir, atau fitur-fitur ini akan berhenti berfungsi setelah migrasi. Kami memperkirakan batasan ini bersifat sementara. Untuk detailnya, lihat Batasan yang diketahui.

Ya. Anda dapat menggunakan banyak teknologi migrasi yang ada untuk bermigrasi ke Hyperscale, termasuk replikasi transaksional, dan teknologi pemindahan data lainnya (Salin Massal, Azure Data Factory, Azure Databricks, SSIS). Lihat juga Azure Database Migration Service, yang mendukung banyak skenario migrasi.

Waktu henti untuk migrasi ke Hyperscale sama dengan waktu henti saat Anda melakukan migrasi database ke tingkat layanan Azure SQL Database lainnya. Anda dapat menggunakan replikasi transaksional untuk meminimalkan migrasi waktu henti untuk database yang berukuran hingga beberapa TB. Untuk database yang sangat besar (10+ TB), Anda dapat mempertimbangkan untuk menerapkan proses migrasi menggunakan Azure Data Factory, Spark, atau teknologi pemindahan data massal lainnya.

Hyperscale mampu menyerap 100 MB/dtk data baru/ubahan, tetapi waktu yang diperlukan untuk memindahkan data ke database di Azure SQL Database juga dipengaruhi oleh throughput jaringan yang tersedia, kecepatan baca sumber, dan tujuan tingkat layanan database target.

Anda dapat membuat aplikasi klien membaca data dari Azure Storage dan memuat data ke dalam database Hyperscale (seperti yang bisa Anda lakukan dengan database lain di Azure SQL Database). Saat ini Polybase tidak didukung di Azure SQL Database. Sebagai alternatif untuk memberikan pemuatan cepat, Anda dapat menggunakan Azure Data Factory, atau menggunakan pekerjaan Spark di Azure Databricks dengan konektor Spark untuk SQL. Konektor Spark ke SQL mendukung penyisipan massal.

Dimungkinkan juga untuk membaca data secara massal dari penyimpanan Azure Blob Storage menggunakan BULK INSERT atau OPENROWSET: Contoh Akses Massal ke Data di Azure Blob Storage.

Pemulihan sederhana atau model pengelogan massal tidak didukung di Hyperscale. Model pemulihan penuh diperlukan untuk memberikan ketersediaan tinggi dan pemulihan pada waktu tertentu. Namun, arsitektur log Hyperscale memberikan tingkat penyerapan data yang lebih baik dibandingkan dengan tingkat layanan Azure SQL Database lainnya.

Tidak. Hyperscale menggunakan arsitektur multi-pemrosesan simetris (SMP) dan bukan pemrosesan paralel besar (MPP) atau arsitektur multi-master. Anda hanya dapat membuat beberapa replika untuk memperluas skala beban kerja baca-saja.

Ya. Azure Database Migration Service mendukung banyak skenario migrasi.

Lihat SLA untuk Azure SQL Database. Sebaiknya tambahkan replika sekunder high availability untuk beban kerja penting. Hal ini memberikan failover yang lebih cepat, dan mengurangi potensi dampak performa segera setelah failover.

Ya.

Ya, Hyperscale mendukung konfigurasi zona redundan. Setidaknya satu replika sekunder HA dan penggunaan penyimpanan zona-redundan atau geo-zona-redundan diperlukan untuk mengaktifkan konfigurasi zona redundan untuk Hyperscale. Dukungan untuk replika bernama Hyperscale zona redundan saat ini dalam pratinjau.

Ya. Kumpulan elastis Hyperscale saat ini dalam pratinjau. Kumpulan elastis Hyperscale zona redundan juga saat ini dalam pratinjau.

Tidak ada cadangan log transaksional yang lengkap, berbeda, dan tradisional untuk database Hyperscale. Sebagai gantinya, terdapat snapshot penyimpanan reguler dari file data, dengan irama snapshot terpisah untuk setiap file. Log transaksi yang dihasilkan disimpan apa adanya untuk periode retensi yang dikonfigurasi. Pada waktu pemulihan, catatan log transaksi yang relevan diterapkan ke snapshot penyimpanan yang dipulihkan. Terlepas dari irama snapshot, hal ini menghasilkan database yang konsisten secara transaksional tanpa kehilangan data pada titik waktu yang ditentukan dalam periode retensi. Akibatnya, cadangan database di Hyperscale berjalan terus menerus.

Ya.

RPO untuk pemulihan titik waktu adalah 0 mnt. Sebagian besar operasi pemulihan titik waktu selesai dalam 60 menit terlepas dari ukuran database. Waktu pemulihan bisa lebih lama untuk database yang lebih besar, dan jika database mengalami aktivitas penulisan yang signifikan sebelum dan hingga titik pemulihan tepat waktu. Mengubah redundansi penyimpanan saat mengeluarkan pemulihan dapat mengakibatkan waktu pemulihan yang lebih lama karena pemulihan adalah ukuran data dan karenanya waktu akan sebanding dengan ukuran database.

Tidak. Cadangan dikelola oleh subsistem penyimpanan, dan menggunakan rekam jepret penyimpanan. Mereka tidak memengaruhi beban kerja pengguna.

Ya. Pemulihan geo didukung penuh jika penyimpanan geo-redundan digunakan. Ini adalah default untuk database baru. Tidak seperti pemulihan berdasar waktu, pemulihan geo memerlukan operasi ukuran data. File data disalin secara paralel, sehingga durasi operasi ini utamanya tergantung pada ukuran file terbesar dalam database, bukan pada ukuran database total. Waktu pemulihan geo akan jauh lebih singkat jika database dipulihkan di wilayah Azure yang dipasangkan dengan wilayah database sumber.

Ya. Replikasi geografis dapat disiapkan untuk database Hyperscale.

Tidak. Format penyimpanan untuk database Hyperscale berbeda dari versi SQL Server yang dirilis, dan Anda tidak mengontrol cadangan atau memiliki akses ke cadangan tersebut. Untuk mengeluarkan data Anda dari database Hyperscale, Anda dapat mengekstrak data menggunakan teknologi pergerakan data apa pun, yaitu, Azure Data Factory, Azure Databricks, SSIS, dll.

Ya. Berlaku mulai 4 Mei 2022, pencadangan untuk semua database baru dikenakan biaya berdasarkan penyimpanan cadangan yang digunakan dan redundansi penyimpanan yang dipilih pada tarif yang diambil di halaman harga Azure SQL Database. Untuk database Hyperscale yang dibuat sebelum 4 Mei 2022, cadangan hanya akan dikenakan biaya jika retensi cadangan diatur menjadi lebih besar dari tujuh hari. Untuk mempelajari selengkapnya, lihat Pencadangan Hyperscale dan redundansi penyimpanan.

Detail tentang cara mengukur ukuran penyimpanan cadangan tercantum di Pencadangan Otomatis.

Untuk menentukan tagihan penyimpanan cadangan Anda, ukuran penyimpanan cadangan dihitung secara berkala, dan dikalikan dengan tingkat penyimpanan cadangan dan jumlah jam sejak perhitungan terakhir. Untuk memperkirakan tagihan cadangan Anda selama jangka waktu tertentu, kalikan ukuran penyimpanan cadangan yang dapat ditagih untuk setiap jam dalam periode tersebut dengan tarif penyimpanan cadangan, dan jumlahkan semua jumlah per jam. Guna mengkueri metrik Azure Monitor yang relevan untuk beberapa interval per jam secara terprogram, gunakan REST API Azure Monitor. Penagihan cadangan di tingkat komputasi tanpa server sama seperti di tingkat komputasi yang disediakan.

Biaya pencadangan akan lebih tinggi untuk beban kerja yang menambah, mengubah, atau menghapus data dalam jumlah besar dalam database. Sebaliknya, beban kerja yang sebagian besar bersifat baca-saja mungkin memiliki biaya cadangan yang lebih kecil.

Detail tentang cara meminimalkan biaya penyimpanan cadangan tercantum di Pencadangan Otomatis.

Batas throughput log transaksi diatur ke 100 MB/dtk untuk semua ukuran komputasi Hyperscale. Kemampuan untuk mencapai tingkat ini tergantung pada beberapa faktor, termasuk tetapi tidak terbatas pada jenis beban kerja, konfigurasi dan performa klien, dan memiliki kapasitas komputasi yang memadai pada replika komputasi utama untuk menghasilkan catatan log pada tingkat ini.

Latensi IOPS dan IO akan bervariasi tergantung pada pola beban kerja. Jika data yang diakses ditembolok di RBPEX pada replika komputasi, Anda akan melihat performa IO serupa seperti pada tingkat Layanan Business Critical atau Premium.

Tidak. Komputasi dipisahkan dari lapisan penyimpanan. Ini menghilangkan dampak performa cadangan.

Karena penyimpanan dibagikan dan tidak ada replikasi fisik langsung yang terjadi antara replika komputasi primer dan sekunder, throughput pada replika utama tidak akan terpengaruh secara langsung dengan menambahkan replika sekunder. Namun, beban kerja tulis berkelanjutan dan agresif mungkin dibatasi pada primer untuk memungkinkan log berlaku pada replika sekunder dan server halaman untuk mengejar ketinggalan. Hal ini menghindari performa pembacaan yang buruk pada replika sekunder dan pemulihan yang lama setelah failover ke replika sekunder high availability.

Ya. Namun, sama seperti di database Azure SQL DB lainnya, koneksi mungkin dihentikan oleh kesalahan sementara yang sangat jarang, yang dapat membatalkan kueri yang berjalan lama dan mengembalikan transaksi. Salah satu penyebab kesalahan sementara adalah ketika sistem dengan cepat menggeser database ke node komputasi yang berbeda untuk memastikan ketersediaan sumber daya komputasi dan penyimpanan yang berkelanjutan, atau untuk melakukan pemeliharaan terencana. Sebagian besar peristiwa konfigurasi ulang selesai dalam waktu kurang dari 10 detik. Aplikasi yang terhubung ke database Anda harus dibangun untuk mengantisipasi dan mentolerir kesalahan sementara yang jarang terjadi ini dengan menerapkan logika coba lagi. Selain itu, pertimbangkan untuk mengonfigurasi jendela pemeliharaan yang sesuai dengan jadwal beban kerja Anda untuk menghindari kesalahan sementara karena pemeliharaan terencana.

Untuk sebagian besar masalah performa, terutama yang tidak berakar pada performa penyimpanan, langkah-langkah diagnostik dan pemecahan masalah SQL umum berlaku. Untuk diagnostik penyimpanan khusus Hyperscale, lihat diagnostik pemecahan masalah performa SQL Hyperscale.

Jumlah maksimum memori yang dapat ditingkatkan oleh database tanpa server adalah 3 GB/vCore kali jumlah maksimum vCore yang dikonfigurasi dibandingkan dengan lebih dari 5 GB/vCore kali jumlah vCore yang sama dalam komputasi yang disediakan. Tinjau batas sumber daya Hyperscale tanpa server untuk detailnya.

Meningkatkan atau menurunkan skala di tingkat komputasi yang disediakan biasanya memakan waktu hingga 2 menit, terlepas dari ukuran data. Di tingkat komputasi tanpa server, di mana komputasi secara otomatis diskalakan berdasarkan permintaan beban kerja, waktu penskalaan biasanya subdetik, tetapi kadang-kadang dapat memakan waktu selama saat menskalakan komputasi yang disediakan.

Tidak. Database tetap online selama operasi peningkatan atau penurunan skala.

Penskalaan komputasi yang disediakan ke atas atau ke bawah menghasilkan koneksi yang dihilangkan saat failover terjadi di akhir operasi penskalaan. Dalam komputasi tanpa server, penskalaan otomatis biasanya tidak mengakibatkan koneksi terputus, tetapi dapat terjadi sesekali. Menambahkan atau menghapus replika sekunder tidak mengakibatkan penurunan koneksi pada replika primer.

Penskalaan dalam komputasi yang disediakan dilakukan oleh pengguna akhir. Penskalaan otomatis dalam komputasi tanpa server dilakukan oleh layanan.

Ya. Database tempdb dan ukuran cache RBPEX pada simpul komputasi ditingkatkan secara otomatis saat jumlah inti ditingkatkan. Untuk detailnya, lihat Penyimpanan dan ukuran komputasi Hyperscale.

Tidak. Hanya replika komputasi utama yang menerima permintaan baca/tulis. Replika komputasi sekunder hanya menerima permintaan baca-saja.

Hyperscale mendukung replika Ketersediaan Tinggi (HA), replika bernama, dan geo-replika. Lihat replika sekunder Hyperscale untuk detailnya.

Antara 0 hingga 4. Jika Anda ingin menyesuaikan jumlah replika, Anda dapat melakukannya menggunakan portal Microsoft Azure atau REST API.

Anda dapat terhubung ke replika komputasi baca-saja tambahan ini dengan mengatur properti ApplicationIntent di string koneksi Anda ke ReadOnly. Setiap koneksi yang ditandai dengan ReadOnly secara otomatis dirutekan ke salah satu replika sekunder HA, jika ada. Untuk detailnya, lihat Menggunakan replika baca-saja untuk memindahkan beban kerja kueri baca-saja.

Anda dapat menjalankan kueri T-SQL berikut: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Hasilnya adalah READ_ONLY jika Anda terhubung ke replika sekunder baca-saja, dan READ_WRITE jika Anda terhubung ke replika utama. Konteks database harus diatur ke nama database Anda, bukan ke master database.

Tidak. Anda hanya dapat terhubung ke replika sekunder high availability dengan menentukan ApplicationIntent=ReadOnly. Namun, Anda dapat menggunakan titik akhir khusus untuk replika bernama.

Tidak. Koneksi baru dengan niat baca-saja dialihkan ke replika sekunder high availability arbitrer.

Tidak dalam tingkat komputasi yang disediakan. Replika sekunder high availability digunakan sebagai target failover high availability, sehingga replika sekunder high availability harus memiliki konfigurasi yang sama seperti yang replika utama agar memberikan performa yang diharapkan setelah failover. Dalam tanpa server, komputasi diskalakan secara otomatis untuk setiap replika KETERSEDIAAN TINGGI berdasarkan permintaan beban kerja individualnya. Setiap sekunder HA masih dapat menskalakan otomatis ke inti maks yang dikonfigurasi untuk mengakomodasi peran pasca-failover-nya. Replika bernamamemberikan kemampuan untuk menskalakan setiap replika secara mandiri.

Tidak. Database Anda tempdb dikonfigurasi berdasarkan ukuran komputasi yang disediakan; replika sekunder HA Anda berukuran sama, termasuk tempdb, sebagai komputasi utama. Pada replika bernama, tempdb diukur sesuai dengan ukuran komputasi replika, sehingga bisa lebih kecil atau lebih besar dari tempdb pada replika utama.

Tidak. Database Hyperscale memiliki penyimpanan bersama, artinya semua replika komputasi melihat tabel, indeks, dan objek database lain yang sama. Jika Anda menginginkan indeks tambahan yang dioptimalkan untuk dibaca di sekunder, Anda harus menambahkannya di primer. Anda masih bisa membuat tabel sementara (nama tabel diawali dengan # atau ##) di setiap replika sekunder untuk menyimpan data sementara. Tabel sementara bersifat baca-tulis.

Latensi data sejak transaksi dilakukan pada primer hingga waktu yang dapat dibaca pada sekunder tergantung pada tingkat pembuatan log saat ini, ukuran transaksi, beban pada replika, dan faktor lainnya. Latensi data umum untuk transaksi kecil berada dalam puluhan milidetik, namun tidak ada batas atas pada latensi data. Data pada replika sekunder tertentu selalu konsisten secara transaksi, sehingga transaksi yang lebih besar membutuhkan waktu lebih lama untuk disebarkan. Namun, pada titik waktu tertentu latensi data dan status database mungkin berbeda untuk replika sekunder yang berbeda. Beban kerja yang perlu segera membaca data tersebut harus berjalan pada replika utama.

Tidak, replika bernama tidak bisa digunakan sebagai target failover untuk replika utama. Tambahkan replika HA untuk tujuan itu.

Karena setiap replika bernama dapat memiliki tujuan tingkat layanan yang berbeda dan dengan demikian digunakan untuk kasus penggunaan yang berbeda, tidak ada cara bawaan untuk mengarahkan lalu lintas baca-saja yang dikirim ke primer ke sekumpulan replika bernama. Misalnya, Anda dapat memiliki delapan replika bernama, dan Anda mungkin ingin mengarahkan beban kerja OLTP hanya ke replika bernama 1 hingga 4, sementara beban kerja analitik Power BI menggunakan replika bernama 5 dan 6, dan beban kerja ilmu data menggunakan replika 7 dan 8. Bergantung pada alat atau bahasa pemrograman mana yang Anda gunakan, strategi untuk mendistribusikan beban kerja tersebut dapat bervariasi. Untuk contoh pembuatan solusi perutean beban kerja agar backend REST dapat diskalakan, tinjau sampel peluasan skala OLTP.

Tidak, karena replika bernama menggunakan server halaman yang sama dari replika utama, mereka harus berada di wilayah yang sama.

Replika bernama tidak dapat memengaruhi ketersediaan replika utama. Replika bernama dalam keadaan normal tidak mungkin memengaruhi performa replika utama, tetapi dapat terjadi jika ada beban kerja intensif yang berjalan. Sama seperti replika HA, replika bernama tetap sinkron dengan replika utama melalui layanan log transaksi. Jika tidak dapat menggunakan log transaksi cukup cepat karena alasan apa pun, replika bernama akan mulai meminta ke replika utama untuk memperlambat (membatasi) pembuatan lognya, sehingga dapat mengejar ketertinggalan. Meskipun perilaku ini tidak akan berdampak pada ketersediaan utama, perilaku ini dapat memengaruhi performa beban kerja tulis pada primer. Untuk menghindari situasi ini, pastikan replika bernama milik Anda memiliki ruang kepala sumber daya yang cukup – terutama CPU – untuk memproses log transaksi tanpa penundaan. Misalnya, jika primer memproses banyak perubahan data, disarankan untuk memiliki replika bernama dengan setidaknya Tujuan Tingkat Layanan yang sama dengan yang utama untuk menghindari menjenuhkan CPU pada replika, dan dengan demikian memaksa primer untuk melambat.

Replika bernama masih akan tersedia untuk akses baca-saja, seperti biasa.

Secara default, replika bernama tidak memiliki replika KETERSEDIAAN TINGGI sendiri. Replika bernama failover memerlukan pembuatan replika baru terlebih dahulu, biasanya membutuhkan waktu sekitar 1-2 menit. Namun, replika bernama juga bisa memanfaatkan ketersediaan yang lebih tinggi dan failover yang lebih singkat disediakan oleh replika HA. Untuk menambahkan replika HA untuk replika bernama, Anda dapat menggunakan parameter ha-replicas dengan AZ CLI, atau parameter HighAvailabilityReplicaCount dengan PowerShell, atau properti highAvailabilityReplicaCount dengan REST API. Jumlah replika HA dapat diatur selama pembuatan replika bernama dan dapat diubah - hanya melalui AZ CLI, PowerShell, atau REST API – kapan saja setelah replika bernama dibuat. Harga replika HA untuk replika bernama sama dengan replika HA untuk database reguler.

Konten terkait

Untuk informasi selengkapnya tentang tingkat layanan Hyperscale, lihat Tingkat layanan Hyperscale.