Birden çok veritabanının saydam ve eşgüdümlü coğrafi yük devretmesini etkinleştirmek için otomatik yük devretme gruplarını kullanın
Uygulama hedefi:
Azure SQL Veritabanı
Azure SQL yönetilen örneği
Otomatik yük devretme grupları özelliği, bir sunucudaki bir veritabanı grubunun veya yönetilen bir örnekteki tüm veritabanlarının çoğaltmasını ve başka bir bölgeye yük devretmesini yönetmenizi sağlar. Bu, var olan etkin coğrafi çoğaltma özelliğinin en üstünde, coğrafi olarak çoğaltılan veritabanlarının dağıtım ve yönetimini kolaylaştırmak için tasarlanan, bildirime dayalı bir soyutlamadır. Coğrafi Yük devretmeyi el ile başlatabilir veya Kullanıcı tanımlı bir ilkeye göre Azure hizmetine temsilci atayabilirsiniz. ikinci seçenek, bir ikincil bölgedeki birden çok ilişkili veritabanını, SQL Veritabanı veya kısmi kayıpla veya birincil bölgede SQL yönetilen örnek kullanılabilirliği ile sonuçlanan diğer plansız bir olaydan sonra otomatik olarak kurtarmanıza olanak sağlar. Yük devretme grubu, genellikle aynı uygulama tarafından kullanılan bir veya daha fazla veritabanı içerebilir. Ayrıca, salt okunur sorgu iş yüklerini boşaltmak için okunabilir ikincil veritabanlarını da kullanabilirsiniz.
Not
Otomatik yük devretme grupları gruptaki tüm veritabanlarının coğrafi olarak çoğaltılmasını yalnızca bir ikincil sunucuya veya farklı bir bölgedeki örneğe destekler. aynı birincil çoğaltma için birden çok Azure SQL Veritabanı coğrafi ikincil çoğaltma (aynı veya farklı bölgelerde) oluşturmanız gerekiyorsa, etkin coğrafi çoğaltmakullanın.
Otomatik yük devretme grupları Şu anda hiper ölçek hizmeti katmanında desteklenmiyor. Hiper ölçekli bir veritabanının coğrafi yük devretmesi için etkin coğrafi çoğaltma' yı kullanın.
Otomatik yük devretme grupları otomatik yük devretme ilkesiyle kullanılırken, gruptaki veritabanlarının birini veya birkaçını etkileyen bir kesinti otomatik coğrafi Yük devretmeyle sonuçlanır. Genellikle, bunlar yerleşik yüksek kullanılabilirlik altyapısı tarafından otomatik olarak hafiflenemez. coğrafi yük devretme tetikleyicilerinin örnekleri, işlem düğümlerinde bir işletim sistemi çekirdek belleği sızıntısı nedeniyle bir SQL Veritabanı kiracı halkasının veya denetim halkasının neden olduğu bir olay içerir ya da bir veya daha fazla kiracı halkasından kaynaklanan bir olay, olağan dışı donanım alma sırasında yanlışlıkla kesildiğinden bir veya daha fazla kiracı halkasından kaynaklanır. daha fazla bilgi için bkz. yüksek kullanılabilirlik SQL Veritabanı.
Ayrıca, otomatik yük devretme grupları, coğrafi Yük devretme sırasında değişmeden kalan okuma-yazma ve salt okuma dinleyicisi uç noktaları sağlar. El ile veya otomatik yük devretme etkinleştirme kullanmanıza bakılmaksızın, coğrafi Yük devretme gruptaki tüm ikincil veritabanlarını birincil role geçirir. Coğrafi Yük devretme tamamlandıktan sonra DNS kaydı, uç noktaları yeni bölgeye yönlendirmek üzere otomatik olarak güncelleştirilir. Coğrafi Yük devretme RPO 'SU ve RTO için bkz. Iş sürekliliği 'Ne genel bakış.
Otomatik yük devretme grupları otomatik yük devretme ilkesiyle kullanılırken, bir sunucu veya yönetilen örnekteki veritabanlarını etkileyen bir kesinti otomatik coğrafi Yük devretme ile sonuçlanır.
Şunu kullanarak otomatik yük devretme grubunu yönetebilirsiniz:
- Azure portalındaki
- Azure CLı: yük devretme grubu
- PowerShell: yük devretme grubu
- REST API: yük devretme grubu
Bir yük devretme grubu yapılandırırken, coğrafi Yük devretme sonrasında ikincil üzerinde kimlik doğrulaması ve ağ erişiminin doğru şekilde ayarlandığından emin olun. Bu, coğrafi-ikincil yeni birincil haline gelir. ayrıntılar için bkz. olağanüstü durum kurtarma sonrasında SQL Veritabanı güvenliği.
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. Bir uygulamayı (hizmet) çok zararlı bir hatadan sonra 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 alanı ve DNS sayılabilir. Tüm bileşenlerin aynı hatalara dayanıklı olması ve uygulamanızın kurtarma süresi hedefi (RTO) içinde kullanılabilir olması önemlidir. Bu nedenle, tüm bağımlı hizmetleri belirlemeniz ve sağladıkları garantileri ve özellikleri anlamanız gerekir. Daha sonra, hizmetin bağımlı olduğu hizmetlerin yük devretmesi sırasında işlevlerinizin çalıştığından emin olmak için yeterli adımları uygulamanız gerekir. 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 grubu terimleri ve özellikleri
Yük devretme grubu (FOG)
Yük devretme grubu, tek bir sunucu tarafından yönetilen adlandırılmış veritabanları grubudur veya bir yönetilen örnek içinde, birincil bölgedeki bir kesinti nedeniyle tüm veya bazı birincil veritabanlarının kullanılamaz hale gelmesi durumunda başka bir bölgeye bir birim olarak yük devredebilirler. SQL yönetilen örnek için oluşturulduğunda, bir yük devretme grubu örnekteki tüm kullanıcı veritabanlarını içerir ve bu nedenle bir örnek üzerinde yalnızca bir yük devretme grubu yapılandırılabilir.
Önemli
Yük devretme grubunun adı etki alanı içinde genel olarak benzersiz olmalıdır
.database.windows.net.Sunucular
Bir 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 grubundaki birincil veritabanlarını barındıran sunucu veya yönetilen örnek.
İkincil
Yük devretme grubundaki ikincil veritabanlarını barındıran sunucu veya yönetilen örnek. İkincil, birincil ile aynı bölgede olamaz.
Yük devretme grubuna tek veritabanları ekleme
Aynı sunucuya aynı yük devretme grubuna birkaç tek veritabanı 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 bir veritabanına sahip olan bir veritabanını 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ına sahip bir veritabanı eklediğinizde, ikincil sunucuda yeni bir ikincil oluşturulur.
Önemli
İkincil sunucuda, var olan bir ikincil veritabanı olmadığı müddetçe aynı ada sahip bir veritabanı bulunmadığından emin olun. SQL yönetilen örnek için yük devretme gruplarında, tüm kullanıcı veritabanları çoğaltılır. Yük devretme grubundaki çoğaltma için kullanıcı veritabanlarının bir alt kümesini seçemezsiniz.
Elastik havuzdaki veritabanlarını yük devretme grubuna ekleme
Elastik havuz içindeki tüm veya birkaç veritabanını aynı yük devretme grubuna yerleştirebilirsiniz. Birincil veritabanı elastik bir havuzda ise, ikincil havuz aynı ada (ikincil havuz) sahip esnek havuzda otomatik olarak oluşturulur. İkincil sunucunun, yük devretme grubu tarafından oluşturulacak ikincil veritabanlarını barındırmak için aynı tam adı ve yeterli boş kapasiteye sahip esnek bir havuz içerdiğinden emin olmanız gerekir. Havuza ikincil havuzda zaten ikincil bir 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ına sahip bir veritabanı eklediğinizde ikincil havuzda yeni bir ikincil oluşturulur.
İlk dengeli dağıtım
Veritabanları, elastik havuzlar veya yönetilen örnekleri bir yük devretme grubuna eklerken, veri çoğaltma başlamadan önce bir ilk dengeli dağıtım aşaması vardır. İlk dengeli dağıtım aşaması en uzun ve en pahalı işlemdir. İlk dengeli dağıtım 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 için gereken süre, verilerinizin boyutuna, çoğaltılan veritabanlarının sayısına, birincil veritabanlarına yükün ve birincil ve ikincil arasındaki bağlantının hızına bağlıdır. normal koşullarda, olası dengeli dağıtım hızı SQL Veritabanı için 500 gb ve SQL yönetilen örnek için 360 gb 'a kadar bir saat kadar sürebilir. Dengeli dağıtım, tüm veritabanları için paralel olarak gerçekleştirilir.
SQL yönetilen örnek için, ilk dengeli dağıtım aşamasının süresini tahmin eden iki örnek arasındaki hızlı rota bağlantısının hızını göz önünde bulundurun. İki örnek arasındaki bağlantının hızı gerekenden daha yavaşsa, çekirdek için zaman önemli ölçüde etkilendi. Veri çoğaltma başlamadan önce ilk dengeli dağıtım aşamasının ne kadar süreyle yapılacağını tahmin etmek için belirtilen dengeli dağıtım 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ının saat başına 84 GB 'a itilebilir olması ve daha önce oluşturulan başka veritabanları olmaması durumunda ilk Çekirdek aşaması yaklaşık 1,2 saat sürer. Bağlantı yalnızca saat başına 10 GB aktarabiliyorsanız, 100 GB 'lik bir veritabanının dağıtımı, yaklaşık 10 saat sürer. Çoğaltılacak birden çok veritabanı varsa, dağıtım paralel olarak yürütülür ve yavaş bir bağlantı hızıyla birleştirildiğinde, özellikle tüm veritabanlarındaki verilerin paralel dengeli dağıtımı kullanılabilir bağlantı bant genişliğini aşarsa, ilk dengeli dağıtım aşaması oldukça uzun sürebilir. İki örnek arasındaki ağ bant genişliği sınırlıysa ve bir yük devretme grubuna birden çok yönetilen örnek ekliyorsanız, yük devretme grubuna birden çok yönetilen örnek eklemeyi göz önünde bulundurun. İki yönetilen örnek arasında uygun boyutta bir ağ geçidi SKU 'SU veriliyorsa ve kurumsal ağ bant genişliği buna izin veriyorsa, hızlara 360 GB kadar yüksek bir saat elde etmek mümkündür.
DNS bölgesi
yeni bir SQL yönetilen örnek oluşturulduğunda otomatik olarak oluşturulan benzersiz bir kimlik. Aynı DNS bölgesindeki herhangi bir örneğe istemci bağlantılarının kimliğini doğrulamak için bu örnek için bir çoklu etki alanı (SAN) sertifikası sağlanır. Aynı yük devretme grubundaki iki yönetilen örnek, DNS bölgesini paylaşmalıdır.
Not
SQL Veritabanı için oluşturulan yük devretme gruplarında bir DNS bölge kimliği gerekli değildir veya kullanılır.
Yük devretme grubu okuma-yazma dinleyicisi
Geçerli birincili 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şiklikler olan okuma/yazma iş yükünün birincil olarak birinciye yeniden bağlanmasına izin verir. Yük devretme grubu bir sunucuda oluşturulduğunda, dinleyici URL 'SI için DNS CNAME kaydı olarak biçimlendirilir
<fog-name>.database.windows.net. yük devretme grubu SQL yönetilen bir örnekte oluşturulduğunda, dinleyici URL 'si için DNS CNAME kaydı olarak biçimlendirilir<fog-name>.<zone_id>.database.windows.net.Yük devretme grubu salt okuma dinleyicisi
Geçerli ikincili 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şiklikler olduğunda salt okunurdur SQL iş yükünün ikincil sunucuya şeffaf 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 biçimlendirilir
<fog-name>.secondary.database.windows.net. yük devretme grubu SQL yönetilen bir örnekte oluşturulduğunda, dinleyici URL 'si için DNS CNAME kaydı olarak biçimlendirilir<fog-name>.secondary.<zone_id>.database.windows.net.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 devretme işlemini tetikler. Sistemin, etkinin ölçeklendirilmesi nedeniyle, sistem kesintisinin yerleşik yüksek kullanılabilirlik altyapısıtarafından azaltılkullanılamadığını doğrulaması gerekir. Coğrafi Yük devretme iş akışını uygulamadan veya el ile denetlemek istiyorsanız otomatik yük devretme ilkesini devre dışı bırakabilirsiniz.
Not
Kesinti ölçeğinin doğrulanması ve ne kadar hızlı bir şekilde azalmayabileceğini öğrenmek için, yetkisiz kullanım süresi bir saat altında ayarlanamaz. Bu sınırlama, veri eşitleme durumu ne olursa olsun, yük devretme grubundaki tüm veritabanları için geçerlidir.
Salt okuma yük devretme ilkesi
Varsayılan olarak, salt okunurdur dinleyicinin yük devretmesi devre dışıdır. İkincil çevrimdışıyken, birincil performans performansının etkilenmemesini sağlar. Bununla birlikte, ikincil kurtarılana kadar salt okuma oturumlarının bağlanamadığı anlamına gelir. Salt okuma oturumları için kapalı kalma süresini kabul edebiliyorsanız ve birincil ' ı salt okunurdur ve okuma/yazma trafiği için birincil olarak kullanabilir, özelliği yapılandırarak salt okuma dinleyicisi için yük devretmeyi etkinleştirebilirsiniz
AllowReadOnlyFailoverToPrimary. Bu durumda, ikincil kullanılabilir değilse salt okuma trafiği otomatik olarak birincil olarak yönlendirilir.Not
AllowReadOnlyFailoverToPrimaryÖzelliği yalnızca otomatik yük devretme ilkesi etkinse ve otomatik coğrafi Yük devretme tetikleniyorsa etkilidir. Bu durumda, özelliği true olarak ayarlanırsa, yeni birincil her ikisi de okuma-yazma ve salt okuma oturumlarına sahip olur.Planlı yük devretme
Planlı Yük devretme, birincil ve ikincil veritabanları arasında birincil role kadar olan tüm verileri tam olarak eşitlemeye çalışır. Bu, veri kaybı garantisi vermez. Planlı Yük devretme aşağıdaki senaryolarda kullanılır:
- Veri kaybı kabul edilebilir olmadığında üretimde olağanüstü durum kurtarma (DR) tatbilar gerçekleştirme
- Veritabanlarını farklı bir bölgeye yeniden konumlandırma
- Kesinti azaltıldıktan sonra veritabanlarını birincil bölgeye döndürün (yeniden çalışma)
Planlanmamış yük devretme
Planlanmamış veya zorlamalı yük devretme, son değişikliklerin Birincilden yayılmasını beklemeden ikincil öğeyi hemen birincil role geçirir. Bu işlem, veri kaybına neden olabilir. Planlanmamış yük devretme, birincil erişim olmadığında kesintiler sırasında kurtarma yöntemi olarak kullanılır. Kesinti azaltıldığında, eski birincil otomatik olarak yeniden bağlanır ve yeni bir ikincil hale gelir. Planlanmış bir yük devretme, çoğaltmaları orijinal birincil ve ikincil rollerine döndüren geri yük devretmek için çalıştırılabilir.
El ile yük devretme
Otomatik yük devretme yapılandırması ne olursa olsun, coğrafi Yük devretmeyi dilediğiniz zaman el ile başlatabilirsiniz. Otomatik yük devretme ilkesi yapılandırılmamışsa, birincili etkileyen bir kesinti sırasında, ikincili 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 erişime açık olduğunda ve birincil bölge 'yi veri kaybı olmadan ikincil bölgeye yeniden konumlandırmak için kullanılabilir. Yük devretme tamamlandığında, DNS kayıtları, yeni birincili bağlantıyı sağlamak üzere otomatik olarak güncelleştirilir.
Veri kaybı olan yetkisiz kullanım süresi
İkincil veritabanları zaman uyumsuz çoğaltma kullanılarak eşitlendiğinden, otomatik coğrafi Yük devretme, veri kaybına neden olabilir. Otomatik yük devretme ilkesini, uygulamanızın veri kaybına karşı dayanıklılığını yansıtacak şekilde özelleştirebilirsiniz. Yapılandırarak
GracePeriodWithDataLossHours, sistemin zorlamalı bir yük devretmeyi başlatmadan önce bekleyeceği süreyi denetleyebilir ve bu durum veri kaybına neden olabilir.Çoklu yük devretme grupları
Coğrafi Yük devretmeler 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 devredildi. Veritabanı başına kiracı uygulamanız birden çok bölgede dağıtılırsa ve elastik havuzlar kullanıyorsa, bu özelliği kullanarak her havuzda birincil ve ikincil veritabanlarını karıştırabilirsiniz. Bu şekilde, bir kesinti etkisini yalnızca bazı kiracı veritabanlarına kadar azaltabilirsiniz.
Not
SQL Yönetilen örnek çoklu yük devretme gruplarını desteklemiyor.
İzinler
Yük devretme grubu izinleri Azure rol tabanlı erişim denetimi (Azure RBAC)aracılığıyla yönetilir. SQL Server katkıda bulunan rolü, yük devretme gruplarını yönetmek için gereken tüm izinlere sahiptir.
Yük devretme grubu oluşturma
Bir yük devretme grubu oluşturmak için, hem birincil hem de ikincil sunuculara ve yük devretme grubundaki tüm veritabanlarına Azure RBAC yazma erişimine sahip olmanız gerekir. SQL yönetilen bir örnek için hem birincil hem de ikincil SQL yönetilen örnek için Azure RBAC yazma erişimine sahip olmanız gerekir, ancak tek tek veritabanları üzerindeki izinler bir yük devretme grubuna eklenemediği veya bu gruba kaldırılamadığı için SQL ilgili değildir.
Yük devretme grubunu güncelleştirme
Bir yük devretme grubunu güncelleştirmek için, yük devretme grubuna ve geçerli birincil sunucu veya yönetilen örnekteki tüm veritabanlarına Azure RBAC yazma erişimi gerekir.
Yük devretme grubu yükünü devreder
Yük devretme grubu yükünü devretmek için, yeni birincil sunucu veya yönetilen örnekteki yük devretme grubuna Azure RBAC yazma erişimine sahip olmanız gerekir.
SQL Veritabanı için yük devretme grubu en iyi yöntemleri
Otomatik yük devretme grubu birincil sunucuda yapılandırılmalı ve bunu farklı bir Azure bölgesindeki ikincil sunucuya bağlayacaktır. Gruplar, bu sunuculardaki tüm veya bazı veritabanlarını içerebilir. Aşağıdaki diyagramda birden çok veritabanı ve otomatik yük devretme grubu kullanılarak coğrafi olarak yedekli bir bulut uygulamasının tipik bir yapılandırması gösterilmektedir.

Not
bir yük devretme grubuna SQL Veritabanı bir veritabanı ekleme hakkında ayrıntılı adım adım öğretici için bkz. yük devretme grubuna SQL Veritabanı ekleme .
İş sürekliliği ile bir hizmet tasarlarken aşağıdaki genel yönergeleri izleyin:
Birden çok veritabanının yük devretmesini yönetmek için bir veya birkaç yük devretme grubu kullanın
Farklı bölgelerde (birincil ve ikincil sunucular) iki sunucu arasında bir veya daha fazla yük devretme grubu oluşturulabilir. Her grup, birincil bölgedeki bir kesinti nedeniyle tüm veya bazı birincil veritabanlarının kullanılamaz duruma gelmesi durumunda birim olarak kurtarılan bir veya birkaç veritabanı içerebilir. Yük devretme grubu oluşturma, birincil ile aynı hizmet hedefi ile coğrafi ikincil veritabanları oluşturur. Mevcut bir coğrafi çoğaltma ilişkisini bir yük devretme grubuna eklerseniz, coğrafi ikincil öğenin aynı hizmet katmanıyla ve işlem boyutuyla birincil olarak yapılandırıldığından emin olun.
Birincil sunucuya bağlanmak için okuma-yazma dinleyicisini kullanın
Okuma-yazma iş yükleri için, <fog-name>.database.windows.net bağlantı dizesinde sunucu adı olarak kullanın. Bağlantılar otomatik olarak birincil ağa yönlendirilir. Bu ad, yük devretmeden sonra değişmez. Bunun için yük devretme, DNS kaydının güncelleştirilmesini içerir, böylece istemci bağlantıları yalnızca istemci DNS önbelleği yenilendikten sonra yeni birincil yere yönlendirilir. Birincil ve ikincil dinleyici DNS kaydının yaşam süresi (TTL) 30 saniyedir.
Coğrafi ikincil sunucuya bağlanmak için salt okunurdur dinleyiciyi kullanın
Veri gecikmesi için dayanıklı olan salt yazılır salt yazılır iş yükleriniz varsa, bunları coğrafi ikincil üzerinde çalıştırabilirsiniz. Salt okuma oturumları için, <fog-name>.secondary.database.windows.net bağlantı dizesinde sunucu adı olarak kullanın. Bağlantılar otomatik olarak coğrafi-ikincil öğesine yönlendirilir. Ayrıca, kullanarak bağlantı dizesinde oku hedefini belirtmeniz önerilir ApplicationIntent=ReadOnly .
Not
Premium, İş Açısından Kritik ve hiper ölçek hizmeti katmanlarında SQL Veritabanı, bağlantı dizesindeki parametresini kullanarak salt okuma sorgusu iş yüklerini boşaltmak için salt okuma çoğaltmalarının kullanımını destekler ApplicationIntent=ReadOnly . Bir coğrafi-ikincil yapılandırdığınızda, birincil konumdaki veya coğrafi olarak çoğaltılan konumdaki salt okunurdur bir çoğaltmaya bağlanmak için bu özelliği kullanabilirsiniz.
- Birincil konumdaki bir salt okuma çoğaltmasına bağlanmak için
ApplicationIntent=ReadOnlyve kullanın<fog-name>.database.windows.net. - İkincil konumdaki bir salt okuma çoğaltmasına bağlanmak için
ApplicationIntent=ReadOnlyve kullanın<fog-name>.secondary.database.windows.net.
Coğrafi 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, Azure SQL bileşenleri yalnızca durum temelinde tetiklenir. Birincil bölgedeki diğer Azure hizmetleri kesinti tarafından etkilenmeyebilir ve bileşenleri bu bölgede kullanılabilir olmaya devam edebilir. Birincil veritabanları ikincil (DR) bölgesine geçiş yaptıktan sonra, bağımlı bileşenler arasındaki gecikme artabilir. Uygulamanın performansına yönelik daha yüksek gecikme süresini önlemek için, DR bölgesindeki tüm uygulama bileşenlerinin yedekliliği olduğundan emin olun, bu ağ güvenlik yönergeleriniizleyin ve ilgili uygulama bileşenlerinin coğrafi yük devretmesini veritabanıyla birlikte yönetin.
Coğrafi Yük devretme sonrasında olası veri kaybı
Birincil bölgede bir kesinti oluşursa, son işlemler coğrafi-ikincil öğesine çoğaltılmayabilir. Otomatik yük devretme ilkesi yapılandırılırsa, sistem GracePeriodWithDataLossHours Otomatik coğrafi Yük devretmeyi başlatmadan önce tarafından belirlediğiniz süreyi bekler. Varsayılan değer 1 saattir. Bu, veri kaybı olmadan veritabanı kullanılabilirliğini tercih eder. GracePeriodWithDataLossHours24 saat gibi daha büyük bir sayıya ayarlama veya otomatik coğrafi Yük devretmeyi devre dışı bırakma, veritabanı kullanılabilirliğinin masrafında veri kaybı olasılığını azaltmanızı sağlar.
Önemli
800 veya daha az sayıda Vcore ile elastik havuzlar ve 250 ' den fazla veritabanı, daha uzun planlı coğrafi Yük devretme ve performans düşüklükleri gibi sorunlarla karşılaşabilir. Bu sorunların, coğrafi çoğaltmalar coğrafya ile yaygın olarak ayrıldığı veya her veritabanı için birden çok ikincil coğrafi çoğaltma kullanıldığı zaman, yazma yoğunluklu iş yükleri için oluşma olasılığı yüksektir. Bu sorunların belirtisi, zaman içinde coğrafi çoğaltma gecikmesi, büyük olasılıkla bir kesinti sırasında daha kapsamlı bir veri kaybına yol açabilir. Bu gecikme, sys.dm_geo_replication_link_statuskullanılarak izlenebilir. Bu sorunlar oluşursa, risk azaltma, havuzun daha fazla DTU veya sanal çekirdeğe sahip olacak şekilde ölçeğini veya havuzdaki coğrafi olarak çoğaltılan veritabanlarının sayısını azaltmayı içerir.
Yük devretme grubunun ikincil bölgesini değiştirme
Değişiklik sırasını göstermek için sunucu A 'nın birincil sunucu olduğunu, sunucu B 'nin var olan ikincil sunucu olduğunu ve sunucu C 'nin üçüncü bölgedeki yeni ikincil olduğunu varsayacağız. Geçişi yapmak için şu adımları izleyin:
- Etkin coğrafi çoğaltmakullanarak her bir veritabanı Için Sunucu A, sunucu C üzerinde ek ikincil sunucular oluşturun. Sunucu A 'daki her veritabanı, biri sunucu B 'de diğeri sunucu C 'de olmak üzere iki ikincil adına sahip olur. Bu, geçiş sırasında birincil veritabanlarının korunduğundan emin olmaya devam edecektir.
- Yük devretme grubunu silin. Bu noktada, yük devretme grubu uç noktalarını kullanan oturum açma girişimleri başarısız olur.
- Yük devretme grubunu, A ve C sunucuları arasında aynı adla yeniden oluşturun.
- A sunucusundaki tüm birincil veritabanlarını yeni yük devretme grubuna ekleyin. Bu noktada oturum açma denemeleri başarısız oluyor.
- B sunucusunu silin. B'de tüm veritabanları otomatik olarak silinir.
Yük devretme grubunun birincil bölgesini değiştirme
Değişiklik sırasını göstermek için A sunucusunun birincil sunucu olduğunu, B sunucusunun mevcut ikincil sunucu olduğunu ve C sunucusunun üçüncü bölgedeki yeni birincil sunucu olduğunu varsayalım. Geçişi yapmak için şu adımları izleyin:
- Birincil sunucuyu B olarak değiştirmek için planlı bir coğrafi yük devretme gerçekleştirin. A Sunucusu yeni ikincil sunucu olur. Yük devretme birkaç dakika kapalı kalma süresine neden olabilir. Gerçek süre, yük devretme grubunun boyutuna bağlıdır.
- Etkin coğrafi çoğaltma kullanarak B sunucusundaki her veritabanının C sunucusuna ek ikincileri oluşturun. B sunucusundaki her veritabanı, biri A sunucusunda ve biri C sunucusunda olmak için iki ikinci sunucuya sahip olur. Bu, geçiş sırasında birincil veritabanlarının korunmasını garantiler.
- Yük devretme grubunu silin. Bu noktada yük devretme grubu uç noktalarını kullanan oturum açma girişimleri başarısız olur.
- B ve C sunucuları arasında aynı adla yük devretme grubunu yeniden oluşturun.
- B'de tüm birincil veritabanlarını yeni yük devretme grubuna ekleyin. Bu noktada oturum açma denemeleri başarısız oluyor.
- B ve C arasında geçiş yapmak için yük devretme grubunun planlı coğrafi yük devretme işlemini gerçekleştirin. Şimdi sunucu C birincil, B ise ikincil sunucu olur. A sunucusundaki tüm ikincil veritabanları otomatik olarak C'nin birincil veritabanlarına bağlanacaktır. 1. adımda olduğu gibi yük devretme birkaç dakika kapalı kalma süresiyle sonuçlanabiliyor.
- Sunucuyu silme A. A'da tüm veritabanları otomatik olarak silinir.
Önemli
Yük devretme grubu silindiğinde dinleyici uç noktalarının DNS kayıtları da silinir. Bu noktada, başka birinin aynı adla yük devretme grubu veya sunucu DNS diğer adı oluşturması sıfır olmayan bir olasılıktır. Yük devretme grubu adları ve DNS diğer adları genel olarak benzersiz olmalıdır, çünkü bu, aynı adı yeniden kullanmalarını önler. Bu riski en aza indirmek için genel yük devretme grubu adlarını kullanmayın.
Yönetilen Örnek için yük devretme grubu SQL yöntemleri
Otomatik yük devretme grubu birincil örnekte yapılandırılmalıdır ve onu farklı bir Azure bölgesinde yer alan ikincil örneğe bağlar. Örnekteki tüm kullanıcı veritabanları ikincil örnekte çoğaltılır. Master ve msdb gibi sistem veritabanları çoğaltılmaz.
Aşağıdaki diyagramda yönetilen örnek ve otomatik yük devretme grubu kullanılarak coğrafi olarak yedekli bir bulut uygulamasının tipik bir yapılandırması yer almaktadır.

Not
Yük devretme grubunu kullanmak için Yönetilen Örnek ekleme hakkında ayrıntılı adım adım öğretici için bkz. Yük devretme SQL yönetilen örnek ekleme.
Uygulamanız veri SQL yönetilen örneği kullanıyorsa, iş sürekliliği tasarımında şu genel yönergeleri izleyin:
Coğrafi olarak ikincil yönetilen örneği oluşturma
Yük devretmeden sonra birincil SQL yönetilen örneğin bağlantısının kesintiye uğramaması için hem birincil hem de ikincil örneklerin aynı DNS bölgesinde olması gerekir. Yük devretme grubunda iki örnekten herhangi biri için istemci bağlantılarının kimliğini doğrulamak için aynı çok etki alanı (SAN) sertifikasının kullanıla olacağını garanti eder. Uygulamanız üretim dağıtımı için hazır olduğunda, farklı bir bölgede SQL yönetilen yönetilen örnek için ikincil bir yönetilen örnek oluşturun ve DNS bölgesi ile birincil yönetilen SQL emin olun. Oluşturma sırasında isteğe bağlı bir parametre belirterek bunu yapabiliriz. PowerShell veya powershell REST API isteğe bağlı parametrenin adı şu DNSZonePartner şekildedir: . Örnek içinde karşılık gelen isteğe bağlı Azure portal Birincil Yönetilen Örnek'tir.
Önemli
Alt ağda oluşturulan ilk yönetilen örnek, aynı alt ağda yer alan sonraki tüm örnekler için DNS bölgesi belirler. Bu, aynı alt ağdan gelen iki örneğin farklı DNS bölgelere ait olamayy anlamına gelir.
birincil örnekle aynı DNS bölgesinde ikincil SQL yönetilen örnek oluşturma hakkında daha fazla bilgi için bkz. İkincil yönetilen örnek oluşturma.
Eşleştirilmiş bölgeleri kullanma
Performans nedenleriyle her iki yönetilen örneği de eşleştirilmiş bölgelere dağıtın. SQL Eşleştirilmiş bölgelerdeki Yönetilen Örnek yük devretme grupları, eşleştirilmiş olmayan bölgelere kıyasla daha iyi performansa sahip olur.
İki yönetilen örnek arasında coğrafi çoğaltma trafiğini etkinleştirme
Her yönetilen örnek kendi sanal a ağı içinde yalıtılmış olduğundan, bu sanal ağlar arasında iki yönlü trafiğe izin verilmiyor. Bkz. Azure VPN ağ geçidi
Farklı aboneliklerde yönetilen örnekler arasında yük devretme grubu oluşturma
İki farklı abonelikte yönetilen SQL arasında bir yük devretme grubu oluşturabilirsiniz; abonelikler aynı kiracı kiracısı ile ilişkili olduğu Azure Active Directory. PowerShell API'sini kullanırken, bunu yönetilen yönetilen örnek için ikincil SQL PartnerSubscriptionId belirtebilirsiniz. Bu REST API, parametreye dahil edilen her örnek properties.managedInstancePairs kimliğinin kendi Abonelik Kimliği olabilir.
Önemli
Azure portal, farklı abonelikler arasında yük devretme gruplarının oluşturulmasını desteklemez. Ayrıca, farklı abonelikler ve/veya kaynak grupları arasında mevcut yük devretme grupları için, birincil abonelikten ve Yönetilen Örnekten portal aracılığıyla el SQL başlatılamaz. Bunun yerine yük devretmeyi coğrafi olarak ikincil örnekten başlatın.
Coğrafi olarak ikincil bir örnek için coğrafi yük devretmeyi yönetme
Yük devretme grubu, birincil yönetilen örnekteki tüm veritabanlarının coğrafi yük devretmelerini yönetir. Bir grup oluşturulduğunda, örnekteki her veritabanı coğrafi olarak coğrafi olarak ikincil örneğine çoğaltılır. Veritabanlarının bir alt kümesinin kısmi yük devretmesi başlatmak için yük devretme gruplarını kullanamazsınız.
Önemli
Bir veritabanı birincil yönetilen örnekte bırakılırsa, coğrafi olarak ikincil yönetilen örnekte de otomatik olarak bırakılır.
Birincil yönetilen örneğine bağlanmak için okuma/yazma dinleyicisi kullanma
Okuma/yazma iş yükleri için sunucu <fog-name>.zone_id.database.windows.net adı olarak kullanın. Bağlantılar otomatik olarak birincile yönlendirilir. Yük devretme sonrasında bu ad değişmez. Coğrafi yük devretme, DNS kaydının güncelleştirilmesini içerir, bu nedenle istemci bağlantıları yalnızca istemci DNS önbelleği yenilendikten sonra yeni birincile yeniden yönlendirildi. İkincil örnek DNS bölgesini birincil örnekle paylaştığı için, istemci uygulaması aynı sunucu tarafı SAN sertifikasını kullanarak buna yeniden bağlanabilecektir.
Coğrafi olarak ikincil yönetilen örneğine bağlanmak için salt okunur dinleyiciyi kullanma
Veri gecikme süresine karşı karşı olan mantıksal olarak yalıtılmış salt okunur iş yükleri varsa, bunları coğrafi olarak ikincilde çalıştırabilirsiniz. Coğrafi olarak ikincil bölgeye doğrudan bağlanmak için sunucu <fog-name>.secondary.<zone_id>.database.windows.net adı olarak kullanın.
Not
İş Açısından Kritik yönetilen SQL, bağlantı dizesinde parametresini kullanarak salt okunur sorgu iş yüklerini boşaltmak için salt okunur ApplicationIntent=ReadOnly çoğaltmaların kullanımını destekler. Coğrafi olarak çoğaltılan ikincil örneği yapılandırdığınızda bu özelliği kullanarak birincil konumdaki veya coğrafi olarak çoğaltılan konumdaki bir salt okuma çoğaltmasına bağlanabilirsiniz.
- Birincil konumdaki salt okunur bir çoğaltmaya bağlanmak için ve
ApplicationIntent=ReadOnly<fog-name>.<zone_id>.database.windows.netkullanın. - İkincil konumdaki salt okunur bir çoğaltmaya bağlanmak için ve
ApplicationIntent=ReadOnly<fog-name>.secondary.<zone_id>.database.windows.netkullanın.
Coğrafi olarak ikincil yönetilen örneğine 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, Azure güvenlik grubu bileşenlerinin durumuna SQL tetiklenir. Birincil bölgedeki diğer Azure hizmetleri kesintiden etkilenmeyebilirsiniz ve bileşenleri bu bölgede kullanılabilir durumda olabilir. Birincil veritabanları ikincil bölgeye geçiş yapıldıktan 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, ikincil bölgedeki tüm uygulama bileşenlerinin yedekli olduğundan ve veritabanıyla birlikte uygulama bileşenlerinin yük devretmesini sağlar. Yapılandırma zamanında, ikincil bölgedeki veritabanına bağlantı sağlamak için ağ güvenlik yönergelerini izleyin.
Coğrafi olarak ikincil yönetilen örneğine yük devretme sonrasında olası veri kaybı
Birincil bölgede bir kesinti oluşursa, son işlemler coğrafi olarak ikincil bölgeye çoğaltılamayabiliyor olabilir. Otomatik yük devretme ilkesi yapılandırılırsa, veri kaybı yaşanmazsa coğrafi yük devretme tetiklenir. Aksi takdirde, yük devretme, kullanarak belirttiğiniz süre boyunca GracePeriodWithDataLossHours ertelenmiştir. Otomatik yük devretme ilkesi yapılandırdıysanız, veri kaybı için hazırlıklı olun. Genel olarak, kesintiler sırasında Azure kullanılabilirliği tercih ediyor. 24 saat gibi daha büyük bir sayıya ayarlanarak veya otomatik coğrafi yük devretmenin devre dışı bırakılması, veritabanı kullanılabilirliği nedeniyle veri kaybı olasılığını GracePeriodWithDataLossHours azaltmaya olanak sağlar.
Yük devretme başlatıldıktan hemen sonra okuma-yazma dinleyicisi DNS güncelleştirmesi güncelleştirmesi gerçekleşecektir. Bu işlem veri kaybına neden olmaz. Ancak, veritabanı rollerini değiştirme işlemi normal koşullarda 5 dakika kadar sürebilir. Tamamlanana kadar, yeni birincil örnekteki bazı veritabanları yine de salt okunur olur. PowerShell kullanılarak yük devretme başlatılırsa, birincil çoğaltma rolünü değiştirme işlemi zaman uyumludur. Kullanıcı arabirimi kullanılarak başlatılırsa Azure portal kullanıcı arabirimi tamamlanma durumunu gösterir. REST API kullanılarak başlatılırsa, tamamlanmasını izlemek için Azure Resource Manager'nin 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 devretme kullanın.
Yönetilen örnek yük devretme grubunun ikincil bölgesini değiştirme
A örneğinin birincil örnek olduğunu, B örneğinin mevcut ikincil örnek olduğunu ve C örneğinin üçüncü bölgedeki yeni ikincil örnek olduğunu varsayalım. Geçişi yapmak için şu adımları izleyin:
- A ile aynı boyutta ve aynı DNS bölgesinde C örneği oluşturun.
- A ve B örnekleri arasındaki yük devretme grubunu silin. Bu noktada, yük devretme grubu dinleyicilerine SQL diğer adları silindikten ve ağ geçidi yük devretme grubu adını tanımayacak olduğundan oturum açma bilgileri başarısız olur. İkincil veritabanlarının birincil veritabanlarıyla bağlantısı kesilir ve okuma-yazma veritabanlarına dönüşecek.
- a ve C örneğiyle aynı ada sahip bir yük devretme grubu oluşturun. SQL yönetilen örnek öğreticisi ile yük devretme grubundakiyönergeleri izleyin. Bu bir veri boyutudur ve bir örnek A 'dan tüm veritabanları birlikte çalıştırıldığında ve eşitlendiğinde tamamlanacaktır.
- Gereksiz ücretlerden kaçınmak için gerekmiyorsa örnek B 'yi silin.
Not
- adım ve 3. adım tamamlanana kadar sonra A örneğindeki veritabanları korumasız olarak kalır.
Yönetilen örnek yük devretme grubunun birincil bölgesini değiştirme
Örnek A 'nın birincil örnek olduğu varsayıyoruz, örnek B var olan ikincil örnek ve C örneği, üçüncü bölgedeki yeni birincil örnek. Geçişi yapmak için şu adımları izleyin:
- B örneğini aynı boyuta sahip C ve aynı DNS bölgesinde oluşturun.
- birincil örneği b 'ye geçirmek için b örneğine ve el ile yük devretmeye Bağlan. örnek A, yeni ikincil örnek otomatik olarak olur.
- A ve B örnekleri arasında yük devretme grubunu silin. Bu noktada, yük devretme grubu uç noktalarını kullanan oturum açma girişimleri başarısız olur. Bir üzerindeki ikincil veritabanlarının, bu yana bağlı olarak bağlantısı kesilecek ve okuma yazma veritabanları olur.
- A ve C örneğiyle aynı ada sahip bir yük devretme grubu oluşturun. Yük devretme grubundaki yönergeleri yönetilen örnek öğreticisiyleizleyin. Bu bir veri boyutudur ve bir örnek A 'dan tüm veritabanları birlikte çalıştırıldığında ve eşitlendiğinde tamamlanacaktır. Bu noktada oturum açma girişimleri başarısız olur.
- Gereksiz ücretlerden kaçınmak için gerekmiyorsa örneğini silin.
Dikkat
Adım 3 ' ten sonra ve 4. adım tamamlanana kadar sonra a örneğindeki veritabanları korumasız olarak kalır.
Önemli
Yük devretme grubu silindiğinde, dinleyici uç noktaları için DNS kayıtları da silinir. Bu noktada, başka birisinin aynı ada sahip bir yük devretme grubu oluşturması için sıfır olmayan bir olasılık vardır. Yük devretme grubu adları genel olarak benzersiz olması gerektiğinden, bu, aynı adı yeniden kullanmanızı engeller. Bu riski en aza indirmek için genel yük devretme grubu adlarını kullanmayın.
Sistem veritabanlarından nesnelere bağımlı senaryoları etkinleştirme
Sistem veritabanları, bir yük devretme grubundaki ikincil örneğe çoğaltılmaz. Sistem veritabanlarından nesnelere bağlı olan senaryoları etkinleştirmek için, ikincil örnekte aynı nesneleri oluşturun ve bunların birincil örnekle eşitlenmiş halde kalmasını sağlayın.
Örneğin, ikincil örnekte aynı oturum açmaları kullanmayı planlıyorsanız, bunları aynı SID ile oluşturmayı unutmayın.
-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;
Birincil ve ikincil örnek arasında örnek özelliklerini ve bekletme ilkelerini eşitler
Bir yük devretme grubundaki örnekler ayrı Azure kaynakları olarak kalır ve birincil örnek yapılandırmasında hiçbir değişiklik yapıldığında ikincil örneğe otomatik olarak çoğaltılır. Hem birincil hem de ikincil örnekte ilgili tüm değişiklikleri gerçekleştirdiğinizden emin olun. Örneğin, birincil örnekteki yedek depolama artıklığı veya uzun süreli yedek saklama ilkesini değiştirirseniz, ikincil örnek üzerinde de değiştirdiğinizden emin olun.
Yük devretme grupları ve ağ güvenliği
Bazı uygulamalarda, güvenlik kuralları, veri katmanına ağ erişiminin bir VM, Web hizmeti vb. gibi belirli bir bileşenle veya bileşenlerle 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ükleri sunmaktadır. 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ğ hizmeti uç noktalarını kullanma
SQL Veritabanı veya SQL yönetilen örnekteki veritabanınıza erişimi kısıtlamak için sanal ağ hizmet uç noktaları ve kuralları kullanıyorsanız, her bir sanal ağ hizmeti 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 iletişim kabul etmesine izin vermez. Bu nedenle, yalnızca aynı bölgede dağıtılan istemci uygulamaları birincil veritabanına bağlanabilir. coğrafi yük devretme, SQL Veritabanı istemci oturumlarının farklı bir (ikincil) bölgedeki bir sunucuya tekrar yönlendirilmesinden kaynaklanır, bu oturumlar söz konusu bölgenin dışındaki bir istemciden kaynaklandığından başarısız olur. Bu nedenle, katılan sunucular veya örnekler sanal ağ kurallarında yer alıyorsa otomatik yük devretme ilkesi etkinleştirilemez. El ile yük devretmeyi desteklemek için şu adımları izleyin:
- Uygulamanızın ön uç bileşenlerinin (Web hizmeti, sanal makineler vb.) yedek kopyalarını ikincil bölgede sağlayın.
- Sanal ağ kurallarını birincil ve ikincil sunucu için ayrı ayrı yapılandırın.
- Traffic Manager yapılandırması kullanarak ön uç yük devretmesinietkinleştirin.
- Kesinti algılandığında el ile coğrafi Yük devretme başlatın. Bu seçenek, ön uç ve veri katmanı arasında tutarlı gecikme süresi gerektiren uygulamalar için en iyi duruma getirilmiştir ve ön uç, veri katmanı veya her ikisi de kesinti tarafından etkilendiğinde kurtarmayı destekler.
Not
Salt yazılır bir iş yükünü dengelemek için salt okunurdur dinleyiciyi kullanıyorsanız, ikincil veritabanına bağlanabilmesi için bu iş yükünün ikincil BÖLGEDEKI bir VM 'de veya diğer bir kaynakta yürütüldüğünden emin olun.
Yük devretme gruplarını ve güvenlik duvarı kurallarını kullanma
iş sürekliliği planınız, otomatik yük devretme içeren grupları kullanarak yük devretme gerektiriyorsa, genel ıp 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:
- Genel IP oluşturma
- Ortak yük dengeleyici oluşturun ve genel IP 'yi buna atayın.
- Ön uç bileşenleriniz için bir sanal ağ ve sanal makineler oluşturun .
- Ağ güvenlik grubu oluşturun ve gelen bağlantıları yapılandırın.
- giden bağlantıların bir
Sql.<Region>hizmet etiketikullanarak bir bölgede Azure SQL Veritabanı için açık olduğundan emin olun. - adım 1 ' de oluşturduğunuz genel ıp adresinden gelen trafiğe izin vermek için SQL Veritabanı bir güvenlik duvarı kuralı oluşturun.
Giden erişimin nasıl yapılandırılacağı ve güvenlik duvarı kurallarında hangi IP 'nin kullanılacağı hakkında daha fazla bilgi için bkz. yük dengeleyici giden bağlantıları.
Yukarıdaki yapılandırma, bir otomatik coğrafi Yük devretmenin ön uç bileşenlerinden gelen bağlantıları engelolmamasını ve uygulamanın ön uç ile veri katmanı arasındaki daha uzun gecikmeye neden olduğunu varsaymaktadır.
Önemli
Bölgesel kesintiler sırasında iş sürekliliği sağlamak için hem ön uç bileşenleri hem de veritabanları için coğrafi artıklık sağlamalısınız.
Yönetilen örnek sanal ağlar arasında Coğrafi çoğaltmayı etkinleştirme
iki farklı bölgede birincil ve ikincil SQL yönetilen örnekler arasında bir yük devretme grubu ayarlarken, her örnek bağımsız bir sanal ağ kullanılarak yalıtılmıştır. Bu sanal ağlar arasındaki çoğaltma trafiğine izin vermek için bu önkoşulların karşılandığından emin olun:
SQL yönetilen örneğin iki örneğinin farklı Azure bölgelerinde olması gerekir.
SQL yönetilen örneğin iki örneğinin aynı hizmet katmanı olması ve aynı depolama boyutuna sahip olması gerekir.
SQL yönetilen örneğinin ikincil örneğinizin boş olması gerekir (kullanıcı veritabanı yok).
SQL yönetilen örnek tarafından kullanılan sanal ağların bir VPN Gateway veya Express Routeile bağlanması gerekir. İki sanal ağ şirket içi ağı üzerinden bağlandığında 5022 ve 11000-11999 numaralı bağlantı noktalarını engelleyen bir güvenlik duvarı kuralı olmadığından emin olun. Genel VNet Eşlemesi aşağıdaki notta açıklanan sınırlamayla desteklenir.
Önemli
Yeni oluşturulan sanal kümeler için genel sanal ağ eşlemesi 9/22/2020 üzerinde, duyurulmuştur. bu, genel sanal ağ eşlemesinin, duyuru tarihinden sonra boş alt ağlarda oluşturulan SQL yönetilen örneklerin yanı sıra bu alt ağlarda oluşturulan tüm sonraki yönetilen örneklere de desteklendiği anlamına gelir. diğer tüm SQL yönetilen örnekler için eşleme desteği, genel sanal ağ eşlemesi kısıtlamalarındandolayı aynı bölgedeki ağlarla sınırlıdır. Daha fazla bilgi için bkz. Azure sanal ağlar sık sorulan sorular makalesinin ilgili bölümü. duyuru tarihinden önce oluşturulan sanal kümelerdeki SQL yönetilen örnekler için genel sanal ağ eşlemesi kullanabilmek için, örnekleri genel sanal ağ eşliğini destekleyen yeni sanal kümelere taşıyacağınız için örneklerde varsayılan olmayan bakım penceresini yapılandırmayı göz önünde bulundurun.
iki SQL yönetilen örnek sanal ağları çakışan ıp adreslerine sahip olamaz.
Ağ Güvenlik Gruplarınızı (NSG), 5022 numaralı ve 11000~12000 aralığındaki bağlantı noktalarının diğer yönetilen örneğin alt ağından gelen ve giden bağlantılara açık olmasını sağlayacak şekilde ayarlamalısınız. Bunun amacı örnekler arasında çoğaltma trafiğine olanak tanımaktır.
Önemli
Yanlış yapılandırılmış NSG güvenlik kuralları, veritabanı dengeli işlem işlemlerine yol açar.
ikincil SQL yönetilen örneği doğru DNS bölge kimliğiyle yapılandırılır. DNS bölgesi, SQL yönetilen bir örneğin ve temel alınan sanal kümenin bir özelliğidir ve kimliği ana bilgisayar adı adresine dahildir. bölge kimliği, ilk SQL yönetilen örnek her VNet 'te oluşturulduğunda ve aynı kimlik aynı alt ağdaki diğer tüm örneklere atandığında rastgele bir dize olarak oluşturulur. Atandıktan sonra DNS bölgesi değiştirilemez. SQL Aynı yük devretme grubuna dahil edilen yönetilen örnekler, DNS bölgesini paylaşmalıdır. Bu, ikincil örneği oluştururken birinci örneğin bölge KIMLIĞINI DnsZonePartner parametresinin değeri olarak geçirerek gerçekleştirirsiniz.
Not
SQL yönetilen örnekle yük devretme gruplarını yapılandırmaya ilişkin ayrıntılı bir öğretici için bkz. bir yük devretme grubuna SQL yönetilen örnek ekleme.
Birincil veritabanını ölçeklendirin
Birincil veritabanının ölçeğini, coğrafi ikincil öğeler bağlantısını kesmeden farklı bir işlem boyutuna (aynı hizmet katmanı içinde) ölçeklendirebilir veya azaltabilirsiniz. Wonu ölçeklendirirken, önce coğrafi birincili ölçeklendirmenizi ve ardından birincili ölçeği büyütmeyi öneririz. Ölçeği aşağı ölçeklendirirken sırayı tersine çevirin: önce birincili ölçeği azaltın ve sonra ikincil ölçeği azaltın. Bir veritabanını farklı bir hizmet katmanına ölçeklendirirseniz, bu öneri zorlanır.
Bu dizi, daha düşük bir SKU 'daki coğrafi ikincil öğenin aşırı yüklendiği ve yükseltme veya düşürme işlemi sırasında yeniden hazırlanması gereken sorunlardan kaçınmak için özellikle ö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 bir coğrafi ikincil oluşturduysanız, coğrafi ikincil değer ölçeği 'nin ölçeklendirilmesi önerilmez. Bu, veri katmanınızın coğrafi Yük devretmeden sonra düzenli iş yükünüzü işlemek için yeterli kapasiteye sahip olmasını sağlamaktır.
Kritik verilerin kaybını önleme
Geniş alan ağlarının yüksek gecikmesi 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ı ortadan kaldırılmaz hale getirir. Bir uygulama geliştiricisi, veri kaybından önemli işlemleri korumak için, işlem tamamlandıktan hemen sonra sp_wait_for_database_copy_sync saklı yordamını çağırabilir. Çağırma, sp_wait_for_database_copy_sync son kaydedilen işlem, ikincil veritabanının işlem günlüğünde iletilene ve sağlamlana kadar çağıran iş parçacığını engeller. Ancak, ikincil üzerinde iletilen işlemlerin yeniden çalınmasını (redone) beklemez. sp_wait_for_database_copy_sync , belirli bir coğrafi çoğaltma bağlantısının kapsamına alınır. Birincil veritabanında bağlantı hakları olan herhangi bir Kullanıcı, bu yordamı çağırabilir.
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. Bir yordam çağrısının neden olduğu gecikme sp_wait_for_database_copy_sync önemli olabilir ve çağrı sırasında birincil üzerinde henüz gönderilmemiş olan işlem günlüğünün boyutuna bağlıdır.
Yük devretme grupları ve zaman içinde noktaya geri yükleme
Yük devretme gruplarıyla zaman içinde nokta geri yükleme kullanma hakkında bilgi için bkz. Noktadan Noktaya Kurtarma (PITR).
Yük devretme gruplarının sınırlamaları
Aşağıdaki sınırlamalara dikkat edin:
- Yük devretme grupları aynı Azure bölgesinde iki sunucu veya örnek arasında oluşturulamaz.
- Yük devretme grupları yeniden adlandırılamaz. Grubu silmeniz ve farklı bir adla yeniden oluşturmanız gerekir.
- Yük devretme grubunda veritabanları için veritabanı yeniden adlandırması desteklenmiyor. Veritabanını yeniden adlandırabilecek veya veritabanını yük devretme grubundan kaldırabilecek şekilde yük devretme grubunu geçici olarak silmeniz gerekir.
- Sistem veritabanları bir yük devretme grubunda ikincil örnek için çoğaltılmaz. Bu nedenle, sistem veritabanlarından nesnelere bağımlı senaryolar, nesnelerin ikincil örneklerde el ile oluşturularak aynı zamanda birincil örnekte yapılan değişikliklerden sonra el ile eşit tutulmasını gerektirir. Tek özel durum, yük devretme grubu oluşturulurken otomatik olarak ikincil SQL çoğaltılan Yönetilen Örnek için Hizmet ana Anahtarıdır (SMK). Ancak birincil örnekte SMK'nin sonraki değişiklikleri ikincil örnekte çoğaltılmaz.
- Bunlardan herhangi biri örnek havuzunda yer alan örnekler arasında yük devretme grupları oluşturulamaz.
Yük devretme gruplarını program aracılığıyla yönetme
Daha önce de belirtildiği gibi, otomatik yük devretme grupları Azure PowerShell, Azure CLI ve REST API. Aşağıdaki tablolarda kullanılabilir komut kümesi açık bulunmaktadır. Etkin coğrafi çoğaltma, Azure SQL Veritabanı REST API cmdlet'Azure Resource Managerleri dahil olmak üzere yönetim için Azure SQL Veritabanı REST API api'Azure PowerShell içerir. Bu API'ler kaynak gruplarının kullanımını gerektirir ve Azure rol tabanlı erişim denetimi (Azure RBAC) desteği sunar. Erişim rollerini uygulama hakkında daha fazla bilgi için bkz. Azure rol tabanlı erişim denetimi (Azure RBAC).
Coğrafi SQL Veritabanı yük devretmeyi yönetme
| Cmdlet | Açıklama |
|---|---|
| New-AzSqlDatabaseFailoverGroup | Bu komut bir yük devretme grubu oluşturur ve bunu hem birincil hem de ikincil sunuculara kaydettirer |
| Remove-AzSqlDatabaseFailoverGroup | Yük devretme grubunu sunucudan kaldırır |
| Get-AzSqlDatabaseFailoverGroup | Yük devretme grubunun yapılandırmasını alma |
| Set-AzSqlDatabaseFailoverGroup | Yük devretme grubunun yapılandırmasını değiştiren |
| Switch-AzSqlDatabaseFailoverGroup | Bir yük devretme grubunun ikincil sunucuya yük devretmeyi tetikler |
| Add-AzSqlDatabaseToFailoverGroup | Yük devretme grubuna bir veya daha fazla veritabanı ekler |
Yönetilen SQL coğrafi yük devretmeyi yönetme
| Cmdlet | Açıklama |
|---|---|
| New-AzSqlDatabaseInstanceFailoverGroup | Bu komut bir yük devretme grubu oluşturur ve bunu hem birincil hem de ikincil örneklere kaydettirer |
| Set-AzSqlDatabaseInstanceFailoverGroup | Yük devretme grubunun yapılandırmasını değiştiren |
| Get-AzSqlDatabaseInstanceFailoverGroup | Yük devretme grubunun yapılandırmasını alma |
| Switch-AzSqlDatabaseInstanceFailoverGroup | Bir yük devretme grubunun ikincil örneğine yük devretmeyi tetikler |
| Remove-AzSqlDatabaseInstanceFailoverGroup | Yük devretme grubunu kaldırır |
Sonraki adımlar
- Ayrıntılı öğreticiler için bkz.
- Örnek betikler için bkz:
- Coğrafi çoğaltma için etkin coğrafi çoğaltmayı yapılandırmak üzere PowerShell Azure SQL Veritabanı
- Azure SQL Veritabanı'de havuza havuza alan bir veritabanı için etkin coğrafi çoğaltmayı yapılandırmak için PowerShell'i Azure SQL Veritabanı
- Yük devretme grubuna bir Azure SQL Veritabanı eklemek için PowerShell kullanma
- İş sürekliliği genel bakışı ve senaryoları için bkz. İş sürekliliğine genel bakış
- Otomatik yedeklemeleri Azure SQL Veritabanı için bkz. SQL Veritabanı yedeklemeleri.
- Kurtarma için otomatik yedeklemeleri kullanma hakkında bilgi edinmek için bkz. Hizmet tarafından başlatılan yedeklemelerden veritabanını geri yükleme.
- Yeni bir birincil sunucu ve veritabanı için kimlik doğrulama gereksinimleri hakkında bilgi edinmek için bkz. olağanüstü SQL Veritabanı sonra güvenlik.