Bagikan melalui

Replika sekunder Hyperscale

  • Artikel

Berlaku untuk: Azure SQL Database

Seperti yang dijelaskan dalam Arsitektur fungsi terdistribusi, Azure SQL Database Hyperscale memiliki dua jenis simpul komputasi yang berbeda yang juga disebut sebagai replika:

Replika sekunder selalu baca-saja, dan dapat merupakan salah satu dari tiga jenis yang berbeda berikut:

  • Replika Ketersediaan Tinggi
  • Geo-replika
  • Replika bernama

Setiap jenis memiliki arsitektur, set fitur, tujuan, dan biaya yang berbeda. Berdasarkan fitur yang Anda butuhkan, Anda dapat menggunakan hanya satu atau bahkan ketiganya bersama-sama. Replika sekunder didukung oleh tingkat komputasi tanpa server dan yang disediakan.

Untuk tutorial tentang mengonfigurasi dan mengelola replika bernama Hyperscale, lihat:

Replika Ketersediaan Tinggi

Replika Ketersediaan Tinggi (HA) menggunakan server halaman yang sama dengan replika utama, jadi tidak diperlukan salinan data untuk menambahkan replika HA. Replika HA terutama digunakan untuk meningkatkan ketersediaan database; mereka bertindak sebagai replika siaga panas untuk tujuan failover. Jika replika utama menjadi tidak tersedia, maka lakukan failover ke salah satu replika ketersediaan tinggi yang sudah ada akan dilakukan secara otomatis dan cepat. string koneksi tidak perlu berubah; selama aplikasi failover mungkin mengalami waktu henti minimal karena koneksi aktif terputus. Seperti biasa untuk skenario ini, logika coba ulang koneksi yang tepat disarankan. Beberapa driver sudah menyediakan beberapa tingkat logika coba ulang otomatis. Jika Anda menggunakan .NET, pustaka Microsoft.Data.SqlClient terbaru menyediakan dukungan penuh asli untuk logika coba ulang otomatis yang dapat dikonfigurasi.

Replika ketersediaan tinggi menggunakan server dan nama database yang sama dengan replika utama. Tujuan Tingkat Layanan mereka juga selalu sama dengan replika utama. Replika ketersediaan tinggi tidak dapat dilihat atau dikelola sebagai sumber daya yang berdiri sendiri dari portal atau dari alat dari API apa pun.

Mungkin ada nol hingga empat replika HA. Nomor replika dapat diubah selama pembuatan database atau setelah database dibuat melalui titik akhir dan alat manajemen yang umum (misalnya: PowerShell, AZ CLI, Portal, REST API). Membuat atau menghapus replika ketersediaan tinggi tidak memengaruhi koneksi yang aktif di replika utama.

Menyambungkan ke replika KETERSEDIAAN TINGGI

Dalam database Hyperscale, argumen ApplicationIntent dalam string koneksi yang digunakan oleh klien menentukan apakah koneksi dirutekan ke replika utama baca-tulis atau ke replika ketersediaan tinggi baca-saja. Jika ApplicationIntent diatur ke ReadOnly dan database tidak memiliki replika sekunder, maka koneksi akan dirutekan ke replika utama dan akan default ke perilaku ReadWrite.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Kapasitas sumber daya pada replika ketersediaan tinggi adalah sama. Jika ada lebih dari satu replika ketersediaan tinggi, beban kerja baca-niat didistribusikan secara menyeluruh ke semua replika ketersediaan tinggi yang tersedia. Jika ada beberapa replika HA, perlu diingat bahwa setiap replika dapat memiliki latensi data yang berbeda sehubungan dengan perubahan data yang dibuat pada replika utama. Setiap replika HA menggunakan data yang sama dengan data utama pada kumpulan server halaman yang sama. Namun, cache data lokal pada setiap replika KETERSEDIAAN TINGGI mencerminkan perubahan yang dilakukan pada primer melalui layanan log transaksi, yang meneruskan rekaman log dari replika utama ke replika HA. Akibatnya, tergantung pada beban kerja yang sedang diproses oleh replika HA, aplikasi rekaman log dapat terjadi pada kecepatan yang berbeda, dan dengan demikian replika yang berbeda dapat memiliki latensi data yang berbeda relatif terhadap replika utama.

