Otomatik yük devretme gruplarına genel bakış & en iyi yöntemleri (Azure SQL Veritabanı)

  • Makale
  • Okumak için 18 dakika

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

Otomatik yük devretme grupları özelliği, mantıksal sunucudaki veritabanlarının bir kısmının veya tümünün başka bir bölgeye çoğaltılmasını ve yük devretmesini yönetmenize olanak tanır. Bu makale, Azure SQL Veritabanı ve bazı en iyi yöntemlerle Otomatik yük devretme grubu özelliğini kullanmaya odaklanmaktadır.

Başlamak için Otomatik yük devretme grubunu yapılandırma bölümünü gözden geçirin. Uçtan uca deneyim için Otomatik yük devretme grubu öğreticisine bakın.

Not

  • Bu makale, Azure SQL Veritabanı için otomatik yük devretme gruplarını kapsar. Azure SQL Yönetilen Örneği için bkz. Azure SQL Yönetilen Örneği'da otomatik yük devretme grupları.
  • Otomatik yük devretme grupları, gruptaki tüm veritabanlarının farklı bir bölgedeki yalnızca bir ikincil sunucuya coğrafi çoğaltmasını destekler. Aynı birincil çoğaltma için birden çok Azure SQL Veritabanı coğrafi ikincil çoğaltması (aynı veya farklı bölgelerde) oluşturmanız gerekiyorsa etkin coğrafi çoğaltma kullanın.

Genel Bakış

Otomatik yük devretme grupları özelliği, bir sunucudaki bir grup veritabanının veya 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, 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.

Otomatik yük devretme

Coğrafi yük devretmeyi el ile başlatabilir veya kullanıcı tanımlı bir ilkeye göre Azure hizmetine devredebilirsiniz. İkinci seçenek, yıkıcı bir hatadan veya birincil bölgedeki SQL Veritabanı veya SQL Yönetilen Örneği kullanılabilirliğinin tam veya kısmen kaybolmasına neden olan planlanmamış başka bir olaydan sonra ikincil bölgedeki birden çok ilişkili veritabanını otomatik olarak kurtarmanıza olanak tanır. Bunlar genellikle yerleşik yüksek kullanılabilirlik altyapısı tarafından otomatik olarak giderilemeyen kesintilerdir. Coğrafi yük devretme tetikleyicilerine örnek olarak doğal olağanüstü durumlar veya işlem düğümlerindeki işletim sistemi çekirdeği bellek sızıntısı nedeniyle kiracı veya denetim kademesinin kapalı olmasından kaynaklanan olaylar verilebilir. Daha fazla bilgi için bkz. yüksek kullanılabilirlik Azure SQL.

Salt okunur iş yüklerini boşaltma

Birincil veritabanlarınıza yönelik 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.

Uç nokta yeniden yönlendirme

Otomatik 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. Bu, coğrafi yük devretme sonrasında uygulamanızın bağlantı dizesini değiştirmeniz gerekmediği anlamına gelir çünkü bağlantılar otomatik olarak geçerli birincil sunucuya yönlendirilir. İster el ile ister otomatik yük devretme etkinleştirmesi kullanın, 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. Coğrafi yük devretme RPO ve RTO için bkz. İş Sürekliliğine Genel Bakış.

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ı (hizmet) uçtan uca kurtarmak için, hizmeti oluşturan tüm bileşenlerin ve bağımlı hizmetlerin kurtarılması gerekir. 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 duruma gelmesi kritik önem taşır. Bu nedenle, tüm bağımlı hizmetleri tanımlamanız ve bunların sağladığı garantileri ve yetenekleri 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.

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, tek bir 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 sunucu.

  • İkincil

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

  • Yük devretme grubuna tek veritabanları ekleme

    Aynı sunucuya birkaç tek veritabanını aynı yük devretme grubuna yerleştirebilirsiniz. Yük devretme grubuna tek bir veritabanı eklerseniz, ikincil sunucuda aynı sürümü ve işlem boyutunu kullanarak otomatik olarak ikincil bir veritabanı oluşturur. Yük devretme grubu oluşturulduğunda bu sunucuyu belirttiniz. İ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 sunucuda zaten ikincil veritabanı olan bir veritabanı eklediğinizde, ikincil sunucuda yeni bir ikincil oluşturulur.

    Önemli

    İkincil sunucunun, var olan bir ikincil veritabanı olmadığı sürece aynı ada sahip bir veritabanına sahip olmadığından emin olun.

  • 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 olarak aynı ada sahip bir elastik havuz ve yük devretme grubu tarafından oluşturulacak ikincil veritabanlarını barındırmak için yeterli boş kapasite 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 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 yük devretme sonrasında birincil değişiklik yapıldığında okuma-yazma iş yükünün birincile saydam bir şekilde yeniden bağlanmasına izin verir. Yük devretme grubu bir sunucuda oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.database.windows.netoluşturulur.

  • Yük devretme grubu salt okunur dinleyicisi

    Geçerli ikincil öğeye işaret eden bir DNS CNAME kaydı. Yük devretme grubu oluşturulduğunda otomatik olarak oluşturulur ve yük devretme sonrasında ikincil değişiklik olduğunda salt okunur SQL iş yükünün ikincil iş yüküne saydam bir şekilde bağlanmasına izin verir. Yük devretme grubu bir sunucuda oluşturulduğunda, dinleyici URL'si için DNS CNAME kaydı olarak <fog-name>.secondary.database.windows.netoluşturulur.

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

  • Otomatik yük devretme ilkesi

    Varsayılan olarak, bir yük devretme grubu otomatik yük devretme ilkesiyle yapılandırılır. Sistem, hata algılandıktan ve yetkisiz kullanım süresi dolduktan sonra coğrafi yük devretmeyi tetikler. Sistemin, örneğin etkinin ölçeğinden dolayı yerleşik yüksek kullanılabilirlik altyapısı tarafından kesintinin giderilemeyeceğini doğrulaması gerekir. Coğrafi yük devretme iş akışını uygulamadan veya el ile denetlemek istiyorsanız, otomatik yük devretme ilkesini kapatabilirsiniz.

    Not

    Kesintinin ölçeğinin doğrulanması ve ne kadar çabuk giderilebileceği insan eylemleri içerdiğinden, yetkisiz kullanım süresi bir saatin altına ayarlanamaz ve yük devretmenin tam süresi ayarlanan yetkisiz kullanım süresinden biraz farklı olabilir. Bu sınırlama, veri eşitleme durumlarından bağımsız olarak yük devretme grubundaki tüm veritabanları için geçerlidir.

  • Salt okunur yük devretme ilkesi

    Varsayılan olarak, salt okunur dinleyicinin yük devretmesi devre dışı bırakılır. İkincil çevrimdışı olduğunda birincilin performansının etkilenmemesini sağlar. Ancak, ikincil kurtarılana kadar salt okunur oturumların bağlanamayacağı anlamına da gelir. Salt okunur oturumlarda 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

    AllowReadOnlyFailoverToPrimary Özelliğin etkili olması için otomatik yük devretme ilkesinin etkinleştirilmesi ve otomatik coğrafi 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.

  • Planlı yük devretme

    Planlı 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. Planlı 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
    • Veritabanlarını farklı bir bölgeye taşıma
    • Kesinti azaltıldıktan sonra veritabanlarını birincil bölgeye döndür (yeniden çalışma)

    Not

    Bir veritabanı bellek içi OLTP nesneleri içeriyorsa, bellek içi OLTP nesneleri her zaman bellekte hidratlandığından birincil veritabanlarının ve hedef ikincil coğrafi çoğaltma veritabanlarının eşleşen hizmet katmanları olmalıdır. Hedef coğrafi çoğaltma veritabanında daha düşük bir hizmet katmanı bellek yetersiz sorunlarına neden olabilir. Bu durumda, etkilenen coğrafi ikincil veritabanı çoğaltması bellek içi OLTP denetim noktası-yalnızca modu olarak adlandırılan sınırlı bir salt okunur moda konulabilir. Salt okunur tablo sorgularına izin verilir, ancak etkilenen coğrafi ikincil veritabanı çoğaltmasında salt okunur bellek içi OLTP tablo sorgularına izin verilmez. Coğrafi ikincil veritabanındaki tüm çoğaltmalar yalnızca denetim noktası modundaysa planlı yük devretme engellenir. Planlanmamış yük devretme yetersiz bellek sorunları nedeniyle başarısız olabilir. Bunu önlemek için, planlı yük devretme sırasında ikincil veritabanının hizmet katmanını birincil veritabanıyla eşleşecek şekilde yükseltin veya detaya geçin. Hizmet katmanı yükseltmeleri veri boyutu işlemleri olabilir ve tamamlanması biraz zaman alabilir.

  • Planlanmamış yük devretme

    Planlanmamış veya zorlamalı yük devretme, son değişikliklerin birincil rolden yayılmasını beklemeden ikincil rolü birincil role hemen değiştirir. Bu işlem veri kaybına neden olabilir. Planlanmamış yük devretme, birincilin erişilebilir olmadığı 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 planlı bir yük devretme yürütülebilir ve çoğaltmalar özgün birincil ve ikincil rollerine döndürülür.

  • El ile yük devretme

    Coğrafi yük devretmeyi otomatik yük devretme yapılandırmasından bağımsız olarak istediğiniz zaman el ile başlatabilirsiniz. Birincili etkileyen bir kesinti sırasında, otomatik yük devretme ilkesi yapılandırılmamışsa, ikincil rolü birincil role yükseltmek için el ile yük devretme gerekir. Zorlamalı (planlanmamış) veya kolay (planlı) yük devretme başlatabilirsiniz. Kolay yük devretme yalnızca eski birincil birincile erişilebilir olduğunda mümkündür ve birincili veri kaybı olmadan ikincil bölgeye yeniden aktarmak için kullanılabilir. Yük devretme tamamlandığında, DNS kayıtları yeni birincil sunucuya bağlantı sağlamak için otomatik olarak güncelleştirilir.

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

    Veriler zaman uyumsuz çoğaltma kullanılarak ikincil veritabanına çoğaltıldığı için otomatik coğrafi yük devretme veri kaybına neden olabilir. Otomatik yük devretme ilkesini, uygulamanızın veri kaybına dayanıklılığını yansıtacak şekilde özelleştirebilirsiniz. yapılandırarak GracePeriodWithDataLossHours, sistemin zorlamalı yük devretme başlatmadan önce ne kadar bekleyeceğini denetleyebilir ve bu da veri kaybına neden olabilir.

Yük devretme grubu mimarisi

Azure SQL Veritabanı'ndaki bir yük devretme grubu, genellikle aynı uygulama tarafından kullanılan bir veya birden çok veritabanı içerebilir. Otomatik yük devretme ilkesine sahip otomatik yük devretme gruplarını kullanırken, gruptaki veritabanlarından birini veya birkaçını etkileyen bir kesinti otomatik coğrafi yük devretmeye neden olur.

Otomatik yük devretme grubu birincil sunucuda yapılandırılmalıdır ve bunu farklı bir Azure bölgesindeki ikincil sunucuya bağlar. Gruplar, bu sunuculardaki veritabanlarının tümünü veya bazılarını içerebilir. Aşağıdaki diyagramda birden fazla veritabanı ve otomatik yük devretme grubu kullanan coğrafi olarak yedekli bir bulut uygulamasının tipik yapılandırması gösterilir.

Diyagram, birden çok veritabanı ve otomatik yük devretme grubu kullanan coğrafi olarak yedekli bir bulut uygulamasının tipik bir yapılandırmasını gösterir.

İş sürekliliği göz önünde bulundurularak bir hizmet tasarlarken, bu makalede özetlenen genel yönergeleri ve en iyi yöntemleri izleyin. Yük devretme grubunu yapılandırırken, coğrafi yük devretme sonrasında coğrafi ikincil yeni birincil olduğunda ikincilde kimlik doğrulamasının 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ı. Olağanüstü durum kurtarma çözümleri tasarlama hakkında daha fazla bilgi için bkz. Etkin coğrafi çoğaltma kullanarak Olağanüstü Durum Kurtarma için Bulut Çözümleri Tasarlama.

Yük devretme gruplarıyla belirli bir noktaya geri yükleme kullanma hakkında bilgi için bkz. Belirli Bir Noktaya Kurtarma (PITR).

İlk tohumlama

Bir 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 ile ikincil arasındaki bağlantı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 daha fazla yük devretme grubu oluşturulabilir. Birincil bölgedeki bir kesinti nedeniyle birincil veritabanlarının tümünün veya bazılarının kullanılamaz duruma gelmesi durumunda, her grup birim olarak kurtarılan bir veya birkaç veritabanı içerebilir. Yük devretme grubu oluşturmak, birincil ile aynı hizmet amacına sahip coğrafi ikincil veritabanları oluşturur. 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ğlantılar otomatik olarak birincil sunucuya yönlendirilir. Yük devretme sonrasında bu ad değişmez. Yük devretmenin DNS kaydının güncelleştirilmesini içerdiğini, böylece istemci bağlantılarının yeni birincil sunucuya yeniden yönlendirilmesini ancak istemci DNS önbelleği yenilendikten sonra içerdiğini 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ğlantılar otomatik olarak coğrafi ikincil sunucuya yönlendirilir. Bağlantı dizesinde okuma amacını kullanarak ApplicationIntent=ReadOnlybelirtmeniz de önerilir.

Premium, İş Açısından Kritik ve Hiper Ölçek hizmet katmanlarında SQL Veritabanı, bağlantı dizesindeki 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 olarak çoğaltılan konumdaki salt okunur bir çoğaltmaya bağlanmak için bu özelliği kullanabilirsiniz:

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

Yük devretme sonrasında olası performans düşüşü

Tipik bir Azure uygulaması birden çok Azure hizmeti kullanır ve birden çok bileşenden oluşur. Yük devretme grubunun otomatik coğrafi yük devretmesi, yalnızca Azure SQL bileşenlerinin durumuna göre tetikler. Birincil bölgedeki diğer Azure hizmetleri kesintiden etkilenmeyebilir ve bileşenleri bu bölgede kullanılabilir olmaya devam edebilir. 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.

Yük devretme sonrasında olası veri kaybı

Birincil bölgede kesinti olursa son işlemler coğrafi olarak ikincil bölgeye çoğaltılamayabilir. Otomatik yük devretme ilkesi yapılandırıldıysa, sistem otomatik coğrafi yük devretme başlatmadan önce belirttiğiniz GracePeriodWithDataLossHours süreyi bekler. Varsayılan değer 1 saattir. Bu, veri kaybını önlemek yerine veritabanı kullanılabilirliğini destekler. 24 saat gibi daha büyük bir sayıya ayarlamak GracePeriodWithDataLossHours veya otomatik coğrafi yük devretmeyi devre dışı bırakmak, veritabanı kullanılabilirliği pahasına veri kaybı olasılığını azaltmanızı sağlar.

Önemli

800 veya daha az DTU'su ya da 8 veya daha az sanal çekirdeği ve 250'den fazla veritabanı olan elastik havuzlar, uzun süre planlanmış coğrafi yük devretme işlemleri ve düşük performans gibi sorunlarla karşılaşabilir. Bu sorunlar yazma yoğunluklu iş yüklerinde, coğrafi çoğaltmalar coğrafi olarak geniş ölçüde ayrıldığında veya her veritabanı için birden çok ikincil coğrafi çoğaltma kullanıldığında ortaya çıkabilir. 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 oluşursa, azaltma, daha fazla DTU veya sanal çekirdek elde etmek için havuzun ölçeğini artırmayı veya havuzdaki coğrafi olarak çoğaltılan veritabanı sayısını azaltmayı içerir.

Yük devretme grupları ve ağ güvenliği

Bazı uygulamalar için güvenlik kuralları, veri katmanına ağ erişiminin vm, web hizmeti vb. belirli bir bileşen veya bileşenle sınırlı olmasını gerektirir. Bu gereksinim, iş sürekliliği tasarımı ve yük devretme gruplarının kullanımı için bazı güçlükler sunar. Bu tür kısıtlı erişimi uygularken aşağıdaki seçenekleri göz önünde bulundurun.

Yük devretme gruplarını ve sanal ağ hizmet uç noktalarını kullanma

SQL Veritabanı'da veritabanınıza erişimi kısıtlamak için Sanal Ağ hizmet uç noktalarını ve kurallarını kullanıyorsanız, her sanal ağ hizmet uç noktasının yalnızca bir Azure bölgesi için geçerli olduğunu unutmayın. Uç nokta, diğer bölgelerin alt ağdan gelen iletişimi kabul etmelerini sağlamaz. Bu nedenle, birincil veritabanına yalnızca aynı bölgede dağıtılan istemci uygulamaları bağlanabilir. Coğrafi yük devretme, SQL Veritabanı istemci oturumlarının farklı bir (ikincil) bölgedeki bir sunucuya yeniden yönlendirilmeleriyle sonuçlandığı için, bu oturumlar bu bölgenin dışındaki bir istemciden kaynaklanırsa başarısız olur. Bu nedenle, katılan sunucular veya örnekler Sanal Ağ kurallarına dahil edilirse otomatik yük devretme ilkesi etkinleştirilemez. El ile yük devretmeyi desteklemek için şu adımları izleyin:

  1. İkincil bölgede uygulamanızın ön uç bileşenlerinin (web hizmeti, sanal makineler vb.) yedekli kopyalarını sağlayın.
  2. Birincil ve ikincil sunucu için sanal ağ kurallarını tek tek yapılandırın.
  3. Traffic manager yapılandırmasını kullanarak ön uç yük devretmesini etkinleştirin.
  4. Kesinti algılandığında el ile coğrafi yük devretme başlatın. Bu seçenek ön uç ile veri katmanı arasında tutarlı gecikme süresi gerektiren uygulamalar için iyileştirilmiştir ve ön uç, veri katmanı veya her ikisi de kesintiden etkilendiğinde kurtarmayı destekler.

Not

Salt okunur bir iş yükünün yükünü dengelemek için salt okunur dinleyiciyi kullanıyorsanız, bu iş yükünün ikincil veritabanına bağlanabilmesi için ikincil bölgedeki bir VM'de veya başka bir kaynakta yürütildiğinden emin olun.

Yük devretme gruplarını ve güvenlik duvarı kurallarını kullanma

İş sürekliliği planınız otomatik yük devretmeye sahip grupları kullanarak yük devretme gerektiriyorsa, genel IP güvenlik duvarı kurallarını kullanarak SQL Veritabanı veritabanınıza erişimi kısıtlayabilirsiniz. Otomatik yük devretmeyi desteklemek için şu adımları izleyin:

  1. Genel IP oluşturun.
  2. Bir genel yük dengeleyici oluşturun ve genel IP'yi ona atayın.
  3. Ön uç bileşenleriniz için bir sanal ağ ve sanal makineler oluşturun.
  4. Ağ güvenlik grubu oluşturun ve gelen bağlantıları yapılandırın.
  5. Hizmet etiketi kullanarak Sql.<Region> bir bölgedeki Azure SQL Veritabanına giden bağlantıların açık olduğundan emin olun.
  6. 1. adımda oluşturduğunuz genel IP adresinden gelen trafiğe izin vermek için bir SQL Veritabanı güvenlik duvarı kuralı oluşturun.

Giden erişimi yapılandırma ve güvenlik duvarı kurallarında kullanılacak IP hakkında daha fazla bilgi için bkz . Yük dengeleyici giden bağlantıları.

Yukarıdaki yapılandırma, otomatik coğrafi yük devretmenin ön uç bileşenlerinden gelen bağlantıları engellememesini sağlar ve uygulamanın ön uç ile veri katmanı arasındaki daha uzun gecikme süresini tolere edebildiğini varsayar.

Önemli

Bölgesel kesintiler sırasında iş sürekliliğini garanti etmek için hem ön uç bileşenleri hem de veritabanları için coğrafi yedeklilik sağlamanız gerekir.

Birincil veritabanını ölçeklendirme

Coğrafi ikincil öğelerin bağlantısını kesmeden birincil veritabanının ölçeğini artırıp azaltarak farklı bir işlem boyutuna (aynı hizmet katmanı içinde) gidebilirsiniz. Ölçeği büyütürken, önce coğrafi ikincil ölçeği artırmanızı ve ardından birincil ölçeği artırmanızı öneririz. Ölçeği azaltırken işlemi tersine çevirin: Önce birincil örneğin ölçeğini azaltıp ardından ikincil örneğin ölçeğini azaltın. Veritabanını farklı bir hizmet katmanına ölçeklendirdiğinizde bu öneri uygulanır.

Bu dizi özellikle daha düşük bir SKU'daki coğrafi ikincilin aşırı yüklendiği ve yükseltme veya eski sürüme düşürme işlemi sırasında yeniden dağıtılması gerektiği sorundan kaçınmak için önerilir. Ayrıca birincil örneği salt okunur yaparak da bu sorunu önleyebilirsiniz ama bu durumda birincil örnekteki tüm okuma-yazma iş yükleri bundan etkilenecektir.

Not

Yük devretme grubu yapılandırmasının bir parçası olarak coğrafi ikincil oluşturduysanız coğrafi ikincil ölçeği azaltmanız önerilmez. Bunun nedeni coğrafi yük devretme sonrasında veri katmanınızın normal iş yükünüzü işlemek için yeterli kapasiteye sahip olduğundan emin olmaktı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ını ç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ına göre belirlenmiştir. Birincil veritabanına bağlantı hakları olan tüm kullanıcılar bu yordamı çağırabilir.

Not

sp_wait_for_database_copy_sync belirli işlemler için coğrafi yük devretmeden sonra 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.

Yeniden çalışma

Otomatik Yük Devretme grupları otomatik yük devretme ilkesiyle yapılandırıldığında, coğrafi ikincil sunucuya 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 birincile yeniden çalışma işleminin el ile başlatılması gerekir.

İzinler

Yük devretme grubu izinleri Azure rol tabanlı erişim denetimi (Azure RBAC) aracılığıyla yönetilir.

Yük devretme grupları oluşturmak ve yönetmek için Azure RBAC yazma erişimi gereklidir. SQL Server Katkıda Bulunan rolü, yük devretme gruplarını yönetmek için gerekli tüm izinlere sahiptir.

Belirli izin kapsamları için Azure SQL Veritabanında otomatik yük devretme gruplarını yapılandırmayı gözden geçirin.

Sınırlamalar

Aşağıdaki sınırlamalara dikkat edin:

  • Aynı Azure bölgesindeki iki sunucu arasında yük devretme grupları oluşturulamaz.
  • Yük devretme grupları yeniden adlandırılamaz. Grubu silmeniz ve farklı bir adla yeniden oluşturmanız gerekir.
  • Yük devretme grubundaki veritabanları için veritabanını yeniden adlandırma desteklenmez. Veritabanını yeniden adlandırmak için yük devretme grubunu geçici olarak silmeniz veya veritabanını yük devretme grubundan kaldırmanız gerekir.

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

Daha önce açıklandığı gibi, otomatik yük devretme grupları Azure PowerShell, Azure CLI ve REST API kullanılarak program aracılığıyla da yönetilebilir. Aşağıdaki tablolarda kullanılabilir komut kümesi açıklanmaktadır. Etkin coğrafi çoğaltma, Azure SQL Veritabanı REST API'si ve Azure PowerShellcmdlet'leri dahil olmak üzere yönetim için bir dizi Azure Resource Manager API'si içerir. Bu API'ler kaynak gruplarının kullanılmasını gerektirir ve Azure rol tabanlı erişim denetimini (Azure RBAC) destekler. Erişim rollerini uygulama hakkında daha fazla bilgi için bkz. Azure rol tabanlı erişim denetimi (Azure RBAC).

Cmdlet Açıklama
New-AzSqlDatabaseFailoverGroup Bu komut bir yük devretme grubu oluşturur ve bunu hem birincil hem de ikincil sunuculara kaydeder
Remove-AzSqlDatabaseFailoverGroup Sunucudan yük devretme grubunu kaldırır
Get-AzSqlDatabaseFailoverGroup Yük devretme grubunun yapılandırmasını alır
Set-AzSqlDatabaseFailoverGroup Yük devretme grubunun yapılandırmasını değiştirir
Switch-AzSqlDatabaseFailoverGroup Bir yük devretme grubunun ikincil sunucuya yük devretmesini tetikler
Add-AzSqlDatabaseToFailoverGroup Yük devretme grubuna bir veya daha fazla veritabanı ekler

Sonraki adımlar