Yük devretme gruplarına genel bakış ve en iyi yöntemler - Azure SQL Yönetilen Örneği

  • Makale

Şunlar için geçerlidir:Azure SQL Yönetilen Örneği

Yük devretme grupları özelliği, yönetilen örnekteki tüm kullanıcı veritabanlarının başka bir Azure bölgesine çoğaltılmasını ve yük devretmesini yönetmenizi sağlar. Bu makalede, Azure SQL Yönetilen Örneği ile birlikte kullanmaya yönelik en iyi yöntemler ve öneriler içeren yük devretme grubu özelliğine genel bir bakış sunulmaktadır.

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

Genel bakış

Yük devretme grupları özelliği, yönetilen örnekteki kullanıcı veritabanlarının başka bir Azure bölgesindeki yönetilen örneğe çoğaltılmasını ve yük devretmesini yönetmenizi sağlar. Yük devretme grupları, 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ıştır.

Daha fazla bilgi için bkz. Azure SQL Yönetilen Örneği için yüksek kullanılabilirlik. 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ı ve coğrafi dağıtım ilişkileri aynı hizmet katmanına, işlem katmanına (sağlanan veya sunucusuz) ve işlem boyutuna (DTU'lar veya sanal çekirdekler) sahiptir. 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ölge kesintisi nedeniyle birincil yönetilen örneğin kullanılamaz duruma gelmesi durumunda yönetilen örnekteki tüm kullanıcı veritabanlarının birim olarak başka bir Azure bölgesine yük devretmesine olanak tanır. SQL Yönetilen Örneği için yük devretme grupları örnekteki tüm kullanıcı veritabanlarını içerdiğinden, bir örnekte yalnızca bir yük devretme grubu yapılandırılabilir.

    Önemli

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

  • Birincil

    Yük devretme grubunda birincil veritabanlarını barındıran yönetilen örnek.

  • İkincil

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

    Önemli

    • Bir veritabanı bellek içi OLTP nesneleri içeriyorsa, bellek içi OLTP nesneleri bellekte bulunduğundan birincil ve ikincil coğrafi çoğaltma örneğinin eşleşen hizmet katmanları olmalıdır. Coğrafi çoğaltma örneğinde daha düşük bir hizmet katmanı bellek yetersiz sorunlarına neden olabilir. Bu durumda ikincil çoğaltma veritabanını kurtaramayabilir ve ikincil veritabanının kullanılamamasına ve coğrafi ikincildeki bellek içi OLTP nesnelerinin kullanılabilir olmamasına neden olabilir. Bu da yük devretmenin başarısız olmasına neden olabilir. Bunu önlemek için coğrafi ikincil örneğin hizmet katmanının birincil veritabanıyla eşleştiğinden emin olun. Hizmet katmanı yükseltmeleri veri boyutu işlemleri olabilir ve tamamlanması biraz zaman alabilir.

  • 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.

  • DNS bölgesi

    Yeni bir SQL Yönetilen Örneği oluşturulduğunda otomatik olarak oluşturulan benzersiz bir kimlik. Bu örnek için bir çok etki alanı (SAN) sertifikası, aynı DNS bölgesindeki herhangi bir örneğe yönelik istemci bağlantılarının kimliğini doğrulamak için sağlanır. Aynı yük devretme grubundaki iki yönetilen örneğin DNS bölgesini paylaşması gerekir.

  • 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. Yük devretme grubu bir SQL Yönetilen Örneği oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.<zone_id>.database.windows.netoluşturulur.

  • 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. Yük devretme grubu bir SQL Yönetilen Örneği oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.secondary.<zone_id>.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.

Yük devretme grubu mimarisi

Yük devretme grubu birincil örnekte yapılandırılmalıdır ve bunu farklı bir Azure bölgesindeki ikincil örneğe bağlar. Örnekteki tüm kullanıcı veritabanları ikincil örneğe çoğaltılır. ve msdb gibi master sistem veritabanları çoğaltılamaz.

Aşağıdaki diyagramda, yönetilen örnek ve yük devretme grubu kullanılarak coğrafi olarak yedekli bulut uygulamasının tipik bir yapılandırması gösterilmektedir:

Azure SQL Yönetilen Örneği için yük devretme grubunun diyagramı.

Uygulamanız veri katmanı olarak SQL Yönetilen Örneği kullanıyorsa, iş sürekliliği tasarımı yaparken bu makalede açıklanan genel yönergeleri ve en iyi yöntemleri izleyin.

Coğrafi ikincil örneği oluşturma

Yük devretme sonrasında birincil SQL Yönetilen Örneği kesintisiz bağlantı sağlamak için hem birincil hem de ikincil örneklerin aynı DNS bölgesinde olması gerekir. Yük devretme grubundaki iki örnekten herhangi biriyle istemci bağlantılarının kimliğini doğrulamak için aynı çok etki alanı (SAN) sertifikasının kullanılabileceğini garanti eder. Uygulamanız üretim dağıtımına hazır olduğunda, farklı bir bölgede ikincil bir SQL Yönetilen Örneği oluşturun ve DNS bölgesini birincil SQL Yönetilen Örneği ile paylaştığından emin olun. Oluşturma sırasında isteğe bağlı bir parametre belirterek bunu yapabilirsiniz. PowerShell veya REST API kullanıyorsanız isteğe bağlı parametrenin adı olur DNSZonePartner. Azure portalda buna karşılık gelen isteğe bağlı alanın adı Birincil Yönetilen Örnek'tir.

Önemli

Alt ağda oluşturulan ilk yönetilen örnek, aynı alt ağda sonraki tüm örnekler için DNS bölgesini belirler. Başka bir deyişle, aynı alt ağdan iki örnek farklı DNS bölgelerine ait olamaz.

Birincil örnekle aynı DNS bölgesinde ikincil SQL Yönetilen Örneği oluşturma hakkında daha fazla bilgi için bkz. Azure SQL Yönetilen Örneği için yük devretme grubu yapılandırma.

Eşleştirilmiş bölgeleri kullanma

Performans nedenleriyle her iki yönetilen örneği de eşleştirilmiş bölgelere dağıtın. Eşleştirilmiş bölgelerdeki SQL Yönetilen Örneği yük devretme grupları, eşleştirilmemiş bölgelerdekilere göre daha iyi performansa sahiptir.

Azure SQL Yönetilen Örneği, Azure eşleştirilmiş bölgelerinin genellikle aynı anda dağıtılmadığı güvenli bir dağıtım uygulamasını izler. Ancak önce hangi bölgenin yükseltileceğini tahmin etmek mümkün olmadığından dağıtım sırası garanti edilmeyecektir. Bazen önce birincil örneğiniz yükseltilir, bazen de önce ikincil örnek yükseltilir.

Azure SQL Yönetilen Örneği bir yük devretme grubunun parçası olduğu ve gruptaki örneklerin Azure eşleştirilmiş bölgelerinde olmadığı durumlarda, birincil ve ikincil veritabanınız için farklı bakım penceresi zamanlamaları seçin. Örneğin, coğrafi ikincil veritabanınız için bir Hafta içi bakım penceresi ve coğrafi birincil veritabanınız için hafta sonu bakım penceresi seçin.

Örnekler arasında coğrafi çoğaltma trafik akışını etkinleştirme ve iyileştirme

Birincil ve ikincil örneği barındıran sanal ağ alt ağları arasındaki Bağlan üretkenliğin kesintisiz coğrafi çoğaltma trafik akışı için oluşturulması ve korunması gerekir. Ağ topolojinize ve ilkelerinize göre aralarından seçim yapabileceğiniz örnekler arasında bağlantı sağlamanın birden çok yolu vardır:

Genel sanal ağ eşlemesi (VNet eşlemesi), bir yük devretme grubundaki iki örnek arasında bağlantı kurmanın önerilen yoludur. Microsoft omurga altyapısını kullanarak, eşlenen sanal ağlar arasında düşük gecikmeli, yüksek bant genişliğine sahip bir özel bağlantı sağlar. Eşlenen sanal ağlar arasındaki iletişimde genel İnternet, ağ geçitleri veya ek şifreleme gerekmez.

İlk tohumlama

Yönetilen örnekler arasında bir yük devretme grubu oluşturulurken, veri çoğaltma başlamadan önce bir ilk tohumlama aşaması vardır. İlk tohumlama aşaması, işlemin en uzun ve en pahalı kısmıdır. İlk tohumlama tamamlandıktan sonra veriler eşitlenir ve yalnızca sonraki veri değişiklikleri çoğaltılır. İlk tohumlamanın tamamlanması için gereken süre, verilerin boyutuna, çoğaltılan veritabanlarının sayısına, birincil veritabanlarındaki iş yükü yoğunluğuna ve çoğunlukla bağlantının kurulma şekline bağlı olan birincil ve ikincil örneği barındıran sanal ağlar arasındaki bağlantının hızına bağlıdır. Normal koşullarda ve önerilen genel sanal ağ eşlemesi kullanılarak bağlantı kurulduğunda, SQL Yönetilen Örneği için tohumlama hızı saatte 360 GB'a kadar çıkar. Aynı anda tüm veritabanları için değil, paralel olarak bir grup kullanıcı veritabanı için tohumlama gerçekleştirilir. Örnekte barındırılan çok sayıda veritabanı varsa birden çok toplu işlem gerekebilir.

İki örnek arasındaki bağlantının hızı gerekenden daha yavaşsa, tohumlanma süresi büyük olasılıkla belirgin bir şekilde etkilenecektir. Veri çoğaltma başlamadan önce ilk tohumlama aşamasının ne kadar süreceğini tahmin etmek için belirtilen tohumlama hızını, veritabanı sayısını, toplam veri boyutunu ve bağlantı hızını kullanabilirsiniz. Örneğin, tek bir 100 GB veritabanı için bağlantı saatte 84 GB gönderemiyorsa ve başka veritabanı yoksa ilk tohum aşaması yaklaşık 1,2 saat sürebilir. Bağlantı saatte yalnızca 10 GB aktarabiliyorsa, 100 GB'lık bir veritabanının tohumlanması yaklaşık 10 saat sürebilir. Çoğaltılacak birden çok veritabanı varsa, tohumlama paralel olarak yürütülür ve yavaş bağlantı hızıyla birleştirildiğinde, özellikle tüm veritabanlarından verilerin paralel olarak dağıtılması kullanılabilir bağlantı bant genişliğini aşarsa ilk dağıtım aşaması çok daha uzun sürebilir.

Önemli

Son derece düşük hızlı veya meşgul bir bağlantının ilk tohumlama aşamasının günler sürmesine neden olması durumunda yük devretme grubunun oluşturulması zaman aşımına uğratılabilir. Oluşturma işlemi 6 gün sonra otomatik olarak iptal edilir.

Coğrafi ikincil örneğe coğrafi yük devretmeyi yönetme

Yük devretme grubu, birincil yönetilen örnekteki tüm veritabanlarının coğrafi yük devretmesini yönetir. Bir grup oluşturulduğunda, örnekteki her veritabanı otomatik olarak coğrafi ikincil örneğe coğrafi olarak çoğaltılır. Veritabanlarının bir alt kümesinin kısmi yük devretmesini başlatmak için yük devretme gruplarını kullanamazsınız.

Önemli

Bir veritabanı birincil yönetilen örneğe bırakılırsa, coğrafi olarak ikincil yönetilen örneğe de otomatik olarak bırakılır.

Okuma-yazma dinleyicisini (birincil MI) kullanma

Okuma-yazma iş yükleri için sunucu adı olarak kullanın <fog-name>.zone_id.database.windows.net . Bağlan ions otomatik olarak birincile yönlendirilir. Yük devretmeden sonra bu ad değişmez. Coğrafi yük devretme, DNS kaydının güncelleştirilmesini içerir, bu nedenle yeni istemci bağlantıları yalnızca istemci DNS önbelleği yenilendikten sonra yeni birincil sunucuya yönlendirilir. İkincil örnek DNS bölgesini birincil ile paylaştığından, istemci uygulama aynı sunucu tarafı SAN sertifikasını kullanarak bu bölgeye yeniden bağlanabilir. Mevcut istemci bağlantılarının sonlandırılıp yeni birincil sunucuya yönlendirilmesi için yeniden oluşturulması gerekir. Okuma-yazma dinleyicisine ve salt okunur dinleyiciye yönetilen örnek için genel uç nokta üzerinden erişilemiyor.

Salt okunur dinleyiciyi (ikincil MI) kullanma

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. Doğrudan coğrafi ikincil sunucuya bağlanmak için sunucu adı olarak kullanın <fog-name>.secondary.<zone_id>.database.windows.net .

İş Açısından Kritik katmanında SQL Yönetilen Örneği, 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 olarak çoğaltılmış bir ikincil yapılandırma yaptığınızda, birincil konumda veya coğrafi olarak çoğaltılan konumda salt okunur bir çoğaltmaya bağlanmak için bu özelliği kullanabilirsiniz:

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

Okuma-yazma dinleyicisine ve salt okunur dinleyiciye yönetilen örnek için genel uç nokta üzerinden erişilemiyor.

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

Tipik bir Azure uygulaması birden çok Azure hizmeti kullanır ve birden çok bileşenden oluşur. Yalnızca Azure SQL bileşenlerinin durumuna bağlı olarak grubun coğrafi yük devretmesi tetikleniyor. Birincil bölgedeki diğer Azure hizmetleri kesintiden etkilenmeyebilir ve bileşenleri bu bölgede kullanılabilir durumda olabilir. Birincil veritabanları ikincil bölgeye geçtikten sonra bağımlı bileşenler arasındaki gecikme süresi artabilir. İkincil bölgedeki tüm uygulama bileşenlerinin yedekli olduğundan emin olun ve uygulamanın performansının bölgeler arası gecikme süresinden etkilenmemesi için veritabanıyla birlikte uygulama bileşenlerinin yük devretmesini sağlayı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.

DNS güncelleştirmesi

Okuma-yazma dinleyicisinin DNS güncelleştirmesi, yük devretme başlatıldıktan hemen sonra gerçekleşir. Bu işlem veri kaybına neden olmaz. Ancak, veritabanı rollerini değiştirme işlemi normal koşullarda 5 dakikaya kadar sürebilir. Tamamlanana kadar, yeni birincil örnekteki bazı veritabanları salt okunur olmaya devam eder. PowerShell kullanılarak bir yük devretme başlatılırsa, birincil çoğaltma rolünü değiştirme işlemi zaman uyumlu olur. Azure portalı kullanılarak başlatılırsa kullanıcı arabirimi tamamlanma durumunu gösterir. REST API kullanılarak başlatılırsa, tamamlamayı izlemek için standart Azure Resource Manager'ın yoklama mekanizmasını kullanın.

Önemli

Coğrafi yük devretmeye neden olan kesinti azaltıldıktan sonra birincil konumu özgün konuma geri taşımak için el ile planlı yük devretmeyi kullanın.

Lisanssız DR çoğaltması ile maliyet tasarrufu

İkincil yönetilen örneğinizi yalnızca olağanüstü durum kurtarma (DR) için kullanılacak şekilde yapılandırarak SQL Server lisans maliyetlerinden tasarruf edebilirsiniz. Bunu ayarlamak için bkz. Azure SQL Yönetilen Örneği için lisanssız bekleme çoğaltması yapılandırma.

İkincil örnek okuma iş yükleri için kullanılmadıkça, Microsoft size birincil örnekle eşleşmesi için ücretsiz sayıda sanal çekirdek sağlar. İkincil örnek tarafından kullanılan işlem ve depolama için hala ücretlendirilirsiniz. Yük devretme grupları yalnızca bir çoğaltmayı destekler. Çoğaltma okunabilir bir çoğaltma olmalı veya yalnızca DR çoğaltması olarak belirlenmelidir.

Sistem veritabanlarındaki nesnelere bağımlı senaryoları etkinleştirme

Sistem veritabanları, bir yük devretme grubundaki ikincil örneğe çoğaltılmaz. Sistem veritabanlarındaki nesnelerin kullanıldığı senaryoları etkinleştirmek için ikincil örnekte aynı nesneleri oluşturun ve bunları birincil örnekle eşitlenmiş durumda tutmayı unutmayın.

Örneğin, ikincil örnekte aynı oturum açma bilgilerini kullanmayı planlıyorsanız, bunları aynı SID ile oluşturduğunuzdan emin olun.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Daha fazla bilgi için bkz. Oturum açma bilgilerini ve aracı işlerini çoğaltma.

Örnek özelliklerini ve bekletme ilkeleri örneklerini eşitleme

Yük devretme grubundaki örnekler ayrı Azure kaynakları olarak kalır ve birincil örneğin yapılandırmasında yapılan hiçbir değişiklik otomatik olarak ikincil örneğe çoğaltılamaz. Hem birincil hem de ikincil örnekte tüm ilgili değişiklikleri gerçekleştirdiğinden emin olun. Örneğin, birincil örnekte yedekleme depolama yedekliliğini veya uzun süreli yedekleme saklama ilkesini değiştirirseniz, bunu ikincil örnekte de değiştirdiğinizden emin olun.

Örnekleri ölçeklendirme

Birincil ve ikincil örneğin ölçeğini artırarak veya azaltarak aynı hizmet katmanında farklı bir işlem boyutuna veya farklı bir hizmet katmanına ulaşabilirsiniz. Ölçeği aynı hizmet katmanında büyütürken önce coğrafi ikincil ölçeği artırmanızı ve ardından birincil katmanın ölçeğini artırmanızı öneririz. Aynı hizmet katmanında ölçeği daraltırken sırayı tersine çevirin: önce birincil katmanın ölçeğini küçültün ve ardından ikincil katmanın ölçeğini küçültün. Örneği farklı bir hizmet katmanına ölçeklendirirken bu öneri zorunlu tutulur. hizmet katmanı ve sanal çekirdeklerin yanı sıra depolama ölçeklendirilirken işlem dizisi uygulanır.

Daha düşük bir SKU'da olan coğrafi ikincil örnek aşırı yüklendiğinde ve yükseltme veya sürüm düşürme işlemi sırasında yeniden dağıtılması gerektiğinde oluşan sorundan kaçınmak için bu sıralamanın kullanılması önerilir.

Not

İlgili yük devretme grubu dinleyicisi kullanılarak ölçeklendirilen örneğin erişilebilirliğini etkiebilen bilinen bir sorun vardır.

Kritik veri kaybını önleme

Geniş alan ağlarının yüksek gecikme süresi nedeniyle, coğrafi çoğaltma zaman uyumsuz bir çoğaltma mekanizması kullanır. Zaman uyumsuz çoğaltma, birincil başarısız olursa veri kaybı olasılığını kaçınılmaz hale getirir. Kritik işlemleri veri kaybına karşı korumak için, uygulama geliştiricisi işlemi işledikten hemen sonra sp_wait_for_database_copy_sync saklı yordamı çağırabilir. Çağırma sp_wait_for_database_copy_sync , son işlenen işlem ikincil veritabanının işlem günlüğünde iletilip sağlamlaştırılana kadar çağıran iş parçacığını engeller. Ancak, iletilen işlemlerin ikincil işlemde yeniden oynatılması (yeniden yapılması) için beklemez. sp_wait_for_database_copy_sync kapsamı belirli bir coğrafi çoğaltma bağlantısıyla belirlenmiştir. Birincil veritabanına bağlantı hakları olan tüm kullanıcılar bu yordamı çağırabilir.

Kullanıcı tarafından başlatılan, planlanan coğrafi yük devretme sırasında veri kaybını önlemek için, çoğaltma otomatik olarak ve geçici olarak zaman uyumlu çoğaltmaya değişir, ardından yük devretme gerçekleştirir. Ardından coğrafi yük devretme tamamlandıktan sonra çoğaltma zaman uyumsuz moda döner.

Not

sp_wait_for_database_copy_sync belirli işlemler için coğrafi yük devretme sonrasında veri kaybını önler, ancak okuma erişimi için tam eşitlemeyi garanti etmez. Yordam sp_wait_for_database_copy_sync çağrısının neden olduğu gecikme önemli olabilir ve çağrı sırasında birincilde henüz iletilmeyen işlem günlüğünün boyutuna bağlıdır.

Yük devretme grubu durumu

Yük devretme grubu, veri çoğaltmanın geçerli durumunu açıklayan durumunu bildirir:

  • Tohumlama - tüm kullanıcı veritabanları ikincil örnekte başlatılana kadar yük devretme grubu oluşturulduktan sonra ilk tohumlama gerçekleştirilir. Kullanıcı veritabanları henüz ikincil örneğe kopyalanmadığından yük devretme grubu Tohumlama durumundayken yük devretme işlemi başlatılamaz.
  • Eşitleme - yük devretme grubunun normal durumu. Bu, birincil örnekteki veri değişikliklerinin ikincil örneğe zaman uyumsuz olarak çoğaltıldığı anlamına gelir. Bu durum, verilerin her an tam olarak eşitlenmesini garanti etmez. Yük devretme grubundaki örnekler arasındaki çoğaltma işleminin zaman uyumsuz yapısı nedeniyle birincilden ikincilye yine de çoğaltılacak veri değişiklikleri olabilir. Yük devretme grubu Eşitleme durumundayken hem otomatik hem de el ile yük devretme başlatılabilir.
  • Yük devretme devam ediyor - Bu durum otomatik olarak veya el ile başlatılan yük devretme işleminin devam ettiğini gösterir. Yük devretme grubu bu durumdayken yük devretme grubunda herhangi bir değişiklik veya ek yük devretme başlatılamaz.

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.

İşlem çoğaltması olan yük devretme grupları

Yük devretme grubundaki örneklerle işlem çoğaltması kullanılması desteklenir. Ancak, SQL yönetilen örneğinizi bir yük devretme grubuna eklemeden önce çoğaltmayı yapılandırırsanız, yük devretme grubunuzu oluşturmaya başladığınızda çoğaltma duraklatılır ve çoğaltma izleyicisi Replicated transactions are waiting for the next log backup or for mirroring partner to catch updurumunu gösterir. Yük devretme grubu başarıyla oluşturulduktan sonra çoğaltma devam eder.

Yayımcı veya dağıtımcı SQL yönetilen örneği bir yük devretme grubundaysa, SQL yönetilen örneği yöneticisinin eski birincildeki tüm yayınları temizlemesi ve bir yük devretme gerçekleştikten sonra bunları yeni birincilde yeniden yapılandırması gerekir. Bu senaryoda gerekli olan etkinliklerin adımı için işlem çoğaltma kılavuzunu gözden geçirin.

İzinler, sınırlamalar ve önkoşullar

Yük devretme grubunu yapılandırmaya devam etmeden önce izinler, sınırlamalar ve önkoşulları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 edinmek için yük devretme grubunu yapılandırmayı gözden geçirin.

Olağanüstü durum kurtarma tatbikatları

Dr tatbikatı gerçekleştirmenin önerilen yolu, aşağıdaki öğreticiye göre el ile planlanan yük devretmeyi kullanmaktır: Yük devretme testi.

Bu işlem veri kaybına karşı koruma sağlamadığından zorlamalı yük devretme kullanarak bir tatbikat gerçekleştirmeniz önerilmez. Bununla birlikte, zorlamalı yük devretmeyi başlatmadan önce aşağıdaki koşulların karşılandığından emin olarak veri kaybı olmayan zorlamalı yük devretme elde etmek mümkündür:

  • İş yükü birincil yönetilen örnekte durdurulur.
  • Uzun süre çalışan tüm işlemler tamamlandı.
  • Birincil yönetilen örneğe yönelik tüm istemci bağlantılarının bağlantısı kesildi.
  • Yük devretme grubu durumu :'Eşitleme'.

İsteğe bağlı olarak yeni birincil yönetilen örneğe bağlantı kurmadan ve okuma-yazma iş yükünü başlatmadan önce yönetilen iki örneğin rol değiştirdiğinden ve yük devretme grubu durumunun 'Yük devretme sürüyor' durumundan 'Eşitleme' olarak değiştiğinden emin olun.

Özgün yönetilen örnek rollerinde veri kaybı olmayan bir yeniden çalışma gerçekleştirmek için zorlamalı yük devretme yerine el ile planlanmış yük devretme kullanılması kesinlikle önerilir. Zorlamalı yeniden çalışma ile devam etmek için:

  • Veri kaybı olmayan yük devretme ile aynı adımları izleyin.
  • Önceki birincil yönetilen örnekte bekleyen otomatik yedekleme işlemlerinin tamamlanmasını beklemek zorunda olduğundan, ilk zorlamalı yük devretme tamamlandıktan kısa süre sonra zorlamalı yeniden çalışma yürütülürse daha uzun yeniden çalışma yürütme süresi beklenir.

İlgili içerik