Replika bernama

Replika bernama, seperti replika HA, menggunakan server halaman yang sama dengan replika utama. Mirip dengan replika HA, tidak ada salinan data yang diperlukan untuk menambahkan replika bernama.

Ada perbedaan antara replika HA dan replika bernama:

  • Replika bernama muncul sebagai database Azure SQL reguler (baca-saja) di portal dan di panggilan API (AZ CLI, PowerShell, T-SQL).
  • Replika bernama dapat memiliki nama database yang berbeda dari replika utama, dan secara opsional terletak di server logis yang berbeda (selama berada di wilayah yang sama dengan replika utama).
  • Replika bernama memiliki Tujuan Tingkat Layanan mereka sendiri yang dapat diatur dan diubah secara independen dari replika utama.
  • Dukungan replika bernama hingga 30 replika bernama (untuk setiap replika utama).
  • Replika bernama mendukung autentikasi yang berbeda untuk setiap replika bernama dengan membuat login yang berbeda di server logis yang menghosting replika bernama.

Akibatnya, replika bernama menawarkan beberapa manfaat daripada replika HA, untuk apa masalah beban kerja baca-saja:

  • Pengguna yang terhubung ke replika bernama tidak akan mengalami pemutusan jika replika utama ditingkatkan atau diturunkan; pada saat yang sama, pengguna yang terhubung ke replika utama tidak akan terpengaruh oleh replika bernama yang meningkatkan atau menurunkan skala.
  • Beban kerja yang berjalan pada replika apa pun, utama atau bernama, tidak akan terpengaruh oleh kueri yang berjalan lama yang berjalan pada replika lain.

Tujuan utama replika bernama adalah untuk memungkinkan berbagai skenario peluasan skala baca, dan untuk meningkatkan beban kerja Hybrid Transactional and Analytical Processing (HTAP). Contoh cara membuat solusi tersebut tersedia di sini:

Selain skenario utama yang tercantum di atas, replika bernama menawarkan fleksibilitas dan elastisitas untuk juga memenuhi banyak kasus penggunaan lainnya:

  • Isolasi Akses: Anda dapat memberikan akses ke replika tertentu bernama, tetapi Anda tidak dapat melakukannya pada replika utama atau replika dengan nama yang lain.
  • Tujuan tingkat layanan yang bergantung pada beban kerja: karena replika bernama dapat memiliki tujuan tingkat layanannya sendiri, penggunaan replika bernama berbeda untuk beban kerja dan kasus penggunaan yang berbeda adalah mungkin. Misalnya, satu replika bernama dapat digunakan untuk melayani permintaan Power BI, sementara yang lain dapat digunakan untuk menyajikan data ke Apache Spark untuk tugas Ilmu Data. Masing-masing dapat memiliki tujuan dan skala tingkat layanan independen secara independen.
  • Perutean yang begrantung pada beban kerja: dengan hingga 30 replika bernama, penggunaan replika yang memiliki dalam grup sehingga aplikasi dapat diisolasi dari yang lain adalah mungkin. Misalnya, grup yang terdiri dari empat replika bernama dapat digunakan untuk melayani permintaan yang datang dari aplikasi seluler, sementara grup lain yang terdiri dari dua replika bernama dapat digunakan untuk melayani permintaan yang berasal dari aplikasi web. Pendekatan ini akan memungkinkan penyetelan kinerja dan biaya yang halus untuk setiap kelompok.

Catatan

Untuk pertanyaan umum tentang replika bernama Hyperscale, lihat FAQ Azure SQL Database Hyperscale replika bernama.

Redundansi zona untuk replika bernama Hyperscale

