Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bu makalede, NoSQL için Azure Cosmos DB'de yüksek kullanılabilirlik (güvenilirlik) desteği açıklanır ve hem kullanılabilirlik alanları hem de bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği ele alınmaktadır.
İşlem düğümlerinin dayanıklılığı
Azure Cosmos DB, tek tek işlem düğümlerinin tüm ayrıntılarını saydam bir şekilde yönetir. Herhangi bir düzeltme eki uygulama veya planlı bakım konusunda endişelenmeniz gerekmez. Azure Cosmos DB, sistemin gerçekleştirdiği tüm otomatik bakım işlemleri aracılığıyla kullanılabilirlik ve P99 gecikme süresi için SLA'ları garanti eder.
Azure Cosmos DB, dört çoğaltmalı çekirdek içindeki hesabınız için her Azure bölgesindeki verilerinizin en az üç çoğaltmasını garanti ederek çoğaltma kesintilerini otomatik olarak azaltır. Bu garanti, uygulama değişikliklerine veya yapılandırmalara gerek kalmadan tek tek düğüm kesintileri için 0 RTO'sunun ve 0 RPO'sunun ortaya çıkmasını sağlar. RTO ve RPO hakkında bilgi için bkz. İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?
Kullanılabilirlik alanı desteği
Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.
Azure Cosmos DB , alanlar arası yedekliliği destekler. Alanlar arası yedekliliği etkinleştirdiğinizde Azure, verilerinizin çoğaltmalarını birden çok kullanılabilirlik alanına dağıtarak veri merkezi sorunlarına ve kesintilerine dayanıklılık sağlar. Kullanılabilirlik alanlarını destekleyen Azure bölgelerinde alanlar arası yedekliliği etkinleştirebilirsiniz. Bölgenizin kullanılabilirlik alanlarını desteklenip desteklemediğini görmek için desteklenen bölgelerin listesine bakın.
Özellikle tek bölgeli hesaplar için desteklenen bölgelerde bölge yedekliliği kullanmanızı öneririz.
Alanlar arası yedeklilik ve tek bölgeli hesaplar
Tek bölgeli bir Cosmos DB hesabınız varsa, kullanılabilirlik alanındaki sorunlara karşı dayanıklı olmak önemlidir. Bölge yedekliliğini etkinleştirmek, bir kullanılabilirlik bölgesinin başarısızlığı nedeniyle toplam kullanılabilirlik kaybını önler.
Kullanılabilirlik alanları fiziksel olarak ayrı olduğundan ve ayrı güç kaynağı, ağ ve soğutma sağladığından, Azure Cosmos DB için kullanılabilirlik SLA'ları alanlar arası yedekli hesaplar için kullanılabilirlik alanlarını kullanmayan hesaplardan daha yüksektir.
Alanlar arası yedeklilik ve çok bölgeli hesaplar
Çok bölgeli bir hesabınız varsa, isteğe bağlı olarak kullanılabilirlik alanlarını destekleyen hesap bölgelerinin herhangi birinde veya tümlerinde bölge yedekliliğini etkinleştirebilirsiniz. Çok bölgeli hesaplar yüksek kullanılabilirlik hizmet düzeyi sözleşmeleri (SLA' lar) elde edebilir ve alanlar arası yedekliliği etkinleştirmek, bu bölgelerde elde ettiğiniz genel kullanılabilirlik SLA'larını daha da geliştirebilir.
Çok bölgeli hesaplarda, bölge yedekliliğinin NoSQL için Cosmos DB veritabanınızın kullanılabilirliği üzerindeki etkisi, hesabın tutarlılık düzeyine ve bölge yedekliliğinin etkinleştirildiği bölgelere bağlıdır. Çok bölgeli hesap yapılandırmanızda kullanılabilirlik alanlarını kullanmanın etkisini tahmin etmek için aşağıdaki tabloya bakın:
| Hesap tutarlılığı düzeyi | Kullanılabilirlik alanlarının etkinleştirildiği bölgeler | Kullanılabilirlik alanlarını kullanmanın etkisi |
|---|---|---|
| Zaman Uyumlu (Güçlü) | bir ikincil okuma bölgesi | Bölge yedekliliğinin yüksek avantajı. Bu senaryoda okuma bölgesinin kaybı yazma kullanılabilirliğini etkileyebileceğinden daha fazla değer sağlar. |
| Zaman Uyumlu (Güçlü) | İki veya daha fazla ikincil okuma bölgesi | Alan yedekliliği değerinin düşüklüğü. Sistem okuma bölgesinin kullanılabilirliğini kaybetmesi ve yazma işleminin devam etmesine olanak tanıdığından, sistem dinamik çekirdekten yararlanabildiğinden marjinal değer sağlar. |
| Zaman uyumsuz (Sınırlanmış Eskime veya zayıf) | Bir veya daha fazla ikincil okuma bölgesi | Alan yedekliliği değerinin düşüklüğü. SDK zaten okuma bölgesi başarısız olduğunda okumalar için sorunsuz yeniden yönlendirmeler sağladığından en düşük değeri sağlar. |
| Herhangi biri | Tüm yazma bölgeleri ve herhangi bir sayıda ikincil bölge | Bölge yedekliliğinin yüksek avantajı. Yazma işlemleri için, kullanılabilirlik alanı hatalarına karşı daha yüksek kullanılabilirlik sağlar. |
Bölge yedekliliğini etkinleştirme maliyeti
Bölge yedekliliğinin etkinleştirildiği bölgeler 25% ek ücretle faturalandırılır. Ancak, çok bölgeli yazma işlemleriyle yapılandırılan hesaplar ve/veya otomatik ölçeklendirme moduyla yapılandırılmış koleksiyonlar için kullanılabilirlik alanları için premium fiyatlandırmadan feragat edilir.
Cosmos DB hesabına ek bölge eklemek genellikle mevcut faturanızı her bölge için 100% artırır. Ancak, bölgeler arasında maliyette küçük varyasyonlar vardır.
Diğer ayrıntılar için bkz . fiyatlandırma sayfası.
SLA geliştirmeleri
Azure Cosmos DB hesabının dayanıklılığını ve kullanılabilirliğini artırmak için aşağıdakileri içeren bir katmanlama yaklaşımı uygulayabilirsiniz:
- Alanlar arası yedekliliği etkinleştirme.
- Bir veya daha fazla ek bölge ekleme.
- Çoklu bölge yazma işlemlerini etkinleştirme.
Katmanlama yaklaşımı, bölge yedekliliği olmadan tek bölgeli bir yapılandırma için 4 9'luk kullanılabilirlikten, bölge yedekliliği olan tek bölge için 4 buçuk 9'luk ve çok bölgeli yazma seçeneği etkinleştirildiğinde çok bölgeli yapılandırma için 5 9'luk kullanılabilirlik seviyesine kadar her adımda hesabı korur.
Aşağıdaki tabloda her yapılandırma için SLA'ların özeti yer alır:
| KPI | Kullanılabilirlik alanları olmadan tek bölgeli yazma işlemleri | Kullanılabilirlik alanlarıyla tek bölgeli yazma işlemleri | Kullanılabilirlik alanları olmadan birden çok bölgeli, tek bölgeli yazma işlemleri | Kullanılabilirlik alanlarıyla birden çok bölgeli, tek bölgeli yazma işlemleri | Kullanılabilirlik alanlarıyla veya kullanılabilirlik alanları olmadan birden çok bölgeli, çok bölgeli yazma işlemleri |
|---|---|---|---|---|---|
| Yazma kullanılabilirliği SLA'sı | %99,99 | 99.995% | %99,99 | 99.995% | %99,999 |
| Okuma kullanılabilirliği SLA'sı | %99,99 | 99.995% | %99,999 | %99,999 | %99,999 |
| Bölge hataları: veri kaybı | Veri kaybı | Veri kaybı yok | Veri kaybı yok | Veri kaybı yok | Veri kaybı yok |
| Bölge hataları: kullanılabilirlik | Kullanılabilirlik kaybı | Kullanılabilirlik kaybı yok | Kullanılabilirlik kaybı yok | Kullanılabilirlik kaybı yok | Kullanılabilirlik kaybı yok |
| Bölgesel kesinti: veri kaybı | Veri kaybı | Veri kaybı | Tutarlılık düzeyine bağlıdır. Daha fazla bilgi için bkz . Tutarlılık, kullanılabilirlik ve performans dengeleri. | Tutarlılık düzeyine bağlıdır. Daha fazla bilgi için bkz . Tutarlılık, kullanılabilirlik ve performans dengeleri. | Tutarlılık düzeyine bağlıdır. Daha fazla bilgi için bkz . Tutarlılık, kullanılabilirlik ve performans dengeleri. |
| Bölgesel kesinti: kullanılabilirlik | Kullanılabilirlik kaybı | Kullanılabilirlik kaybı | Okuma bölgesi hatası için kullanılabilirlik kaybı yok, yazma bölgesi hatası için geçici | Okuma bölgesi hatası için kullanılabilirlik kaybı yok, yazma bölgesi hatası için geçici | Etkilenen bölgede okuma kullanılabilirliği kaybı, geçici yazma kullanılabilirliği kaybı yok |
| Fiyat (1) | Uygulanamaz | Sağlanan RU/sn x 1,25 oranı | Sağlanan RU/sn x N bölgeleri | Sağlanan RU/sn x 1,25 oran x N bölge (2) | Çok bölgeli yazma hızı x N bölge |
1 Sunucusuz hesaplar için RU'lar 1,25 faktörüyle çarpılır.
2 1,25 oranı yalnızca kullanılabilirlik alanlarını etkinleştirdiğiniz bölgeler için geçerlidir.
Kullanılabilirlik alanlarını yapılandırma
Kullanılabilirlik alanlarının etkinleştirildiği bir kaynak oluşturma
Kullanılabilirlik alanlarını yalnızca Azure Cosmos DB NoSQL hesabına yeni bir bölge eklediğinizde yapılandırabilirsiniz.
Kullanılabilirlik alanı desteğini etkinleştirmek için şunu kullanabilirsiniz:
Kullanılabilirlik alanı desteğini etkinleştirme
Azure Cosmos DB hesabınızda alanlar arası yedekliliği etkinleştirmeyi öğrenmek için bkz. NoSQL için Azure Cosmos DB'yi kullanılabilirlik alanı desteğine geçirme).
Bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği
Olağanüstü durum kurtarma (DR), kuruluşların doğal afetler veya kesinti ve veri kaybına neden olan başarısız dağıtımlar gibi yüksek etkili olaylardan kurtarmak için kullandığı uygulamaları ifade eder. Nedeni ne olursa olsun, olağanüstü durum için en iyi çözüm iyi tanımlanmış ve test edilmiş bir DR planı ve DR'yi etkin bir şekilde destekleyen bir uygulama tasarımıdır. Olağanüstü durum kurtarma planınızı oluşturmaya başlamadan önce bkz. Olağanüstü durum kurtarma stratejisi tasarlama önerileri.
DR için Microsoft, paylaşılan sorumluluk modelini kullanır. Bu modelde Microsoft, temel altyapı ve platform hizmetlerinin kullanılabilir olmasını sağlar. Ancak, birçok Azure hizmeti verileri otomatik olarak çoğaltmaz veya başarısız olan bir bölgeden geri dönerek başka bir etkin bölgeye çapraz çoğaltma yapamaz. Bu hizmetler için iş yükünüz için uygun bir olağanüstü durum kurtarma planı ayarlamak sizin sorumluluğunuzdadır. Hizmet olarak Azure platformu (PaaS) tekliflerinde çalışan hizmetlerin çoğu, DR'yi desteklemek için özellikler ve rehberlik sağlar. DR planınızı geliştirmeye yardımcı olmak üzere hızlı kurtarma desteklemek için hizmete özgü özellikleri kullanabilirsiniz.
Bölge kesintileri, bir Azure bölgesindeki tüm kullanılabilirlik alanlarındaki tüm Azure Cosmos DB düğümlerini etkileyen kesintilerdir. Nadir bölge kesintileri için Azure Cosmos DB'yi çeşitli dayanıklılık ve kullanılabilirlik sonuçlarını destekleyecek şekilde yapılandırabilirsiniz.
Durability
Azure Cosmos DB hesabı tek bir bölgede dağıtıldığında genellikle veri kaybı olmaz. Azure Cosmos DB hizmetleri etkilenen bölgede kurtarıldıktan sonra veri erişimi geri yüklenir. Veri kaybı yalnızca Azure Cosmos DB bölgesinde kurtarılamaz bir olağanüstü durumla oluşabilir.
Azure Cosmos DB, bir bölgedeki olağanüstü olağanüstü durumlardan kaynaklanabilecek tam veri kaybına karşı koruma sağlamanıza yardımcı olmak için iki yedekleme modu sağlar:
- Sürekli yedeklemeler her bölgeyi 100 saniyede bir yedekler . Verilerinizi 1 saniyelik ayrıntı düzeyiyle belirli bir noktaya geri yüklemenize olanak tanır. Her bölgede yedekleme, o bölgede işlenen verilere bağlıdır. Bölgede kullanılabilirlik alanları etkinse yedekleme, alanlar arası yedekli depolama hesaplarında depolanır.
- Düzenli yedeklemeler , bölümler arasında eşitleme olmadan hesabınızın altındaki tüm kapsayıcılardan tüm bölümleri tamamen yedekler. En düşük yedekleme aralığı 1 saattir.
Azure Cosmos DB hesabı birden çok bölgeye dağıtıldığında, veri dayanıklılığı hesapta yapılandırdığınız tutarlılık düzeyine bağlıdır. Tüm tutarlılık düzeyleri için, en az iki bölgede dağıtılan bir Azure Cosmos DB hesabının RPO'sunun aşağıdaki tablo ayrıntıları.
| Tutarlılık düzeyi | Bölge kesintisi için RPO |
|---|---|
| Oturum, tutarlı ön ek, son | 15 dakikadan az |
| Sınırlanmış eskime durumu | K ve T |
| Güçlü | 0 |
K = Bir öğenin sürüm sayısı (yani güncelleştirmeler).
T = Son güncelleştirmeden bu yana geçen zaman aralığı.
Birden çok bölgeli hesaplar için en düşük K ve T değeri 100.000 yazma işlemi veya 300 saniyedir. Bu değer, sınırlanmış eskime durumunu kullanırken veriler için en düşük RPO'yu tanımlar.
Tutarlılık düzeyleri arasındaki farklar hakkında daha fazla bilgi için bkz . Azure Cosmos DB'de tutarlılık düzeyleri.
Hizmet tarafından yönetilen yük devretme
Çözümünüz bölge kesintileri sırasında sürekli çalışma süresi gerektiriyorsa Azure Cosmos DB'yi verilerinizi birden çok bölgede çoğaltacak ve gerektiğinde çalışma bölgelerine saydam bir şekilde yük devredecek şekilde yapılandırabilirsiniz.
Tek bölgeli hesaplar bölgesel bir kesintiden sonra erişilebilirliğini kaybedebilir. İş sürekliliğini her zaman sağlamak için Azure Cosmos DB hesabınızı tek bir yazma bölgesi ve en az bir saniyelik (okuma) bölgeyle ayarlamanızı ve hizmet tarafından yönetilen yük devretmeyi etkinleştirmenizi öneririz.
Hizmet tarafından yönetilen yük devretme, Azure Cosmos DB'nin daha önce Dayanıklılık bölümünde açıklandığı gibi iş sürekliliğini veri kaybı pahasına korumak için birden çok bölgeli bir hesabın yazma bölgesinde yük devretme yapmasına olanak tanır. Bölgesel yük devretmeler Azure Cosmos DB istemcisinde algılanıp işlenir. Uygulamadan herhangi bir değişiklik yapılması gerekmez. Birden çok okuma bölgesini ve hizmet tarafından yönetilen yük devretmeyi etkinleştirme yönergeleri için bkz . Azure portalını kullanarak Azure Cosmos DB hesabını yönetme.
Önemli
Birden çok okuma bölgesi olan tek bölgeli yazma yapılandırmasını seçtiyseniz, hizmet tarafından yönetilen yük devretmeyi etkinleştirmek için üretim iş yükleri için kullanılan Azure Cosmos DB hesaplarını yapılandırmanızı kesinlikle öneririz. Bu yapılandırma, Azure Cosmos DB'nin hesap veritabanlarının yükünü kullanılabilir bölgelere devretmesini sağlar. Bu yapılandırmanın olmaması durumunda hesap, yazma bölgesi kesintisinin tüm süresi boyunca yazma kullanılabilirliği kaybıyla karşılaşır. El ile yük devretme, bölge bağlantısının olmaması nedeniyle başarılı olmayacaktır.
Uyarı
Hizmet tarafından yönetilen yük devretme etkinleştirildiğinde bile kısmi kesinti, Azure Cosmos DB hizmet ekibi için el ile müdahale gerektirebilir. Bu senaryolarda yük devretmenin etkili olması 1 saat (veya daha fazla) sürebilir. Kısmi kesintiler sırasında daha iyi yazma kullanılabilirliği için hizmet tarafından yönetilen yük devretmeye ek olarak kullanılabilirlik alanlarını etkinleştirmenizi öneririz.
Birden çok yazma bölgesi
Azure Cosmos DB'yi birden çok bölgede yazmaları kabul etmek üzere yapılandırabilirsiniz. Bu yapılandırma, coğrafi olarak dağıtılmış uygulamalarda yazma gecikme süresini azaltmak için kullanışlıdır.
Bir Azure Cosmos DB hesabını birden çok yazma bölgesi için yapılandırdığınızda güçlü tutarlılık desteklenmez ve yazma çakışmaları ortaya çıkabilir. Bu çakışmaları çözme hakkında daha fazla bilgi için bkz . Birden çok yazma bölgesi kullanırken çakışma türleri ve çözüm ilkeleri.
Önemli
Aynı Belge Kimliğini sık sık güncelleştirme (veya TTL veya silme işleminden sonra aynı belge kimliğini sık sık yeniden oluşturma), sistemde oluşturulan çakışma sayısının artması nedeniyle çoğaltma performansını etkiler.
Çakışma çözümleme bölgesi
Azure Cosmos DB hesabı birden çok bölgeli yazma işlemleriyle yapılandırıldığında, bölgelerden biri yazma çakışmalarında bir arbiter görevi görür.
Çok bölgeli yazma işlemleri için en iyi yöntemler
Birden çok bölgeye yazarken göz önünde bulundurmanız gereken bazı en iyi yöntemler aşağıdadır.
Yerel trafiği yerel tutma
Birden çok bölgeli yazma işlemleri kullandığınızda uygulama, yerel bölgeden kaynaklanan okuma ve yazma trafiğini kesinlikle yerel Cosmos DB bölgesine vermelidir. En iyi performans için bölgeler arası çağrılardan kaçının.
Uygulamanın aşağıdaki kötü modellerden kaçınarak çakışmaları en aza indirmesi önemlidir:
Hızlı yanıt süresi alma olasılığını artırmak için tüm bölgelere aynı yazma işlemini gönderme
İstek başına okuma veya yazma işlemi için hedef bölgeyi rastgele belirleme
İstek başına okuma veya yazma işleminin hedef bölgesini belirlemek için hepsini bir kez deneme ilkesi kullanma.
Çoğaltma gecikmesi bağımlılığından kaçının
Çok bölgeli yazma hesaplarını güçlü tutarlılık için yapılandıramazsınız. Yazılmakta olan bölge, Azure Cosmos DB verileri yerel olarak çoğaltırken verileri zaman uyumsuz olarak genel olarak çoğaltdıktan hemen sonra yanıt verir.
Seyrek olsa da, verileri coğrafi olarak çoğaltırken bir veya birkaç bölümde çoğaltma gecikmesi oluşabilir. Çoğaltma gecikmesi, ağ trafiğinde nadir görülen bir blip veya normalden yüksek çakışma çözümü oranları nedeniyle oluşabilir.
Örneğin, uygulamanın A Bölgesine yazdığı ancak B Bölgesinden okuduğu bir mimari, iki bölge arasındaki çoğaltma gecikmesine bağımlılık sağlar. Ancak, uygulama aynı bölgeyi okur ve yazarsa, çoğaltma gecikmesi durumunda bile performans sabit kalır.
Yazma işlemleri için oturum tutarlılığı kullanımını değerlendirme
Oturum tutarlılığında, hem okuma hem de yazma işlemleri için oturum belirtecini kullanırsınız.
Okuma işlemleri için Azure Cosmos DB, önbelleğe alınan oturum belirtecini, belirtilen (veya daha yeni) oturum belirtecine karşılık gelen verileri alma garantisiyle sunucuya gönderir.
Yazma işlemleri için Azure Cosmos DB, oturum belirtecini veritabanına yalnızca sunucu sağlanan oturum belirtecini yakaladığında verileri kalıcı hale getirmek için garanti ile gönderir. Tek bölgeli yazma hesaplarında, yazma bölgesinin her zaman oturum belirtecine yetişmiş olması garanti edilir. Ancak, birden çok bölgeli yazma hesaplarında, yazdığınız bölge başka bir bölgeye verilen yazma işlemlerine yetişmiş olmayabilir. İstemci B Bölgesinden bir oturum belirteci ile A Bölgesine yazarsa, Bölge A, B Bölgesinde yapılan değişiklikleri yakalayana kadar verileri kalıcı hale getiremez.
Oturum belirteçlerini istemci örnekleri arasında geçirirken yazma işlemleri için değil, yalnızca okuma işlemleri için kullanmak en iyisidir.
Aynı belgede yapılan hızlı güncelleştirmeleri azaltma
Çakışmaların yokluğunu çözmek veya onaylamak için sunucunun güncelleştirmeleri, aynı belge tekrar tekrar güncelleştirildiğinde uygulama tarafından tetiklenen yazma işlemleriyle çakılabilir. Aynı belgeye hızla art arda yapılan yinelenen güncelleştirmeler, çakışma çözümü sırasında daha yüksek gecikme süreleri yaşar.
Aynı belgede yinelenen güncelleştirmelerde zaman zaman ani artışlar kaçınılmaz olsa da, sabit durum trafiği uzun bir süre boyunca aynı belgede hızlı güncelleştirmeler görüyorsa, bunun yerine yeni belgelerin oluşturulduğu bir mimariyi keşfetmeyi düşünebilirsiniz.
Okuma ve yazma kesintileri
Tek bölgeli hesapların istemcileri, hizmet geri yüklenene kadar okuma ve yazma kullanılabilirliği kaybıyla karşılaşır.
Birden çok bölgeli hesaplar, aşağıdaki yapılandırmalara ve kesinti türlerine bağlı olarak farklı davranışlarla karşılaşır.
| Konfigürasyon | Kesinti | Kullanılabilirlik etkisi | Dayanıklılık etkisi | Yapılması gerekenler |
|---|---|---|---|---|
| Tek yazma bölgesi | Okuma bölgesi kesintisi | Tüm istemciler okumaları otomatik olarak diğer bölgelere yönlendirir. Tüm yapılandırmalarda okuma veya yazma kullanılabilirliği kaybı olmaz. Özel durum, güçlü tutarlılığı olan ve hizmetin geri yüklenmesine kadar yazma kullanılabilirliğini kaybeden iki bölgenin yapılandırmasıdır. Hizmet tarafından yönetilen yük devretmeyi etkinleştirirseniz, hizmet bölgeyi başarısız olarak işaretler ve yük devretme gerçekleşir. | Veri kaybı yok. | Kesinti sırasında, kalan bölgelerde okuma trafiğini desteklemek için yeterli sağlanan İstek Birimi (RU) olduğundan emin olun. Kesinti sona erdiğinde, sağlanan RU'ları uygun şekilde yeniden ayarlayın. |
| Tek yazma bölgesi | Bölge kesintisi yazma | İstemciler okumaları diğer bölgelere yeniden yönlendirir. Hizmet tarafından yönetilen yük devretme olmadan istemciler yazma kullanılabilirliği kaybıyla karşılaşır. Kesinti sona erdiğinde yazma kullanılabilirliğinin geri yüklenmesi otomatik olarak gerçekleşir. Hizmet tarafından yönetilen yük devretme ile, hizmet seçtiğiniz yeni bir yazma bölgesine yük devretmeyi yönetene kadar istemciler yazma kullanılabilirliği kaybıyla karşılaşır. |
Güçlü tutarlılık düzeyini seçmezseniz hizmet bazı verileri kalan etkin bölgelere çoğaltmayabilir. Bu çoğaltma, seçtiğiniz tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, kurtarılmamış verileri kaybedebilirsiniz. | Kesinti sırasında, kalan bölgelerde okuma trafiğini desteklemek için yeterli sağlanan RU olduğundan emin olun. Kesinti sırasında el ile yük devretme tetiklemeyin , çünkü başarılı olamaz. Kesinti sona erdiğinde, sağlanan RU'ları uygun şekilde yeniden ayarlayın. NoSQL için API'yi kullanan hesaplar da çakışma akışınızdan başarısız olan bölgedeki kurtarılmamış verileri kurtarabilir. |
| Birden çok yazma bölgesi | Bölgesel kesintiler | Hizmet tarafından yönetilen yük devretme ile tek bir yazma bölgesine benzer olan geçici yazma kullanılabilirliği kaybı olasılığı vardır. Çakışma çözümleme bölgesinin yük devretmesi, kesinti sırasında çok sayıda çakışan yazma işlemi gerçekleştiğinde yazma kullanılabilirliği kaybına da neden olabilir. | Seçilen tutarlılık düzeyine bağlı olarak, başarısız bölgedeki son güncelleştirilen veriler kalan etkin bölgelerde kullanılamayabilir. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, yapılandırılmamış verileri kaybedebilirsiniz. | Kesinti sırasında, daha fazla trafiği desteklemek için kalan bölgelerde sağlanan RU'ların yeterli olduğundan emin olun. Kesinti sona erdiğinde, sağlanan RU'ları uygun şekilde yeniden ayarlayabilirsiniz. Mümkünse, Azure Cosmos DB başarısız bölgedeki kurtarılmamış verileri otomatik olarak kurtarır. Bu otomatik kurtarma, NoSQL için API kullanan hesaplar için yapılandırdığınız çakışma çözümleme yöntemini kullanır. Diğer API'leri kullanan hesaplar için bu otomatik kurtarma son yazma kazançlarını kullanır. |
Okuma bölgesi kesintileri hakkında ek bilgi
Etkilenen bölgenin bağlantısı kesildi ve çevrimdışı olarak işaretlendi. Azure Cosmos DB SDK'ları , okuma çağrılarını tercih edilen bölge listesinde bir sonraki kullanılabilir bölgeye yönlendirir.
Tercih edilen bölge listesindeki bölgelerin hiçbiri kullanılamıyorsa, çağrılar otomatik olarak geçerli yazma bölgesine geri döner.
Okuma bölgesi kesintilerini işlemek için uygulama kodunuzda değişiklik yapılması gerekmez. Etkilenen okuma bölgesi yeniden çevrimiçi olduğunda, geçerli yazma bölgesiyle eşitlenir ve tam olarak yakalandıktan sonra okuma isteklerini sunmak için yeniden kullanılabilir.
Sonraki okumalar kurtarılan bölgeye yönlendirilir ve bunun için uygulamanızın kodunda değişiklik yapılması gerekmez. Azure Cosmos DB, hem yük devretme hem de daha önce başarısız olan bir bölgeye yeniden katılma sırasında okuma tutarlılığı garantilerini karşılamaya devam eder.
Azure yazma bölgesinin kalıcı olarak geri alınamaz olduğu nadir ve talihsiz bir durumda bile, çok bölgeli Azure Cosmos DB hesabınız güçlü tutarlılık ile yapılandırıldıysa veri kaybı olmaz. Çok bölgeli bir Azure Cosmos DB hesabı, Dayanıklılık bölümünde daha önce belirtilen dayanıklılık özelliklerine sahiptir.
Yazma bölgesi kesintileri hakkında ek bilgi
Yazma bölgesi kesintisi sırasında Azure Cosmos DB hesabı, Azure Cosmos DB hesabında hizmet tarafından yönetilen yük devretme yapılandırıldığında ikincil bölgeyi yeni birincil yazma bölgesi olarak yükselter. Yük devretme, belirttiğiniz bölge önceliği sırasına göre başka bir bölgeye gerçekleşir.
El ile yük devretme tetiklenmemelidir ve kaynak veya hedef bölgede kesinti olması halinde başarılı olmaz. Bunun nedeni, yük devretme yordamının bölgeler arasında bağlantı gerektiren bir tutarlılık denetimi içermesidir.
Daha önce etkilenen bölge yeniden çevrimiçi olduğunda, bölge başarısız olduğunda çoğaltılan tüm yazma verileri çakışma akışı aracılığıyla kullanılabilir hale getirilir. Uygulamalar çakışma akışını okuyabilir, uygulamaya özgü mantığa göre çakışmaları çözebilir ve güncelleştirilmiş verileri uygun şekilde Azure Cosmos DB kapsayıcısına geri yazabilir.
Daha önce etkilenen yazma bölgesi kurtarıldıktan sonra Azure portalında "çevrimiçi" olarak gösterilir ve okuma bölgesi olarak kullanılabilir hale gelir. Bu noktada[PowerShell, Azure CLI veya Azure portal](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account kullanarak kurtarılan bölgeye yazma bölgesi olarak geri dönmek güvenlidir. Yazma bölgesini değiştirmeden önce veya değiştirdikten sonra veri veya kullanılabilirlik kaybı olmaz. Uygulamanız yüksek oranda kullanılabilir olmaya devam ediyor.
Uyarı
Azure Cosmos DB hesabının hizmet tarafından yönetilen yük devretme yoluyla ikincil bölgeyi yeni birincil yazma bölgesi olarak yükselttiği yazma bölgesi kesintisi durumunda, özgün yazma bölgesi kurtarıldıktan sonra otomatik olarak yazma bölgesi olarak yükseltilmeyecektir. PowerShell, Azure CLI veya Azure portalını kullanarak (yukarıda açıklandığı gibi güvenli bir şekilde) yazma bölgesi olarak kurtarılan bölgeye geri dönmek sizin sorumluluğunuzdadır.
Kesinti algılama, bildirim ve yönetim
Tek bölgeli hesaplar için istemciler, Azure Cosmos DB bölge kesintisi sırasında okuma ve yazma kullanılabilirliği kaybıyla karşılaşır. Birden çok bölgeli hesaplar, aşağıdaki tabloda açıklandığı gibi farklı davranışlarla karşılaşır.
| Yazma bölgeleri | Hizmet tarafından yönetilen yük devretme | Ne beklenmeli | Yapılması gerekenler |
|---|---|---|---|
| Tek yazma bölgesi | Etkin değil | Güçlü tutarlılık kullanmadığınız bir okuma bölgesinde kesinti olursa, tüm istemciler diğer bölgelere yönlendirilir. Okuma veya yazma kullanılabilirliği kaybı ve veri kaybı yoktur. Güçlü tutarlılık kullandığınızda, ikiden az okuma bölgesinin kalması durumunda okuma bölgesindeki bir kesinti yazma kullanılabilirliğini etkileyebilir. Yazma bölgesinde bir kesinti varsa, istemciler yazma kullanılabilirliği kaybıyla karşılaşır. Güçlü tutarlılık seçmediyseniz, hizmet bazı verileri kalan etkin bölgelere çoğaltmayabilir. Bu çoğaltma, seçilen tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, yapılandırılmamış verileri kaybedebilirsiniz. Azure Cosmos DB, kesinti sona erdiğinde yazma kullanılabilirliğini geri yükler. |
Kesinti sırasında, kalan bölgelerde okuma trafiğini desteklemek için yeterli sağlanan RU olduğundan emin olun. Kesinti sırasında el ile yük devretme tetiklemeyin , çünkü başarılı olamaz. Kesinti sona erdiğinde, sağlanan RU'ları uygun şekilde yeniden ayarlayın. |
| Tek yazma bölgesi | Etkinleştirildi | Güçlü tutarlılık kullanmadığınız bir okuma bölgesinde kesinti olursa, tüm istemciler diğer bölgelere yönlendirilir. Okuma veya yazma kullanılabilirliği kaybı ve veri kaybı yoktur. Güçlü tutarlılık kullandığınızda, ikiden az okuma bölgesi kalırsa okuma bölgesinin kesintisi yazma kullanılabilirliğini etkileyebilir. Yazma bölgesinde bir kesinti varsa, Azure Cosmos DB tercihlerinize göre yeni yazma bölgesi olarak yeni bir bölge seçene kadar istemciler yazma kullanılabilirliği kaybıyla karşılaşır. Güçlü tutarlılık seçmediyseniz, hizmet bazı verileri kalan etkin bölgelere çoğaltmayabilir. Bu çoğaltma, seçilen tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, yapılandırılmamış verileri kaybedebilirsiniz. |
Kesinti sırasında, kalan bölgelerde okuma trafiğini desteklemek için yeterli sağlanan RU olduğundan emin olun. Kesinti sırasında el ile yük devretme tetiklemeyin , çünkü başarılı olamaz. Kesinti sona erdiğinde, yazma bölgesini özgün bölgeye geri taşıyabilir ve sağlanan RU'ları uygun şekilde yeniden ayarlayabilirsiniz. NoSQL için API'yi kullanan hesaplar, çakışma akışınızdan başarısız olan bölgedeki kurtarılmamış verileri de kurtarabilir. |
| Birden çok yazma bölgesi | Uygulanamaz | Başarısız bölgedeki son güncelleştirilen veriler kalan etkin bölgelerde kullanılamayabilir. Nihai, tutarlı ön ek ve oturum tutarlılığı düzeyleri 15 dakikadan kısa bir eskime süresi garanti eder. Sınırlanmış eskime durumu, yapılandırmaya bağlı olarak K güncelleştirmelerinden veya T saniyeden daha azını garanti eder. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, yapılandırılmamış verileri kaybedebilirsiniz. | Kesinti sırasında, daha fazla trafiği desteklemek için kalan bölgelerde sağlanan RU'ların yeterli olduğundan emin olun. Kesinti sona erdiğinde, sağlanan RU'ları uygun şekilde yeniden ayarlayabilirsiniz. Mümkünse, Azure Cosmos DB başarısız bölgedeki kurtarılmamış verileri kurtarır. Bu kurtarma, NoSQL için API kullanan hesaplar için yapılandırdığınız çakışma çözümleme yöntemini kullanır. Diğer API'leri kullanan hesaplar için bu kurtarma son yazma kazançlarını kullanır. |
Yüksek kullanılabilirlik için test etme
Azure Cosmos DB hesabınız yüksek oranda kullanılabilir olsa bile, uygulamanız yüksek oranda kullanılabilir kalacak şekilde doğru tasarlanmamış olabilir. Uygulama test veya olağanüstü durum kurtarma (DR) tatbikatlarınızın bir parçası olarak uygulamanızın uçtan uca yüksek kullanılabilirliğini test etmek için, hesap için hizmet tarafından yönetilen yük devretmeyi geçici olarak devre dışı bırakın. PowerShell, Azure CLI veya Azure portalını kullanarak el ile yük devretmeyi çağırın ve uygulamanızı izleyin. Testi tamamladıktan sonra birincil bölgeye yeniden yük devredebilir ve hesap için hizmet tarafından yönetilen yük devretmeyi geri yükleyebilirsiniz.
Önemli
Kaynak veya hedef bölgede Azure Cosmos DB kesintisi sırasında el ile yük devretmeyi çağırmayın. El ile yük devretme, veri tutarlılığını korumak için bölge bağlantısı gerektirir, bu nedenle başarılı olmaz.