Aracılığıyla paylaş

Yük devretme gruplarına genel bakış ve en iyi uygulamalar - Azure SQL Yönetilen Örnek

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

Bu makalede, Azure SQL Yönetilen Örneği ile kullanılacak en iyi yöntemler ve öneriler içeren yük devretme grubu özelliğine genel bir bakış sağlanmaktadır. Yük devretme grupları özelliği, SQL yönetilen örneğindeki 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.

Başlamak için Azure SQL Yönetilen Örneği için yük devretme grubunu yapılandırmayı gözden geçirin.

Genel bakış

Yük devretme grupları özelliği, farklı bir Azure bölgesindeki bir SQL yönetilen örneğinden başka bir SQL yönetilen örneğine kullanıcı veritabanlarının çoğaltması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 işlemleri 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ı dizesini değiştirmenize gerek yoktur çünkü bağlantılar otomatik olarak geçerli birincil veritabanı sunucusuna yönlendirilir. Coğrafi yük devretme, veritabanı grubundaki tüm ikincil veritabanlarını birincil role dönüştürür. 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 politikasını 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 politikası değeri manual olur.
  • Microsoft tarafından yönetilen - Birincil bölgeyi etkileyen yaygın bir 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 yönetimli için yük devretme ilkesi değeri 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ı Yük devretme grubundaki bir veya daha fazla veritabanı bir kesintiden etkilenir ve kullanılamaz duruma gelir. Yük devretmeyi seçebilirsiniz. Evet
Microsoft tarafından yönetildi Bölgedeki tüm yük devretme grupları Bölgedeki yaygın bir kesinti veritabanlarının kullanılamamasına neden olur ve Microsoft Azure SQL hizmet ekibi zorlamalı yük devretme 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.
Microsoft tarafından yönetilen yük devretme, yalnızca aşırı koşullarda gerçekleştirilebilir. Müşteri tarafından yönetilen bir yük devretme ilkesi kesinlikle önerilir.		 Evet

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 durumların herhangi birinde, iş sürekliliğini geri yüklemek için zorunlu bir yük devretme işlemi 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. Beklenmeyen bir kesintinin yük devretme grubundaki bir veya daha fazla veritabanını etkilediğini fark ettiğinizde yük devretme işlemini başlatabilirsiniz.

Microsoft tarafından yönetildi

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ı, yapılandırma değişiklikleri, yazılım hataları veya donanım bileşeni hataları ve bölgedeki birçok veritabanından kaynaklanan bölge düzeyinde kesintiler etkilenir.
  • Yetkisiz kullanım süresi doldu. Kesintinin ölçeğinin doğrulanması ve azaltılması insan eylemlerine bağlı olduğundan, müsaade süresi bir saatin altında ayarlanamaz.

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

Önemli

Olağanüstü durum kurtarma planınızı test etmek ve uygulamak için müşteri tarafından yönetilen yük devretme ilkesini kullanın. Microsoft tarafından yalnızca aşırı durumlarda yürütülebilecek Microsoft yönetimli yük devretmeye güvenmeyin. Bölgede yük devretme ilkesi Microsoft tarafından yönetilen olarak ayarlanmış tüm yük devretme grupları için Microsoft tarafından yönetilen bir yük devretme başlatılır. Tek tek yük devretme grupları için başlatılamaz. Yük devretme grubunuz üzerinde seçmeli olarak yük devretme yapmanız gerekiyorsa, müşteri tarafından yönetilen yük devretme ilkesini kullanın.

Yük devretme ilkesini yalnızca aşağıdaki durumlarda Microsoft tarafından yönetilen 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 devretmeleri tetikleme kabul edilebilir, çünkü zorlanan 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ılmış veritabanları, bölgesel hatalara karşı dayanıklı olsalar ve kesinti sonucunda etkilenmeyebilirler, ancak Microsoft tarafından yönetilen bir yük devretme politikasına sahip bir yük devretme grubunun parçası olduklarında, yine de yük devri yapılacaktır.
  • 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 kesin zamanının denetlenememesi ve ikincil veritabanlarının eşitleme durumunun yoksayıldığı için, bilinmeyen miktarda veri kaybına neden olmak kabul edilebilir.
  • Yük devretme grubundaki birincil ve ikincil çoğaltmalar aynı hizmet katmanına, işlem katmanına ve işlem boyutuna sahiptir.

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 Olayı başlatan kısmı, 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

  • Yedekleme grubu (FOG)

    Yük devretme grubu, birincil SQL yönetilen örneğinin birincil bölge kesintisi nedeniyle kullanılamaz duruma gelmesi durumunda SQL yönetilen örneği içindeki 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 SQL yönetilen örneği.

  • İkincil

    Yük devretme grubunda ikincil veritabanlarını barındıran SQL yönetilen örneği. İkincil, birincille aynı Azure bölgesinde yer alamaz.

    Ö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 yedekleme örneğinde daha düşük bir hizmet katmanı bellek yetersizliği sorunlarına neden olabilir. Bu durum meydana gelirse, ikincil çoğaltma veritabanını kurtaramayabilir ve bu da ikincil veritabanı ile birlikte coğrafi ikincil üzerinde bulunan bellek içi OLTP nesnelerinin kullanılamamasına yol açabilir. 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.

  • Yedekleme (veri kaybı yok)

    Failover, 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. Zorunlu yük devretme, birincil sistem erişilemez olduğunda kesintiler sırasında bir kurtarma yöntemi olarak kullanılır. Kesinti giderildiğinde, eski birincil otomatik olarak yeniden bağlanır ve yeni bir ikincil olur. Yük devretme, sistemin eski durumuna döndürülmesi için yürütülebilir ve çoğaltmalar özgün birincil ve ikincil rollerine geri dönüştürülür.

  • Veri kaybı olanaklı müsaade süresi

    Veriler asenkron replikasyon kullanılarak ikincil sunucuya çoğaltıldığı için, Microsoft tarafından yönetilen yük devretme ilkelerine sahip grupların zorunlu 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. Azure SQL hizmetinin zorlamalı yük devretmeyi başlatmadan önce ne kadar süre bekleyeceğini yapılandırarak GracePeriodWithDataLossHours ile denetleyebilir ve böylece veri kaybının meydana gelmesini önleyebilirsiniz.

  • DNS bölgesi

    Yeni bir SQL Yönetilen Örneği oluşturulduğunda otomatik olarak oluşturulan benzersiz bir kimlik. Bu örneğe yönelik olarak aynı DNS bölgesindeki herhangi bir örneğe yapılan istemci bağlantılarının kimliğini doğrulamak amacıyla çoklu etki alanı (SAN) sertifikası sağlanmaktadır. İki SQL yönetilen örnek aynı yük devretme grubundayken DNS bölgesini paylaşmalıdır.

  • Okuma-yazma yük devretme grubu dinleyicisi

    Geçerli birincile işaret eden bir DNS CNAME kaydı. Yük devretme grubu oluşturulduğunda otomatik olarak oluşturulur ve ana sunucu yük devretme sonrasında değiştiğinde okuma-yazma iş yükünün sorunsuz ve otomatik bir şekilde ana sunucuya yeniden bağlanmasına izin verir. SQL Yönetilen Örneğinde yük devretme grubu oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı <fog-name>.<zone_id>.database.windows.net olarak oluşturulur.

  • Yük devretme grubu salt okuma dinleyicisi

    Geçerli sekonder öğ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 sunucu değişiklik gösterdiğinde ikincil sunucuya sorunsuz bir şekilde bağlanmasına olanak tanır. SQL Yönetilen Örneğinde yük devretme grubu oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı <fog-name>.secondary.<zone_id>.database.windows.net olarak oluşturulur. Varsayılan olarak, salt okunur dinleyicinin yük devretmesi devre dışı bırakılır çünkü bu, ikincil çevrimdışı olduğunda birincil sunucunun performansının etkilenmemesini sağlar. Ancak, salt okunur oturumların, ikincil tamamen kurtarılana kadar bağlanamayacağı anlamına da gelir. Salt okunur oturumlar için kesintiyi tolere edemiyorsanız ve birincilin performansında olası bir düşüşü göze alarak hem salt okunur hem de yazma-okuma trafiği için birincili kullanmanız mümkünse, AllowReadOnlyFailoverToPrimary özelliğini yapılandırarak salt okunur dinleyici için yük devretmeyi 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 ana sunucu hem okuma-yazma hem de salt okunur oturumlara servis verir.

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. Birincil örnekteki tüm kullanıcı veritabanları ikincil örneğe çoğaltılır. Sistem veritabanları master ve msdb gibi çoğaltılamaz.

Aşağıdaki diyagramda, SQL yönetilen örneği ve yük devretme grubu kullanılarak coğrafi olarak yedekli bulut uygulamasının tipik 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şturun.

Yük devretme sonrasında birincil SQL Yönetilen Örneğine kesintisiz bağlantı sağlamak için hem birincil hem de ikincil örneklerin aynı DNS bölgesinde olması gerekir. Aynı çok etki alanlı (SAN) sertifikasının, yük devretme grubundaki iki örnekten birine yapılan istemci bağlantılarını doğrulamak için 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. Örneği oluştururken 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 SQL yönetilen örneği, 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 Azure SQL Yönetilen Örneği için yük devretme grubunu yapılandırma bölümüne bakın.

Eşleştirilmiş bölgeleri kullanma

Performans nedeniyle her iki SQL yönetilen örneğini çift 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ükseltildiği tahmin etmek mümkün değildir, bu nedenle dağıtım sırası garanti edilmez. 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ğlantı, kesintisiz coğrafi çoğaltma trafik akışı için kurulmalı ve korunmalıdır. 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 gerekli değildir.

İlk tohumlama

SQL yönetilen örnekleri 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 dengeli dağıtımı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 birincil ve ikincil örneği barındıran sanal ağlar arasındaki bağlantının hızına bağlıdır ve bu da çoğunlukla bağlantının kurulma şekline 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. Tohumlama, paralel olarak bir grup kullanıcı veritabanı için gerçekleştirilir, ancak aynı anda tüm veritabanları için gerçekleştirilmesi gerekmez. Ö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ürdüğünü 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önderebiliyorsa ve başka veritabanı tohumlanmıyorsa, başlangıç 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ılması gereken birden çok veritabanı varsa, tohumlama paralel olarak yürütülür. Yavaş bağlantı hızıyla birleştirildiğinde, özellikle tüm veritabanlarındaki 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

Başlangıç aşaması, çok düşük hızda veya yoğun bağlantılarla günler sürebilir. Bu durumda, yük devretme grubu oluşturma süreci zaman aşımına uğrayabilir. Altı gün sonra, yük devretme grubu oluşturma işlemi otomatik olarak iptal edilir.

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

Yük devretme grubu, ana SQL yönetilen örneğindeki 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 ç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

Birincil SQL yönetilen örneğinde bir veritabanı silinirse, coğrafi ikincil SQL yönetilen örneğinde de otomatik olarak silinir.

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ğlantılar otomatik olarak birincil sunucuya yönlendirilir. Failover'dan 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 SQL yönetilen örneği için açık uç nokta üzerinden erişilemez.

Salt okunur dinleyiciyi (ikincil MI) kullan

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 <fog-name>.secondary.<zone_id>.database.windows.net kullanın.

İş Açısından Kritik katmanında, bağlantı dizesindeki parametresini kullanarak salt okunur sorgu iş yüklerini boşaltmak için ApplicationIntent=ReadOnly destekleyen SQL Yönetilen Örneği bulunmaktadır. 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 konumdaki salt okunur bir çoğaltmaya bağlanmak için ApplicationIntent=ReadOnly ve <fog-name>.<zone_id>.database.windows.net kullanın.
  • İkincil konumda salt okunur bir çoğaltmaya bağlanmak için ApplicationIntent=ReadOnly ve <fog-name>.secondary.<zone_id>.database.windows.net kullanın.

Okuma-yazma dinleyicisine ve salt okunur dinleyiciye SQL yönetilen örneği için Genel uç nokta üzerinden erişilemiyor.

Yük devredildikten sonra olası performans bozulması

Tipik bir Azure uygulaması birden çok Azure hizmeti kullanır ve birden çok bileşenden oluşur. Grubun coğrafi yük devretmesi, yalnızca Azure SQL bileşenlerinin durumuna bağlı olarak tetikleniyor. Kesinti birincil bölgedeki diğer Azure hizmetlerini etkilemeyebilir ve bileşenleri bu bölgede kullanılabilir olmaya devam edebilir. Birincil veritabanları ikincil bölgeye geçtikten sonra bağımlı bileşenler arasındaki gecikme süresi artabilir. Uygulamanın performansını daha yüksek bölgeler arası gecikmenin etkilememesi için, ikincil bölgedeki tüm uygulama bileşenlerinin yedekli olmasını ve veritabanıyla birlikte uygulama bileşenlerinin birlikte yük devretmesini sağlayın.

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

Birincil bölgede bir kesinti oluşursa, en son işlemler ikincil coğrafi bölgeye çoğaltılmamış olabilir ve zorlamalı yük devretme 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 beş dakikaya kadar sürebilir. Tamamlanana kadar, yeni birincil örnekteki bazı veritabanları kısıtlı olarak erişilebilir olmaya devam edecektir. PowerShell kullanılarak bir yük devretme başlatılırsa, birincil çoğaltıcı rolünü değiştirme işlemi eşzamanlı 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 SQL 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 ve çoğaltmanın okunabilir bir çoğaltma olması veya yalnızca DR çoğaltması olarak atanması gerekir.

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 nesnelere bağlı senaryoları etkinleştirmek için, ikincil örnekte aynı nesneleri oluşturduğunuzdan emin olun. Bunları birincil örnekle eşitlenmiş durumda tutun.

Örneğin, ikincil örnekte aynı oturum açma bilgilerini kullanmayı planlıyorsanız, bunları aynı SIDile 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ı görevlerini çoğaltma.

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

Yük devretme grubundaki örnekler Azure kaynaklarından ayrı 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 yaptığınızdan 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ğinizin yapılandırması aynı olmalıdır. Buna işlem boyutu, depolama boyutu ve hizmet katmanı dahildir. Yük devretme grubunuzun yapılandırmasını değiştirmeniz gerekiyorsa, her örneği uygun şekilde aynı yapılandırmaya ölçeklendirerek bunu yapabilirsiniz. Daha fazla bilgi edinmek için Yük devretme grubundaki örnekleri ölçeklendirme'yi gözden geçirin.

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. Asenkron replikasyon, birincil başarısız olursa veri kaybı olasılığını kaçınılmaz hale getirir. Verilerinizi nasıl koruyabileceğinizi öğrenmek için Veri kaybını önleme'yi gözden geçirin.

Yük devretme grubu durumu

Yük devretme grubu veri çoğaltmanın mevcut durumunu açıklayan bir durum raporu sunar.

  • 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 başlatılamaz.
  • Senkronizasyon: Arıza durumu grubunun olağan 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. Bir yük devretme grubundaki örnekler arasında çoğaltma işleminin zaman uyumsuz yapısı nedeniyle, birincil sistemden ikincil sisteme henüz çoğaltılmamış veri değişiklikleri olabilir. Yük devretme grubu Eşitleme durumundayken hem otomatik yük devretme hem de el ile yük devretme başlatılabilir.
  • Yük devretme devam ediyor: Bu durum, otomatik veya manuel olarak 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.

Geri Dönüş

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

Birlikte çalışabilirlik özelliği

Yedekler

Aşağıdaki senaryolarda tam yedekleme yapılır:

  • Yük devretme grubu oluşturduğunuzda ilk başlatma işlemi başlamadan önce.
  • Failover işleminden sonra.

Tam yedekleme, atlanamaz veya ertelenemez ve tamamlanması biraz zaman alabilir veri işleminin boyutudur. Tamamlanma süresi, verilerin boyutuna, veritabanı sayısına ve birincil veritabanlarındaki iş yükü yoğunluğuna bağlıdır. Tam yedekleme, ilk dağıtımı önemli ölçüde geciktirebilir ve yük devretme işleminden kısa süre sonra yeni bir örnekte yük devretme işlemini geciktirebilir veya engelleyebilir.

Aşağıdakileri göz önünde bulundurun:

  • Bir yük devretme grubunun ikincil örneğinde barındırılan veritabanları, yük devretme sonrasında birincil duruma gelene kadar veya yük devretme grubu bırakılana kadar yedeklenmez.
  • Bir veritabanı yük devretmeden sonra birincil role geçtikten veya bir yük devretme grubu bırakıldıktan sonra tek başına duruma geldikten sonra, belirli bir noktaya geri yüklemeyi kolaylaştırmak için otomatik olarak tam veritabanı yedeklemesi başlatılır.
  • Veritabanı bir örnekten o örneğin bir yük devretme grubunda ikincil çoğaltma olduğu bir noktaya geri yüklenemez. Belirli bir noktaya geri yüklemek için veritabanını o zaman noktasında birincil olan örnekten geri yüklemeniz gerekir.
  • Aynı SQL yönetilen örneği çiftinde bırakılan bir yük devretme grubunu yeniden oluşturmak için, yük devretme grubu bırakıldıktan sonra tüm kullanıcı veritabanlarının hedeflenen ikincil gruptan kaldırılması gerekir. Veritabanı, yalnızca tüm bekleyen yedekleme işlemleri tamamlandıktan sonra tamamen kaldırılır ve bir veritabanı alınmadıysa (veri boyutu işlemidir) tam yedekleme de dahil olmak üzere. Çok büyük veritabanlarına sahip bir yük devretme grubunu bıraktıktan sonra ikincil örneği temizlemek için zaman tanıyın. Her veritabanında bekleyen bir tam yedekleme işlemi devam ediyor olabilir.

Tam yedekleme, atlanamaz veya ertelenemez ve tamamlanması biraz zaman alabilir veri işleminin boyutudur. Tamamlanma süresi, verilerin boyutuna, veritabanı sayısına ve birincil veritabanlarındaki iş yükü yoğunluğuna bağlıdır. Tam yedekleme, ilk dağıtımı önemli ölçüde geciktirebilir ve yük devretme işleminden kısa süre sonra yeni bir örnekte yük devretme işlemini geciktirebilir veya engelleyebilir.

Günlüğü Yeniden Yürütme Hizmeti

Azure SQL Yönetilen Örneği'ne Log Replay Service (LRS) kullanılarak geçirilen veritabanları, kesinti adımı gerçekleştirilene kadar yük devretme grubuna eklenemez. LRS ile geçirilen veritabanı, tam geçişe kadar geri yüklenme aşamasındadır ve geri yüklenme aşamasındaki veritabanlarına yük devretme grubuna ekleme yapılamaz. Geri yükleme durumundaki bir veritabanıyla yük devretme grubu oluşturmaya çalışmak, veritabanı geri yüklemesi tamamlanana kadar yük devretme grubunun oluşturulmasını geciktiriyor.

Transaksiyonel çoğaltma

Yük devretme grubundaki örnekler üzerinde 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. Çoğaltma izleyicisi durumu Replicated transactions are waiting for the next log backup or for mirroring partner to catch up olarak gösterir. Yük devretme grubu başarıyla oluşturulduktan sonra çoğaltma devam etmeye başlar.

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 ve sınırlamalar

Yük devretme grubunu yapılandırmadan önce izinlerin ve sınırlamaların listesini gözden geçirin.

Program aracılığıyla yük devretme gruplarını 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ırma'ya bakın.

Olağanüstü durum kurtarma tatbikatları

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

Zorlamalı yük devretmeyi kullanarak tatbikat yapmak, bu işlem veri kaybına karşı koruma sağlamadığı için ö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 SQL yönetilen örneğinde durdurulur.
  • Uzun süre çalışan tüm işlemler tamamlandı.
  • Birincil SQL yönetilen örneğine yönelik tüm istemci bağlantılarının bağlantısı kesildi.
  • Yük devretme grubu durumu: 'Senkronize Ediliyor'.

Lütfen iki SQL yönetilen örneğinin rolleri değiştirildiğinden emin olun. Ayrıca, okuma-yazma iş yükünü başlatmadan ve isteğe bağlı olarak yeni birincil SQL yönetilen örneğine bağlantı kurmadan önce yük devretme grubu durumunun 'Yük devretme devam ediyor'dan 'Eşitleme' olarak değiştiğini de belirtebilirsiniz.

Özgün SQL yönetilen örnek rollerine veri kaybı olmadan geri dönüş yapmak için zorlamalı yük devretme yerine manuel planlanmış yük devretmenin kullanılması kesinlikle önerilir. Zorlamalı geri dönüş kullanılıyorsa:

  • Veri kaybı olmadan yük devretme ile aynı adımları izleyin.
  • İlk zorlamalı yük devretme tamamlandıktan kısa süre sonra zorlamalı geri dönüş gerçekleştirilirse, önceki birincil SQL yönetilen örneğinde devam eden otomatik yedekleme işlemlerinin tamamlanmasını beklemesi gerektiğinden, daha uzun sürede gerçekleştirilmesi beklenir.
  • Bir örnekte birincil rolden ikincil role geçiş yapılan tüm bekleyen otomatik yedekleme işlemleri, bu örnekteki veritabanı kullanılabilirliğini etkileyebilir.
  • Her iki örneğin de rollerini başarıyla değiştirip değiştirmediğini ve istemci bağlantılarını kabul etmeye hazır olup olmadığını belirlemek için lütfen yük devretme grubu durumunu kullanın.

İlgili içerik

  • Last updated on