Redundansi zona untuk replika bernama Azure SQL Database Hyperscale menggunakan Zona Ketersediaan Azure untuk mendistribusikan simpul komputasi replika bernama di berbagai lokasi fisik dalam wilayah Azure. Dengan memilih redundansi zona untuk replika bernama, Anda dapat meningkatkan ketahanan semua lapisan database Hyperscale Anda ke berbagai kegagalan yang lebih luas, termasuk pemadaman pusat data, tanpa modifikasi logika aplikasi. Untuk informasi selengkapnya, lihat Ketersediaan redundan zona Hyperscale.

Untuk tutorial membuat replika bernama Hyperscale zona redundan, lihat Membuat replika bernama Hyperscale.

Untuk pemecahan masalah dan pengujian ketahanan kesalahan aplikasi, lihat Menguji ketahanan kesalahan aplikasi.

Geo-replika

Dengan replikasi geo aktif, Anda dapat membuat replika sekunder yang dapat dibaca dari database Hyperscale utama di wilayah Azure yang sama atau berbeda. Geo-replika harus dibuat di server logis yang berbeda. Nama database geo-replika selalu cocok dengan nama database utama.

Saat membuat geo-replikasi, semua data disalin dari yang utama ke kumpulan server halaman yang berbeda. Geo-replika tidak berbagi server halaman dengan server utama, meskipun mereka berada di wilayah yang sama. Arsitektur ini menyediakan redundansi yang diperlukan untuk geo-failover.

Replika geo digunakan untuk menjaga salinan database yang konsisten secara transaksional melalui replikasi asinkron. Jika replikasi geo berada di wilayah Azure yang berbeda, replikasi tersebut dapat digunakan untuk pemulihan bencana jika terjadi bencana atau pemadaman di wilayah utama. Geo-replika juga dapat digunakan untuk skenario peluasan skala pembacaan geografis. Pada Oktober 2022, salinan database dari replika sekunder geo Hyperscale didukung.

Replikasi geografis untuk database Hyperscale memiliki batasan saat ini:

  • Hanya satu geo-replika yang dapat dibuat (di wilayah yang sama atau berbeda).
  • Pemulihan titik waktu replikasi geo tidak didukung.
  • Membuat geo-replika geo-replika (juga dikenal sebagai "rantai geo-replika") tidak didukung.

Pecahkan masalah

Memecahkan masalah replika bernama Hyperscale zona redundan

  • Untuk pemecahan masalah dan pengujian ketahanan kesalahan aplikasi, lihat Menguji ketahanan kesalahan aplikasi.

  • Pastikan setidaknya satu replika ketersediaan tinggi ditentukan saat membuat replika bernama redundan zona, di PowerShell dan CLI. Misalnya, lihat Membuat replika bernama Hyperscale.

    • Di Azure CLI, Anda harus menentukan parameter "ha-replicas" dan "redundan".
    • Di PowerShell, Anda harus menentukan parameter "HighAvailabilityReplicaCount" dan "ZoneRedundant".
    • Jika dihilangkan, Anda menerima pesan kesalahan: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • Database Hyperscale harus memiliki redundansi zona yang sudah diaktifkan sebagai prasyarat untuk mengaktifkan fitur ini untuk replika bernama.

    • Ini bersifat opsional untuk mengaktifkan redundansi zona untuk replika bernama, bahkan jika database utama mengaktifkan redundansi zona.
    • Jika tidak diaktifkan, Anda menerima pesan kesalahan: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Masalah umum

Sebagian data salah dikembalikan dari sys.databases

Nilai baris yang dikembalikan dari sys.databases, untuk replika bernama, dalam kolom selain name dan database_id, mungkin tidak konsisten dan salah. Misalnya, kolom compatibility_level untuk replika bernama dapat dilaporkan sebagai 140, meskipun jika database utama dari replika bernama yang telah dibuat diatur ke 150. Solusinya, jika memungkinkan, adalah dengan mendapatkan data yang sama menggunakan fungsi DATABASEPROPERTYEX() yang akan menampilkan data yang benar.

Konten terkait

Untuk tutorial tentang mengonfigurasi dan mengelola replika bernama Hyperscale, lihat:

Untuk informasi selengkapnya, lihat: