Yük devretme gruplarına genel bakış ve en iyi yöntemler (Azure SQL Veritabanı)

  • Makale

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

Yük devretme grupları özelliği, mantıksal sunucudaki bazı veya tüm veritabanlarının başka bir bölgedeki mantıksal sunucuya çoğaltılmasını ve yük devretmesini yönetmenizi sağlar. Bu makalede, Azure SQL Veritabanı ile birlikte kullanmaya yönelik en iyi yöntemler ve öneriler içeren yük devretme grubu özelliğine genel bir bakış sağlanmaktadır.

Özelliği kullanmaya başlamak için Yük devretme grubunu yapılandırma'yı gözden geçirin.

Not

Bu makale, Azure SQL Veritabanı için yük devretme gruplarını kapsar. Azure SQL Yönetilen Örneği için bkz. Azure SQL Yönetilen Örneği yük devretme grupları.

Olağanüstü durum kurtarma Azure SQL Veritabanı hakkında daha fazla bilgi edinmek için şu videoyu izleyin:

Genel bakış

Yük devretme grupları özelliği, veritabanlarının başka bir Azure bölgesine çoğaltılmasını ve yük devretmesini yönetmenizi sağlar. Bir mantıksal sunucudaki kullanıcı veritabanlarının tümünü veya bir alt kümesini başka bir mantıksal sunucuya çoğaltılacak şekilde seçebilirsiniz. Bu, coğrafi olarak çoğaltılan veritabanlarının büyük ölçekte dağıtımını ve yönetimini basitleştirmek için tasarlanmış etkin coğrafi çoğaltma özelliğinin üzerinde bildirim temelli bir soyutlamadır.

Coğrafi yük devretme RPO ve RTO için bkz . iş sürekliliğine genel bakış.

Uç nokta yeniden yönlendirme

Yük devretme grupları, coğrafi yük devretme sırasında değişmeden kalan okuma-yazma ve salt okunur dinleyici uç noktaları sağlar. Coğrafi yük devretmeden sonra uygulamanızın bağlantı dizesi değiştirmeniz gerekmez çünkü bağlantılar otomatik olarak geçerli birincil sunucuya yönlendirilir. Coğrafi yük devretme, gruptaki tüm ikincil veritabanlarını birincil role değiştirir. Coğrafi yük devretme tamamlandıktan sonra DNS kaydı, uç noktaları yeni bölgeye yeniden yönlendirecek şekilde otomatik olarak güncelleştirilir.

Salt okunur iş yüklerini boşaltma

Birincil veritabanlarınıza gelen trafiği azaltmak için, salt okunur iş yüklerini boşaltmak için yük devretme grubundaki ikincil veritabanlarını da kullanabilirsiniz. Salt okunur trafiği okunabilir bir ikincil veritabanına yönlendirmek için salt okunur dinleyiciyi kullanın.

Uygulamayı kurtarma

Tam iş sürekliliği sağlamak için bölgesel veritabanı yedekliliği eklemek çözümün yalnızca bir parçasıdır. Yıkıcı bir hatadan sonra bir uygulamayı (hizmeti) uçtan uca kurtarmak, hizmeti ve bağımlı hizmetleri oluşturan tüm bileşenlerin kurtarılmasını gerektirir. Bu bileşenlere örnek olarak istemci yazılımı (örneğin, özel JavaScript içeren bir tarayıcı), web ön uçları, depolama ve DNS verilebilir. Tüm bileşenlerin aynı hatalara dayanıklı olması ve uygulamanızın kurtarma süresi hedefi (RTO) içinde kullanılabilir hale gelmesi kritik önem taşır. Bu nedenle, tüm bağımlı hizmetleri tanımlamanız ve bunların sağladığı garantileri ve özellikleri anlamanız gerekir. Ardından, bağlı olduğu hizmetlerin yük devretmesi sırasında hizmetinizin çalıştığından emin olmak için yeterli adımları atmalısınız.

Yük devretme ilkesi

Yük devretme grupları iki yük devretme ilkesini destekler:

  • Müşteri tarafından yönetilen (önerilen): Müşteriler, yük devretme grubundaki bir veya daha fazla veritabanını etkileyen beklenmeyen bir kesinti fark ettiğinde grubun yük devretmesini gerçekleştirebilir. PowerShell, Azure CLI veya Rest API gibi komut satırı araçlarını kullanırken, müşteri tarafından yönetilen yük devretme ilkesi değeri olur manual.
  • Microsoft tarafından yönetilen: Birincil bir bölgeyi etkileyen yaygın kesinti durumunda Microsoft, yük devretme ilkesi Microsoft tarafından yönetilecek şekilde yapılandırılmış etkilenen tüm yük devretme gruplarının yük devretmesini başlatır. Microsoft tarafından yönetilen yük devretme, tek tek yük devretme grupları veya bir bölgedeki yük devretme gruplarının alt kümesi için başlatılmaz. PowerShell, Azure CLI veya Rest API gibi komut satırı araçlarını kullanırken, Microsoft tarafından yönetilen için yük devretme ilkesi değeri olur automatic.

Aşağıdaki tabloda özetlediği gibi, her yük devretme ilkesinin benzersiz bir kullanım örnekleri kümesi ve yük devretme kapsamı ve veri kaybıyla ilgili beklentileri vardır:

Yük devretme ilkesi Yük devretme kapsamı Kullanım örneği Olası veri kaybı
Müşteri tarafından yönetilen
(Önerilen)		 Yük devretme grupları Bir yük devretme grubundaki bir veya daha fazla veritabanı kesintiden etkilenir ve kullanılamaz duruma gelir. Yük devretmeyi seçebilirsiniz. Yes
Microsoft tarafından yönetilen Bölgedeki tüm yük devretme grupları Veri merkezinde, kullanılabilirlik alanında veya bölgede yaygın bir kesinti veritabanlarının kullanılamamasına neden olur ve Microsoft Azure SQL hizmet ekibi zorunlu yük devretmeyi tetikleme kararı alır.
Bu seçeneği yalnızca olağanüstü durum kurtarma sorumluluğunu Microsoft'a devretmek istediğinizde ve uygulama en az bir saat veya daha fazla RTO'ya (kapalı kalma süresi) dayanıklı olduğunda kullanın.		 Yes

Müşteri tarafından yönetilen

Nadir durumlarda yerleşik kullanılabilirlik veya yüksek kullanılabilirlik , bir kesintiyi azaltmak için yeterli değildir ve bir yük devretme grubundaki veritabanlarınız, veritabanlarını kullanan uygulamaların hizmet düzeyi sözleşmesi (SLA) tarafından kabul edilemeyen bir süre boyunca kullanılamayabilir. Veritabanları, yalnızca birkaç veritabanını etkileyen yerelleştirilmiş bir sorun nedeniyle kullanılamıyor veya veri merkezi, kullanılabilirlik alanı veya bölge düzeyinde olabilir. Bu durumlarda, iş sürekliliğini geri yüklemek için zorunlu yük devretme başlatabilirsiniz.

Yük devretme işleminin ne zaman başlatılıp iş sürekliliğini geri yükleyebileceğinizi denetleyebilmek için yük devretme ilkenizi müşteri tarafından yönetilen olarak ayarlamanız kesinlikle önerilir. Yük devretme grubundaki bir veya daha fazla veritabanını etkileyen beklenmeyen bir kesinti fark ettiğinizde yük devretme başlatabilirsiniz.

Microsoft tarafından yönetilen

Microsoft tarafından yönetilen yük devretme ilkesiyle, olağanüstü durum kurtarma sorumluluğu Azure SQL hizmetine devredilir. Azure SQL hizmetinin zorlamalı yük devretme başlatması için aşağıdaki koşulların karşılanması gerekir:

  • Doğal afet olayının neden olduğu veri merkezi, kullanılabilirlik alanı veya bölge düzeyi kesintisi, yapılandırma değişiklikleri, yazılım hataları veya donanım bileşeni hataları ve bölgedeki birçok veritabanı etkilenir.
  • Yetkisiz kullanım süresi doldu. Kesintinin ölçeğinin doğrulanması ve azaltılması insan eylemlerine bağlı olduğundan yetkisiz kullanım süresi bir saatin altında ayarlanamaz.

Bu koşullar karşılandığında Azure SQL hizmeti, bölgedeki yük devretme ilkesi Microsoft tarafından yönetilen olarak ayarlanmış tüm yük devretme grupları için zorunlu yük devretmeleri başlatır.

Yük devretme ilkesini Yalnızca aşağıdaki durumlarda Yönetilen Microsoft olarak ayarlayın:

  • Olağanüstü durum kurtarma sorumluluğunu Azure SQL hizmetine devretmek istiyorsunuz.
  • Uygulama, veritabanınızın en az bir saat veya daha fazla süre kullanılamaz durumda olmasına dayanıklıdır.
  • Yetkisiz kullanım süresi dolduktan bir süre sonra zorlamalı yük devretme tetiklenebilir çünkü zorunlu yük devretme için gerçek süre önemli ölçüde farklılık gösterebilir.
  • Alanlar arası yedeklilik yapılandırmasından veya kullanılabilirlik durumlarından bağımsız olarak yük devretme grubundaki tüm veritabanlarının yük devretmesi kabul edilebilir. Alanlar arası yedeklilik için yapılandırılan veritabanları bölgesel hatalara dayanıklı olsa da ve kesintiden etkilenmese de, Microsoft tarafından yönetilen yük devretme ilkesine sahip bir yük devretme grubunun parçası olmaları durumunda da yük devredilir.
  • Uygulamanın uygulama tarafından kullanılan diğer Azure hizmetlerine veya bileşenlerine bağımlılığı dikkate alınmadan yük devretme grubundaki veritabanlarının zorlamalı yük devretmelerinin olması kabul edilebilir. Bu durum, uygulamanın performans düşüşü veya kullanılamamasına neden olabilir.
  • Zorlamalı yük devretmenin tam zamanı denetlenemediğinden ve ikincil veritabanlarının eşitleme durumunu yoksayıldığından, bilinmeyen miktarda veri kaybına neden olmak kabul edilebilir.
  • Yük devretme grubundaki tüm birincil ve ikincil veritabanları aynı hizmet katmanına, işlem katmanına (sağlanan veya sunucusuz) ve işlem boyutuna (DTU'lar veya sanal çekirdekler) sahiptir. Bir yük devretme grubundaki tüm veritabanlarının hizmet düzeyi hedefi (SLO) eşleşmiyorsa, yük devretme ilkesi sonunda Microsoft Tarafından Yönetilen'den Azure SQL hizmeti tarafından Yönetilen Müşteri'ye güncelleştirilir.

Microsoft tarafından bir yük devretme tetiklendiğinde, Azure İzleyici etkinlik günlüğüne Yük Devretme Azure SQL yük devretme grubu işlem adı için bir giriş eklenir. Girdi, Kaynak altında yük devretme grubunun adını içerir ve Tarafından başlatılan olay, yük devretmenin Microsoft tarafından başlatıldığını belirtmek için tek bir kısa çizgi (-) görüntüler. Bu bilgiler, Azure portalındaki yeni birincil sunucunun veya örneğin Etkinlik günlüğü sayfasında da bulunabilir.

Terminoloji ve özellikler

  • Yük devretme grubu (FOG)

    Yük devretme grubu, birincil bölgedeki bir kesinti nedeniyle birincil veritabanlarının tümünün veya bazılarının kullanılamaz duruma gelmesi durumunda birim olarak başka bir Azure bölgesine yük devredebilen, Azure'daki tek bir mantıksal sunucu tarafından yönetilen adlandırılmış bir veritabanı grubudur.

    Önemli

    Yük devretme grubunun adı .database.windows.net etki alanı içinde genel düzeyde benzersiz olmalıdır.

  • Sunucular

    Mantıksal sunucudaki kullanıcı veritabanlarının bazıları veya tümü bir yük devretme grubuna yerleştirilebilir. Ayrıca, bir sunucu tek bir sunucuda birden çok yük devretme grubunu destekler.

  • Birincil

    Yük devretme grubunda birincil veritabanlarını barındıran mantıksal sunucu.

  • İkincil

    Yük devretme grubunda ikincil veritabanlarını barındıran mantıksal sunucu. İkincil, birincil bölgeyle aynı Azure bölgesinde olamaz.

  • Yük devretme (veri kaybı yok)

    Yük devretme, ikincil rol birincil role geçmeden önce birincil ve ikincil veritabanları arasında tam veri eşitlemesi gerçekleştirir. Bu, veri kaybı olmamasını garanti eder. Yük devretme yalnızca birincil erişime açık olduğunda mümkündür. Yük devretme aşağıdaki senaryolarda kullanılır:

    • Veri kaybı kabul edilebilir olmadığında üretimde olağanüstü durum kurtarma (DR) tatbikatları gerçekleştirme
    • İş yükünü farklı bir bölgeye yeniden yerleştirin
    • Kesinti azaltıldıktan (yeniden çalışma) sonra iş yükünü birincil bölgeye geri döndürme

  • Zorlamalı yük devretme (olası veri kaybı)

    Zorlamalı yük devretme, son değişikliklerin birincil rolden yayılmasını beklemeden ikincil rolü hemen birincil role değiştirir. Bu işlem olası veri kaybına neden olabilir. Zorlamalı yük devretme, birincil erişim olmadığında kesintiler sırasında kurtarma yöntemi olarak kullanılır. Kesinti giderildiğinde, eski birincil otomatik olarak yeniden bağlanır ve yeni bir ikincil olur. Yeniden çalışma için yük devretme yürütülebilir ve çoğaltmalar özgün birincil ve ikincil rollerine döndürülür.

  • Veri kaybıyla yetkisiz kullanım süresi

    Veriler zaman uyumsuz çoğaltma kullanılarak ikincil sunucuya çoğaltıldığı için, Microsoft tarafından yönetilen yük devretme ilkelerine sahip grupların zorla yük devretmesi veri kaybına neden olabilir. Yük devretme ilkesini, uygulamanızın veri kaybına dayanıklılığını yansıtacak şekilde özelleştirebilirsiniz. yapılandırarak GracePeriodWithDataLossHours, Azure SQL hizmetinin zorlamalı yük devretme başlatmadan önce ne kadar bekleyeceğini denetleyebilirsiniz ve bu da veri kaybına neden olabilir.

  • Yük devretme grubuna tek veritabanları ekleme

    Aynı mantıksal sunucuya birkaç tek veritabanını aynı yük devretme grubuna yerleştirebilirsiniz. Yük devretme grubuna tek bir veritabanı eklerseniz, yük devretme grubu oluşturulduğunda belirttiğiniz ikincil sunucuda aynı sürüm ve işlem boyutunu kullanarak otomatik olarak ikincil bir veritabanı oluşturur. İkincil sunucuda zaten ikincil veritabanı olan bir veritabanı eklerseniz, bu coğrafi çoğaltma bağlantısı grup tarafından devralınır. Yük devretme grubunun parçası olmayan bir sunucuya zaten ikincil veritabanı olan bir veritabanı eklediğinizde, ikincil sunucuda yeni bir ikincil veritabanı oluşturulur.

    Önemli

    • İkincil mantıksal sunucunun, mevcut bir ikincil veritabanı olmadığı sürece aynı ada sahip bir veritabanı olmadığından emin olun.
    • Bir veritabanı bellek içi OLTP nesneleri içeriyorsa, bellek içi OLTP nesneleri bellekte bulunduğundan birincil veritabanının ve ikincil coğrafi çoğaltma veritabanının eşleşen hizmet katmanları olmalıdır. Coğrafi çoğaltma veritabanında daha düşük bir hizmet katmanı bellek yetersiz sorunlarına neden olabilir. Bu durumda, coğrafi çoğaltma veritabanını kurtaramayabilir ve ikincil veritabanının kullanılamamasına ve coğrafi ikincildeki bellek içi OLTP nesneleriyle birlikte. Bu da yük devretmelerin başarısız olmasına neden olabilir. Bunu önlemek için coğrafi ikincil veritabanının hizmet katmanının birincil veritabanının hizmet katmanıyla eşleştiğinden emin olun. Hizmet katmanı yükseltmeleri veri boyutu işlemleri olabilir ve tamamlanması biraz zaman alabilir.

  • Elastik havuzdaki veritabanlarını yük devretme grubuna ekleme

    Elastik havuzdaki tüm veya birkaç veritabanını aynı yük devretme grubuna yerleştirebilirsiniz. Birincil veritabanı bir elastik havuzdaysa, ikincil otomatik olarak elastik havuzda aynı adla (ikincil havuz) oluşturulur. İkincil sunucunun tam adı ve yük devretme grubu tarafından oluşturulacak ikincil veritabanlarını barındırmak için yeterli boş kapasiteye sahip bir elastik havuz içerdiğinden emin olmanız gerekir. İkincil havuzda zaten ikincil veritabanı olan bir veritabanını havuza eklerseniz, bu coğrafi çoğaltma bağlantısı grup tarafından devralınır. Yük devretme grubunun parçası olmayan bir sunucuda zaten ikincil veritabanı olan bir veritabanı eklediğinizde, ikincil havuzda yeni bir ikincil veritabanı oluşturulur.

  • Yük devretme grubu okuma-yazma dinleyicisi

    Geçerli birincile işaret eden bir DNS CNAME kaydı. Yük devretme grubu oluşturulduğunda otomatik olarak oluşturulur ve birincil yük devretme sonrasında değiştiğinde okuma-yazma iş yükünün saydam bir şekilde birincile yeniden bağlanmasına izin verir. Bir sunucuda yük devretme grubu oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.database.windows.netoluşturulur. Yük devretmeden sonra, DNS kaydı dinleyiciyi yeni birincil öğeye yeniden yönlendirmek için otomatik olarak güncelleştirilir.

  • Yük devretme grubu salt okuma dinleyicisi

    Geçerli ikincil öğeyi işaret eden bir DNS CNAME kaydı. Yük devretme grubu oluşturulduğunda otomatik olarak oluşturulur ve salt okunur SQL iş yükünün, yük devretmeden sonra ikincil değişiklik yapıldığında ikincil iş yüküne saydam bir şekilde bağlanmasına izin verir. Bir sunucuda yük devretme grubu oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.secondary.database.windows.netoluşturulur. Varsayılan olarak, ikincil çevrimdışı olduğunda birincil dinleyicinin performansının etkilenmemesini sağladığından salt okunur dinleyicinin yük devretmesi devre dışı bırakılır. Ancak, salt okunur oturumların ikincil kurtarılana kadar bağlanamayacağı anlamına da gelir. Salt okunur oturumlar için kapalı kalma süresini tolere edemiyorsanız ve birincilin olası performans düşüşü pahasına hem salt okunur hem de okuma-yazma trafiği için birincili kullanabiliyorsanız, özelliği yapılandırarak salt okunur dinleyici için yük devretmeyi AllowReadOnlyFailoverToPrimary etkinleştirebilirsiniz. Bu durumda, ikincil kullanılabilir değilse salt okunur trafik otomatik olarak birincile yönlendirilir.

    Not

    Özelliğin AllowReadOnlyFailoverToPrimary etkili olması için Microsoft tarafından yönetilen yük devretme ilkesinin etkinleştirilmesi ve zorunlu yük devretmenin tetiklenmiş olması gerekir. Bu durumda, özellik True olarak ayarlanırsa, yeni birincil hem okuma-yazma hem de salt okunur oturumlara hizmet eder.

  • Birden çok yük devretme grubu

    Coğrafi yük devretmelerin kapsamını denetlemek için aynı sunucu çifti için birden çok yük devretme grubu yapılandırabilirsiniz. Her grup bağımsız olarak yük devreder. Veritabanı başına kiracı uygulamanız birden çok bölgede dağıtılıyorsa ve elastik havuzlar kullanıyorsa, her havuzdaki birincil ve ikincil veritabanlarını karıştırmak için bu özelliği kullanabilirsiniz. Bu şekilde kesintinin etkisini yalnızca bazı kiracı veritabanlarına azaltabilirsiniz.

Yük devretme grubu mimarisi

Azure SQL Veritabanı bir yük devretme grubu, genellikle aynı uygulama tarafından kullanılan bir veya birden çok veritabanı içerebilir. Birincil sunucuda bir yük devretme grubu yapılandırılmalıdır ve bu grup bunu farklı bir Azure bölgesindeki ikincil sunucuya bağlar. Yük devretme grubu birincil sunucudaki tüm veya bazı veritabanlarını içerebilir. Aşağıdaki diyagramda, bir yük devretme grubunda birden çok veritabanı kullanan coğrafi olarak yedekli bir bulut uygulamasının tipik yapılandırması gösterilmektedir:

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

İş sürekliliği göz önünde bulundurularak bir hizmet tasarlarken, bu makalede özetlenen genel yönergeleri ve en iyi yöntemleri izleyin. Bir yük devretme grubu yapılandırırken, coğrafi ikincil yeni birincil olduğunda, coğrafi yük devretmeden sonra ikincilde kimlik doğrulaması ve ağ erişiminin düzgün çalışması için ayarlandığından emin olun. Ayrıntılar için bkz. Olağanüstü durum kurtarma sonrasında güvenlik SQL Veritabanı. Daha fazla bilgi için bkz . Olağanüstü durum kurtarma için bulut çözümleri tasarlama.

Eşleştirilmiş bölgeleri kullanma

Birincil ve ikincil sunucu arasında yük devretme grubunuzu oluştururken, eşleştirilmiş bölgelerdeki yük devretme gruplarının eşleşmeyen bölgelere kıyasla daha iyi performansa sahip olması nedeniyle eşleştirilmiş bölgeleri kullanın.

Güvenli dağıtım uygulamalarının ardından Azure SQL Veritabanı genellikle eşleştirilmiş bölgeleri aynı anda güncelleştirmez. Ancak önce hangi bölgenin yükseltileceğini tahmin etmek mümkün olmadığından dağıtım sırası garanti edilmeyecektir. Bazen birincil sunucunuz önce yükseltilir, bazen de ikinci olarak yükseltilir.

Azure bölge eşleştirmesi ile uyumlu olmayan veritabanları için coğrafi çoğaltma veya yük devretme gruplarınız yapılandırılmışsa, birincil ve ikincil veritabanlarınız için farklı bakım penceresi zamanlamaları kullanın. Örneğin, ikincil veritabanınız için Hafta içi bakım penceresini ve birincil veritabanınız için Hafta sonu bakım penceresini seçebilirsiniz.

İlk tohumlama

Yük devretme grubuna veritabanları veya elastik havuzlar eklerken, veri çoğaltma başlamadan önce bir ilk tohumlama aşaması vardır. İlk tohumlama aşaması en uzun ve en pahalı işlemdir. İlk tohumlama tamamlandıktan sonra veriler eşitlenir ve ardından yalnızca sonraki veri değişiklikleri çoğaltılır. İlk dengeli dağıtımın tamamlanması için gereken süre, verilerinizin boyutuna, çoğaltılan veritabanlarının sayısına, birincil veritabanlarındaki yüke ve birincil ve ikincil veritabanı arasındaki ağ bağlantısının hızına bağlıdır. Normal koşullarda, SQL Veritabanı için olası tohumlama hızı saatte 500 GB'a kadar çıkar. Tüm veritabanları için paralel olarak tohumlama gerçekleştirilir.

Birden çok veritabanına yük devretmek için birden çok yük devretme grubu kullanma

Farklı bölgelerdeki iki sunucu (birincil ve ikincil sunucular) arasında bir veya birden çok yük devretme grubu oluşturulabilir. Her grup, birincil bölgedeki bir kesinti nedeniyle birincil veritabanlarının tümünün veya bazılarının kullanılamaz duruma gelmesi durumunda birim olarak kurtarılan bir veya birkaç veritabanı içerebilir. Yük devretme grubu oluşturmak, birincil hizmet hedefiyle aynı coğrafi ikincil veritabanları oluşturur. Bir yük devretme grubuna var olan bir coğrafi çoğaltma ilişkisi eklerseniz, coğrafi ikincilin birincil hizmet katmanı ve işlem boyutuyla yapılandırıldığından emin olun.

Okuma-yazma dinleyicisini kullanma (birincil)

Okuma yazma iş yükleri için bağlantı dizesinde sunucu adı olarak <fog-name>.database.windows.net kullanın. Bağlan ions otomatik olarak birincile yönlendirilir. Yük devretmeden sonra bu ad değişmez. Yük devretmenin DNS kaydını güncelleştirmeyi içerdiğini, böylece istemci bağlantılarının yeni birincil sunucuya yeniden yönlendirilmesinin ancak istemci DNS önbelleği yenilendikten sonra olduğunu unutmayın. Birincil ve ikincil dinleyici DNS kaydının yaşam süresi (TTL) 30 saniyedir.

Salt okunur dinleyiciyi kullanma (ikincil)

Veri gecikme süresine dayanıklı, mantıksal olarak yalıtılmış salt okunur iş yükleriniz varsa bunları coğrafi ikincilde çalıştırabilirsiniz. Salt okunur oturumlar için bağlantı dizesinde sunucu adı olarak <fog-name>.secondary.database.windows.net kullanın. Bağlan yonlar otomatik olarak coğrafi ikincile yönlendirilir. ayrıca kullanarak ApplicationIntent=ReadOnlybağlantı dizesi okuma amacını belirtmeniz önerilir.

Premium, İş Açısından Kritik ve Hiper Ölçek hizmet katmanlarında SQL Veritabanı, bağlantı dizesi parametresini kullanarak ApplicationIntent=ReadOnly salt okunur sorgu iş yüklerini boşaltmak için salt okunur çoğaltmaların kullanılmasını destekler. Coğrafi ikincil bir yapılandırma yaptığınızda, birincil konumdaki veya coğrafi ikincil konumdaki salt okunur bir çoğaltmaya bağlanmak için bu özelliği kullanabilirsiniz:

İkincil konumda salt okunur bir çoğaltmaya bağlanmak için ve <fog-name>.secondary.database.windows.netkullanınApplicationIntent=ReadOnly.

Yük devretmeden sonra olası performans düşüşü

Tipik bir Azure uygulaması birden çok Azure hizmeti kullanır ve birden çok bileşenden oluşur. Bir grubun yük devretmesi yalnızca Azure SQL Veritabanı durumuna bağlı olarak tetiklenir. Birincil bölgedeki diğer Azure hizmetleri kesintiden etkilenmeyebilir ve bileşenleri bu bölgede kullanılabilir durumda olabilir. Birincil veritabanları ikincil (DR) bölgesine geçtikten sonra bağımlı bileşenler arasındaki gecikme süresi artabilir. Daha yüksek gecikme süresinin uygulamanın performansı üzerindeki etkisini önlemek için DR bölgesindeki tüm uygulama bileşenlerinin yedekli olduğundan emin olun, bu ağ güvenlik yönergelerini izleyin ve veritabanıyla birlikte ilgili uygulama bileşenlerinin coğrafi yük devretmesini ayarlayın.

Zorlamalı yük devretme sonrasında olası veri kaybı

Birincil bölgede bir kesinti oluşursa son işlemler coğrafi ikincil bölgeye çoğaltılmamış olabilir ve zorlamalı yük devretme işlemi gerçekleştirilirse veri kaybı olabilir.

Önemli

800 veya daha az DTU veya 8 veya daha az sanal çekirdek içeren elastik havuzlar ve 250'den fazla veritabanı daha uzun planlanmış coğrafi yük devretmeler ve düşük performans gibi sorunlarla karşılaşabilir. Bu sorunların, coğrafi çoğaltmalar coğrafi olarak büyük ölçüde uzak olduğunda veya her veritabanı için birden fazla ikincil coğrafi çoğaltma kullanıldığında yoğun yazma içeren iş yükleri için ortaya çıkması daha olasıdır. Bu sorunların bir belirtisi de zaman içinde coğrafi çoğaltma gecikmesindeki artıştır ve bir kesintide potansiyel olarak daha yoğun veri kaybına yol açar. Bu gecikme sys.dm_geo_replication_link_status kullanılarak izlenebilir. Bu sorunlar ortaya çıkarsa azaltma işlemi, havuzun ölçeğini daha fazla DTU veya sanal çekirdeğe sahip olacak şekilde artırmayı veya havuzda coğrafi olarak çoğaltılan veritabanlarının sayısını azaltmayı içerir.

Yeniden çalışma

Yük devretme grupları Microsoft tarafından yönetilen bir yük devretme ilkesiyle yapılandırıldığında, tanımlanan yetkisiz kullanım süresine göre olağanüstü durum senaryosu sırasında coğrafi ikincil sunucuya zorlamalı yük devretme başlatılır. Eski birincil birincile yeniden çalışma el ile başlatılmalıdır.

İzinler ve sınırlamalar

İzinlerin ve sınırlamaların listesi için yük devretme grubunu yapılandırma kılavuzunu gözden geçirin.

Yük devretme gruplarını program aracılığıyla yönetme

Yük devretme grupları Azure PowerShell, Azure CLI ve REST API kullanılarak program aracılığıyla da yönetilebilir. Daha fazla bilgi için bkz. Yük devretme grubu yapılandırma.

İlgili içerik