Hiper ölçekli ikincil kopyalar

Şunlar için geçerlidir:Azure SQL Veritabanı

Dağıtılmış işlevler mimarisinde açıklandığı gibi, Azure SQL Veritabanı Hiper Ölçek'te çoğaltma olarak da adlandırılan iki farklı işlem düğümü türü vardır:

Birincil: Okuma ve yazma işlemlerine hizmet eder
İkincil: Okuma ölçeğini genişletme, yüksek kullanılabilirlik ve coğrafi çoğaltma sağlar

İkincil çoğaltmalar her zaman salt okunur olur ve üç farklı türde olabilir:

Yüksek Erişilebilirlik çoğaltması
Coğrafi kopya
Adlandırılmış kopya

Her türün farklı bir mimarisi, özellik kümesi, amacı ve maliyeti vardır. İhtiyacınız olan özelliklere bağlı olarak, üçünden yalnızca birini veya tümünü birlikte kullanabilirsiniz. İkincil çoğaltmaları sunucusuz veya sağlanan işlem katmanlarıyla kullanabilirsiniz.

Hiper Ölçek adlı çoğaltmaları yapılandırma ve yönetme öğreticileri için bkz:

Yüksek Kullanılabilirlik kopyası

Yüksek Kullanılabilirlik (HA) çoğaltması birincil çoğaltmayla aynı sayfa sunucularını kullandığından, HA çoğaltması eklemek için veri kopyası gerekmez. HA çoğaltmaları, veritabanı erişilebilirliğini artırmak için kullanılır; yük devretme için sıcak yedek çoğaltmalar olarak işlev görürler. Birincil replika kullanılamaz duruma gelirse, mevcut HA replikalarından birine devretme otomatik olarak ve hızlı bir şekilde gerçekleşir. Bağlantı dizesinin değiştirilmesi gerekmez; yük devretme sırasında aktif bağlantıların kesilmesi nedeniyle uygulamalarda kısa süreli bir kesinti yaşanabilir. Bu senaryo için her zamanki gibi uygun yeniden deneme mantığı önerilir. Birkaç sürücü zaten belirli ölçüde otomatik yeniden deneme mantığı sunar. .NET kullanıyorsanız, en son Microsoft.Data.SqlClient kitaplığı yapılandırılabilir otomatik yeniden deneme mantığı için yerel tam destek sağlar.

HA çoğaltmaları, birincil çoğaltmayla aynı sunucu ve veritabanı adını kullanır. Hizmet Düzeyi Hedefi (SLO) de her zaman birincil kopyayla aynıdır. HA çoğaltmaları portaldan veya herhangi bir API'den tek başına kaynaklar olarak görünür veya yönetilemez. Bunlar birincil çoğaltmayla aynı işlem hızında faturalandırılır, ancak depolama maliyetleri ikincil çoğaltmalar için geçerli değildir.

0 ila 4 HA kopyası olabilir. Yeni veritabanı oluşturulurken sayı çoğaltmalarını belirtebilir veya var olan bir veritabanı için çoğaltma sayısını güncelleştirebilirsiniz. Ortak yönetim uç noktalarını ve araçlarını (örneğin: Azure PowerShell, Azure CLI, Azure portalı, REST API) kullanarak HA çoğaltmalarının sayısını belirtebilirsiniz. HA çoğaltmalarının oluşturulması veya kaldırılması, birincil çoğaltmadaki aktif bağlantıları etkilemez.

Kopyaları belirle

sys.dm_hs_database_replicas (Transact-SQL) dinamik yönetim görünümü (DMV) ile birincil çoğaltmaya bağlandığınızda tüm Azure SQL Veritabanı Hiper Ölçek çoğaltmalarını ve rollerini tanımlayabilirsiniz. Örneğin:

SELECT replica_role_desc, replica_server_name, replica_id
FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));

HA çoğaltmasına bağlan

Hiperscale veritabanlarında, istemcinin kullandığı bağlantı dizesindeki ApplicationIntent bağımsız değişkeni, bağlantının okuma-yazma özellikli birincil çoğaltmaya mı yoksa salt okunur bir HA çoğaltmasına mı yönlendirileceğini belirler. ApplicationIntent, ReadOnly olarak ayarlanırsa ve veritabanında ikincil çoğaltma yoksa, bağlantı birincil çoğaltmaya yönlendirilir ve varsayılan olarak ReadWrite davranışı kullanılır.

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

Tüm HA replikaları kaynak kapasitesi açısından aynıdır. Birden fazla HA çoğaltması varsa, okuma amaçlı iş yükü kullanılabilir tüm HA çoğaltmaları arasında gelişigüzel dağıtılır. Birden çok HA çoğaltması olduğunda, birincilde yapılan veri değişiklikleriyle ilgili olarak her birinin farklı veri gecikme süresine sahip olabileceğini unutmayın. Her HA çoğaltması, aynı sayfa sunucusu kümesindeki birincil veriyle aynı verileri kullanır. Ancak, her HA çoğaltması üzerindeki yerel veri önbellekleri, birincil çoğaltmadaki günlük kayıtlarını HA çoğaltmalarına ileten işlem günlüğü hizmeti aracılığıyla birincilde yapılan değişiklikleri yansıtır. Sonuç olarak, HA çoğaltması üzerinde yürütülen iş yüküne bağlı olarak, günlük kayıtlarının uygulanması farklı hızlarda gerçekleşebilir ve bu nedenle farklı çoğaltmalar birincil çoğaltmaya göre farklı veri gecikme süresine sahip olabilir.

Adlandırılmış kopya

Adlandırılmış bir çoğaltma, tıpkı bir HA çoğaltması gibi, birincil replikayla aynı sayfa sunucularını kullanır. HA çoğaltmalarına benzer şekilde, adlandırılmış çoğaltma eklemek için veri kopyası gerekmez.

HA replikaları ile adlandırılmış replikalar arasında farklar vardır:

Adlandırılmış çoğaltmalar, portalda ve API (Azure CLI, Azure PowerShell, T-SQL) çağrılarında normal (salt okunur) Azure SQL veritabanları gibi görünür.
Adlandırılmış çoğaltmaların veritabanı adı birincil çoğaltmadan farklı olabilir ve isteğe bağlı olarak farklı bir mantıksal sunucuda bulunabilir (birincil çoğaltmayla aynı bölgede olduğu sürece).
Adlandırılmış çoğaltmaların birincil çoğaltmadan bağımsız olarak ayarlanabilen ve değiştirilebilen kendi Hizmet Düzeyi Hedefi vardır.
Adlandırılmış çoğaltmalar, en fazla 30 adlandırılmış çoğaltmayı destekler (her birincil çoğaltma için).
Adlandırılmış çoğaltmalar, adlandırılmış çoğaltmaları barındıran mantıksal sunucularda farklı oturum açma bilgileri oluşturarak her adlandırılmış çoğaltma için farklı kimlik doğrulamasını destekler.

Sonuç olarak, adlandırılmış replikalar salt okunur iş yükleri söz konusu olduğunda HA replikalarına göre çeşitli avantajlar sunar:

Birincil çoğaltmanın ölçeği artırıldığında veya azaltıldığında, adlandırılmış çoğaltmaya bağlı kullanıcıların bağlantıları kesilmez.
Birincil çoğaltmaya bağlı olan kullanıcılar, adlandırılmış çoğaltmalardan herhangi biri büyütüldüğünde veya küçültüldüğünde etkilenmez.

Adlandırılmış çoğaltmaların temel amacı, çok çeşitli okuma kapasitesi genişletme senaryolarını etkinleştirmek ve Hibrit İşlemsel ve Analitik İşleme (HTAP) iş yüklerini geliştirmektir. Bu tür çözümlerin nasıl oluşturulacağını gösteren örnekler burada verilmiştir:

OLTP ölçeği genişletme örneği

Buna ek olarak, adlandırılmış replikalar, diğer birçok kullanım senaryosunu da karşılamak için esneklik ve ölçeklenebilirlik sunar:

Erişim Yalıtımı: Belirli bir adlandırılmış çoğaltmaya erişim verebilirsiniz, ancak birincil çoğaltmaya veya diğer adlandırılmış çoğaltmalara değil.
İş yüküne bağımlı hizmet düzeyi hedefi: Adlandırılmış çoğaltmanın kendi hizmet düzeyi hedefi olabileceğinden, farklı iş yükleri ve kullanım örnekleri için farklı adlandırılmış çoğaltmalar kullanmak mümkündür. Örneğin, adlandırılmış çoğaltmalardan biri Power BI isteklerine hizmet vermek için, diğeri ise Veri Bilimi görevler için Apache Spark'a veri sunmak için kullanılabilir. Her birinin bağımsız bir hizmet düzeyi hedefi olabilir ve bağımsız olarak ölçeklendirilebilir.
İş yüküne bağlı yönlendirme: 30 adede kadar adlandırılmış çoğaltma ile, bir uygulamanın başka bir çoğaltmadan yalıtılabilmesi için adlandırılmış çoğaltmaları gruplar halinde kullanmak mümkündür. Örneğin, mobil uygulamalardan gelen istekleri sunmak için dört adlandırılmış çoğaltmadan oluşan bir grup kullanılabilirken, bir web uygulamasından gelen istekleri sunmak için başka bir grup iki adlandırılmış çoğaltma kullanılabilir. Bu yaklaşım, her grup için performans ve maliyetlerin ayrıntılı bir şekilde ayarlanmasını sağlar.

Not

Hiper Ölçek adlandırılmış çoğaltmalar hakkında sık sorulan sorulara bakın Azure SQL Veritabanı Hiper Ölçek adlandırılmış çoğaltmalar hakkında SSS.

Hyperscale adlandırılmış çoğaltmaları için bölge yedekliliği

Alanlar arası yedeklilik için yapılandırılan hiper ölçek adlandırılmış çoğaltmalar, adlandırılmış çoğaltma işlem düğümlerini bir Azure bölgesindeki farklı fiziksel konumlara dağıtmak için Azure Kullanılabilirlik Alanlarını kullanır. Adlandırılmış çoğaltmalar için bölge yedekliliği seçerek, uygulama mantığında herhangi bir değişiklik yapmadan Hiper Ölçek veritabanlarınızın tüm katmanlarının dayanıklılığını veri merkezi kesintileri de dahil olmak üzere daha geniş bir hata aralığına geliştirebilirsiniz. Daha fazla bilgi için bkz. Hiper ölçek bölgesel yedeklilik kullanılabilirliği.

Alanlar arası yedekli çoğaltma adlı hiper ölçek oluşturma öğreticisi için bkz. Çoğaltma adlı hiper ölçek oluşturma.

Uygulama hatası dayanıklılığını test etme ve sorun giderme için bkz. Uygulama hatası dayanıklılığını test etme.

Coğrafi kopya

Etkin coğrafi çoğaltma ile, birincil Hiper Ölçek veritabanının okunabilir ikincil çoğaltmasını aynı veya farklı bir Azure bölgesinde oluşturabilirsiniz. Coğrafi çoğaltmalar farklı bir mantıksal sunucuda oluşturulmalıdır. Coğrafi replikanın veritabanı adı her zaman birincil veritabanının adıyla eşleşir.

Coğrafi çoğaltma oluşturduğunuzda, tüm veriler birincil sunucudan farklı bir sayfa sunucusu kümesine kopyalanır. Coğrafi replika, aynı bölgede bulunsalar bile sayfa sunucularını birincille paylaşmaz. Bu mimari, coğrafi yük devretmeler için gerekli yedekliliği sağlar.

Coğrafi çoğaltmalar, zaman uyumsuz çoğaltma aracılığıyla veritabanının işlem açısından tutarlı bir kopyasını korumak için kullanılır. Coğrafi replika farklı bir Azure bölgesindeyse, birincil bölgede bir felaket veya kesinti olması durumunda felaket kurtarma için kullanılabilir. Coğrafi çoğaltmalar, coğrafi okuma ölçeklendirme senaryolarında da kullanılabilir. Ekim 2022 itibarıyla, bir Hyperscale coğrafi ikincil replikasından veritabanı kopyalama desteklenmektedir.

Hiper Ölçek veritabanı için coğrafi çoğaltmanın geçerli sınırlamaları şunlardır:

Yalnızca bir coğrafi çoğaltma oluşturulabilir (aynı veya farklı bölgede).
Coğrafi çoğaltmanın belirli bir noktaya geri yüklenmesi desteklenmez.
Bir coğrafi çoğaltmadan başka bir coğrafi çoğaltma oluşturma (“coğrafi çoğaltma zincirlemesi” olarak da bilinir) desteklenmemektedir.

Önemli

Aynı veya farklı bölgelerde birden çok coğrafi çoğaltma oluşturma özelliği bir önizleme özelliğidir.

Sorun giderme

Bölge yedekliliğine sahip Hyperscale adlı çoğaltmalarda sorun giderme

Uygulama hatası dayanıklılığını test etme ve sorun giderme için bkz. Uygulama hatası dayanıklılığını test etme.
PowerShell ve CLI'da bölge yedekli bir adlandırılmış çoğaltma oluştururken, en az bir yüksek kullanılabilirlik çoğaltmasının belirtildiğinden emin olun. Örnek için bkz. Hiper Ölçek adlı bir kopya oluşturma.
- Azure CLI'da ha-replicas ve redundant parametrelerinin her ikisini de belirtmeniz gerekir.
- PowerShell'de HighAvailabilityReplicaCount ve ZoneRedundant parametrelerini belirtmeniz gerekir.
- Atlanırsa hata iletisini alırsınız: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.
Hiper Ölçek veritabanında, bu özelliği adlandırılmış çoğaltmalar için etkinleştirmek için önkoşul olarak bölge yedekliliği zaten etkinleştirilmelidir.
- Birincil veritabanında bölge yedekliliği etkinleştirilmiş olsa bile adlandırılmış çoğaltmalar için bölge yedekliliğini etkinleştirmek isteğe bağlıdır.
- Etkinleştirilmemişse şu hata iletisini alırsınız: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Bilinen sorunlar

sys.databases dosyasından kısmen yanlış veriler döndürüldü

sys.databases öğesinden döndürülen satır değerleri, adlandırılmış çoğaltmalar için name ve database_id dışındaki sütunlarda tutarsız ve yanlış olabilir. Örneğin, adlandırılmış çoğaltmaya compatibility_level karşılık gelen birincil veritabanı uyumluluk düzeyi 150 olarak ayarlansa bile adlandırılmış çoğaltma sütunu 140 olarak bildirilebilir. Mümkün olduğunda, geçici bir çözüm, doğru verileri döndüren DATABASEPROPERTYEX() işlevini kullanarak aynı verileri almaktır.