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. Anda dapat menggunakan replika sekunder dengan tingkat komputasi tanpa server atau 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 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 lagi otomatis yang dapat dikonfigurasi.

Replika ketersediaan tinggi menggunakan server dan nama database yang sama dengan replika utama. Tujuan Tingkat Layanan (SLO) mereka juga selalu sama dengan untuk replika utama. Replika HA tidak terlihat atau dapat dikelola sebagai sumber daya yang berdiri sendiri, dari portal atau dari API apa pun. Mereka ditagih dengan tarif komputasi yang sama dengan replika utama, tetapi biaya penyimpanan tidak berlaku untuk replika sekunder.

Mungkin ada nol hingga empat replika HA. Anda dapat menentukan replika angka selama pembuatan database baru, atau memperbarui jumlah replika untuk database yang sudah ada. Anda dapat menggunakan titik akhir dan alat manajemen umum (misalnya: Azure PowerShell, Azure CLI, portal Azure, REST API) untuk menentukan jumlah replika HA. Membuat atau menghapus replika KETERSEDIAAN TINGGI tidak memengaruhi koneksi aktif pada 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, koneksi dirutekan ke replika utama dan default ke ReadWrite perilaku.

-- 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 dijalankan pada 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 (Azure CLI, Azure 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 terputus jika replika utama ditingkatkan atau diturunkan.
  • Pengguna yang terhubung ke replika utama tidak terpengaruh ketika replika bernama apa pun ditingkatkan atau diturunkan skalanya.
  • Beban kerja yang berjalan pada replika apa pun - primer atau bernama - tidak 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 itu, 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, dimungkinkan untuk menggunakan replika bernama yang berbeda untuk beban kerja dan kasus penggunaan yang berbeda. 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 tergantung beban kerja: dengan hingga 30 replika bernama, dimungkinkan untuk menggunakan replika bernama dalam grup sehingga aplikasi dapat diisolasi dari replika lain. 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

Replika bernama Hyperscale yang dikonfigurasi untuk redundansi zona 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 Anda membuat replika geografis, semua data disalin dari server utama ke set server halaman yang berbeda. Replika geografis tidak berbagi server halaman dengan server utama, meskipun 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 geo-replika berada di wilayah Azure yang berbeda, replika tersebut dapat digunakan untuk pemulihan bencana jika ada 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 replika geografis 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 redundant.
    • 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 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, compatibility_level kolom untuk replika bernama dapat dilaporkan sebagai 140 bahkan jika database utama yang sesuai dengan replika bernama diatur ke tingkat kompatibilitas 150. Solusinya, jika memungkinkan, adalah mendapatkan data yang sama menggunakan DATABASEPROPERTYEX() fungsi , yang mengembalikan data yang benar.

Konten terkait

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

Untuk informasi selengkapnya, lihat: