Azure Cosmos DB ile yüksek kullanılabilirlik elde edin
ŞUNLAR IÇIN GEÇERLIDIR:
Nosql MongoDB Cassandra Gremlin Tablo
Yüksek kullanılabilirliğe sahip bir çözüm oluşturmak için tüm bileşenlerinin güvenilirlik özelliklerini değerlendirmeniz gerekir. Azure Cosmos DB, çözümünüz için yüksek kullanılabilirlik elde etmeye yardımcı olacak özellikler ve yapılandırma seçenekleri sağlar.
Bu makalede aşağıdaki terimler kullanılır:
- Kurtarma süresi hedefi (RTO):Azure Cosmos DB'yi etkileyen bir kesintinin başlangıcı ile tam kullanılabilirliğe kurtarma arasındaki süre.
- Kurtarma noktası hedefi (RPO):Doğru şekilde geri yüklenen son yazma ile Azure Cosmos DB'yi etkileyen kesintinin başlangıcı arasındaki süre.
Not
Beklenen ve maksimum GPO'lar ve GPO'lar, Azure Cosmos DB'nin yaşadığı kesinti türüne bağlıdır. Örneğin, tek bir düğümde kesinti olması beklenen RTO ve RPO'dan tüm bölgenin kesintisinden farklıdır.
Bu makalede Azure Cosmos DB kullanılabilirliğini etkileyebilecek olaylar ve ilgili Azure Cosmos DB yapılandırma seçenekleri ayrıntılı olarak açıklanmaktadır.
Çoğaltma bakımı
Azure Cosmos DB, tek tek işlem düğümlerinin tüm ayrıntılarını şeffaf bir şekilde yöneten çok kiracılı bir hizmettir. Kullanıcıların herhangi bir düzeltme eki uygulama veya planlı bakım konusunda endişelenmeleri 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.
Çoğaltma kesintileri
Çoğaltma kesintileri , azure bölgesinde dağıtılan bir Azure Cosmos DB kümesindeki tek tek düğümlerde oluşan kesintilerdir.
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ırmalarına gerek kalmadan tek tek düğüm kesintileri için 0 RTO ve 0 RPO'ya neden olur.
Birçok Azure bölgesinde Azure Cosmos DB kümenizi kullanılabilirlik alanları arasında dağıtmak mümkündür. Kullanılabilirlik alanları, fiziksel olarak ayrı olduklarından ve ayrı bir güç kaynağı, ağ ve soğutma sağladığından SLA'ları artırabilir. Kullanılabilirlik alanlarını kullanarak bir Azure Cosmos DB hesabı dağıttığınızda Azure Cosmos DB, bölge kesintilerinde bile 0 RTO ve 0 RPO sağlar.
Fazladan kullanıcı girişi olmadan tek bir Azure bölgesinde dağıtım yaptığınızda, Azure Cosmos DB düğüm kesintilerine karşı dayanıklıdır. Kullanılabilirlik alanları arasında yedekliliği etkinleştirmek, Azure Cosmos DB'nin artan ücretler karşılığında bölge kesintilerine karşı dayanıklı olmasını sağlar.
Bölge yedekliliğini yalnızca Azure Cosmos DB hesabına yeni bir bölge eklerken yapılandırabilirsiniz. Mevcut bölgeler için, bölgeyi kaldırıp bölge yedekliliği etkinleştirilerek yeniden ekleyerek bölge yedekliliğini etkinleştirebilirsiniz. Tek bölgeli bir hesap için, bu yaklaşım geçici olarak yük devretmek için bir bölge eklemenizi ve ardından bölge yedekliliği etkinleştirilmiş olarak istenen bölgeyi kaldırıp eklemenizi gerektirir.
Varsayılan olarak Azure Cosmos DB hesabı birden çok kullanılabilirlik alanı kullanmaz. Birden çok kullanılabilirlik alanında dağıtımı aşağıdaki yollarla etkinleştirebilirsiniz:
Azure Cosmos DB hesabınız N Azure bölgesine dağıtılmışsa tüm verilerinizin N x 4 kopyası olur. Azure Cosmos DB'nin her bölgedeki verileri çoğaltması hakkında daha fazla bilgi için bkz. Azure Cosmos DB ile genel dağıtım. İkiden fazla bölgede Azure Cosmos DB hesabına sahip olmak, uygulamanızın kullanılabilirliğini artırır ve ilişkili bölgelerde düşük gecikme süresi sağlar.
Bölge kesintileri
Bölge kesintileri , tüm kullanılabilirlik alanlarında bir Azure bölgesindeki 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.
Dayanıklılık
Azure Cosmos DB hesabı tek bir bölgede dağıtıldığında genellikle veri kaybı olmaz. Etkilenen bölgede Azure Cosmos DB hizmetleri 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 felaket felaketlere neden olabilecek 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.
- 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 tam olarak yedekler. En düşük yedekleme aralığı 1 saattir.
Azure Cosmos DB hesabı birden çok bölgede dağıtıldığında, veri dayanıklılığı hesapta yapılandırdığınız tutarlılık düzeyine bağlıdır. Aşağıdaki tabloda tüm tutarlılık düzeyleri için en az iki bölgede dağıtılan Azure Cosmos DB hesabının RPO'sunun ayrıntıları yer alır.
| Tutarlılık düzeyi | Bölge kesintisi için RPO |
|---|---|
| Oturum, tutarlı ön ek, nihai | 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.
Kullanılabilirlik
Çözümünüz bölge kesintileri sırasında sürekli kullanılabilirlik gerektiriyorsa Azure Cosmos DB'yi verilerinizi birden çok bölgede çoğaltacak ve gerektiğinde kullanılabilir bölgelere saydam bir şekilde yük devredecek şekilde yapılandırabilirsiniz.
Tek bölgeli hesaplar bölgesel bir kesintiden sonra kullanılabilirliğini kaybedebilir. Her zaman yüksek kullanılabilirlik sağlamak için Azure Cosmos DB hesabınızı tek bir yazma bölgesi ve en az bir saniyelik (okuma) bir 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, veri kaybı maliyeti karşılığında kullanılabilirliği korumak için çok bölgeli bir hesabın yazma bölgesinde yük devretme gerçekleştirmesine olanak tanır. Bölgesel yük devretme işlemleri Azure Cosmos DB istemcisinde algılanıp işlenir. Bunlar, uygulamadan herhangi bir değişiklik gerektirmez. Birden çok okuma bölgesini ve hizmet tarafından yönetilen yük devretmeyi etkinleştirme yönergeleri için bkz. Azure portal kullanarak Azure Cosmos DB hesabını yönetme.
Önemli
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ı kullanılabilir bölgelere otomatik olarak yük devretmesini sağlar.
Bu yapılandırmanın olmaması durumunda hesap, yazma bölgesi kesintisinin süresi boyunca yazma kullanılabilirliği kaybıyla karşılaşır. El ile yük devretme, bölge bağlantısı olmadığı için başarılı olmayacaktır.
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 gecikmesini 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
İç Azure Cosmos DB mimarisi nedeniyle, birden çok yazma bölgesi kullanmak, bölge kesintisi sırasında yazma kullanılabilirliğini garanti etmez. Bölge kesintisi sırasında yüksek kullanılabilirlik elde etmek için en iyi yapılandırma, hizmet tarafından yönetilen yük devretmeye sahip tek bir yazma bölgesidir.
Ç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. Bu tür çakışmalar gerçekleştiğinde tutarlı bir çözüm için bu bölgeye yönlendirilirler.
Ç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 tut
Birden çok bölgeli yazmaları 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
Okuma veya yazma işleminin hedef bölgesini istek temelinde belirlemek için hepsini bir kez deneme ilkesi kullanma
Çoğaltma gecikmesi bağımlılığından kaçının
Güçlü tutarlılık için birden çok bölgeli yazma hesapları yapılandıramazsınız. Yazılmakta olan bölge, Azure Cosmos DB verileri yerel olarak çoğaltırken verileri genel olarak zaman uyumsuz olarak çoğaltdıktan hemen sonra yanıt verir.
Seyrek olmasına rağmen, 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ınmış 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 gönderir ve verilerin kalıcı olması için sunucunun sağlanan oturum belirtecini yakalaması gerekir. 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, A Bölgesi B Bölgesinde yapılan değişikliklere yetişene 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ı belgedeki 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ızlı bir şekilde 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.
Bölge kesintisi sırasında bekleyebileceğinizler
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.
| Yapılandırma | Kesinti | Kullanılabilirlik etkisi | Dayanıklılık etkisi | Ne yapılmalı |
|---|---|---|---|---|
| Tek yazma bölgesi | Bölge kesintisi okuma | Tüm istemciler okumaları otomatik olarak diğer bölgelere yönlendirir. Tüm yapılandırmalar için okuma veya yazma kullanılabilirliği kaybı olmaz. Özel durum, hizmetin geri yüklenmesine kadar yazma kullanılabilirliğini kaybeden güçlü tutarlılığı olan iki bölgenin yapılandırmasıdır. Veya 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 yazma kesintisi | İstemciler okumaları diğer bölgelere 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 devretmeyi 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 fazla sayıda çakışan yazma gerçekleşirse 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ştirilmiş veriler kalan etkin bölgelerde kullanılamayabilir. Etkilenen bölge kalıcı veri kaybı yaşarsa, kurtarı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 olan 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ı otomatik olarak kesilir ve çevrimdışı olarak işaretlenir. 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 otomatik olarak eşitlenir ve okuma isteklerine hizmet vermek 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 olayda bile, çok bölgeli Azure Cosmos DB hesabınız güçlü tutarlılık ile yapılandırılmışsa 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.
Bölge yazma kesintileri hakkında ek bilgi
Yazma bölgesi kesintisi sırasında Azure Cosmos DB hesabında otomatik (hizmet tarafından yönetilen) yük devretme yapılandırıldığında Azure Cosmos DB hesabı otomatik olarak 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, çakışmaları uygulamaya özgü mantığa göre çö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, otomatik olarak okuma bölgesi olarak kullanılabilir hale gelir. PowerShell, Azure CLI veya Azure portal kullanarak kurtarılan bölgeye yazma bölgesi olarak geri dönebilirsiniz. Yazma bölgesini değiştirmeden önce, bu sırada veya sonrasında veri veya kullanılabilirlik kaybı olmaz . Uygulamanız yüksek oranda kullanılabilir olmaya devam ediyor.
SLA’lar
Aşağıdaki tabloda çeşitli hesap yapılandırmalarının yüksek kullanılabilirlik özellikleri özetlemektedir.
| 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, tek 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.
Yüksek oranda kullanılabilir uygulamalar oluşturmaya yönelik ipuçları
Olaylar sırasında Azure Cosmos DB SDK'larının beklenen davranışını ve bunu etkileyen yapılandırmaları gözden geçirin.
Yüksek yazma ve okuma kullanılabilirliği sağlamak için Azure Cosmos DB hesabınızı en az iki bölgeye (veya güçlü tutarlılık kullanıyorsanız üç bölgeye) yayılacak şekilde yapılandırın. Bölge kesintisi için yüksek kullanılabilirlik elde etmek için en iyi yapılandırmanın, hizmet tarafından yönetilen yük devretmeye sahip tek bir yazma bölgesi olduğunu unutmayın. Daha fazla bilgi edinmek için bkz . Öğretici: NoSQL api'sini kullanarak Azure Cosmos DB genel dağıtımını ayarlama.
Tek bir yazma bölgesiyle yapılandırılan birden çok bölgeli Azure Cosmos DB hesapları için Azure CLI veya Azure portal kullanarak hizmet tarafından yönetilen yük devretmeyi etkinleştirin. Hizmet tarafından yönetilen yük devretmeyi etkinleştirdikten sonra, bölgesel bir olağanüstü durum olduğunda Azure Cosmos DB kullanıcı girişi olmadan hesabınıza yük devredecektir.
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 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.
Genel olarak dağıtılmış bir veritabanı ortamında, bölge genelinde kesinti olması halinde tutarlılık düzeyi ile veri dayanıklılığı arasında doğrudan bir ilişki vardır. İş sürekliliği planınızı geliştirirken, uygulama kesintiye neden olan bir olaydan (RTO) sonra tamamen kurtarılmadan önce kabul edilebilir en uzun süreyi anlamanız gerekir. Ayrıca, kesintiye neden olan bir olaydan (RPO) sonra kurtarılırken uygulamanın kaybetmeye dayanabileceği en son veri güncelleştirmeleri süresini de anlamanız gerekir. RTO ve RPO hakkında daha fazla bilgi için bkz. Azure Cosmos DB'de tutarlılık düzeyleri.
Azure Cosmos DB bölge kesintisi sırasında bekleyebileceğinizler
Tek bölgeli hesaplarda istemciler, Azure Cosmos DB bölgesi 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.
| Bölgeleri yazma | Hizmet tarafından yönetilen yük devretme | Beklentiler | Ne yapılmalı |
|---|---|---|---|
| Tek yazma bölgesi | Etkin değil | Güçlü tutarlılık kullanmadığınızda okuma bölgesinde bir 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ö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, desteklenmeyen verileri kaybedebilirsiniz. Azure Cosmos DB, kesinti sona erdiğinde yazma kullanılabilirliğini otomatik olarak 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 bittiğinde sağlanan RU'ları uygun şekilde yeniden ayarlayın. |
| Tek yazma bölgesi | Etkin | Güçlü tutarlılık kullanmadığınızda okuma bölgesinde bir 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 olursa, Azure Cosmos DB tercihlerinize göre yeni yazma bölgesi olarak otomatik 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, desteklenmeyen 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 da çakışma akışınızdan başarısız bölgedeki kurtarılmamış verileri 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, desteklenmeyen verileri kaybedebilirsiniz. | Kesinti sırasında, diğer bölgelerde daha fazla trafiği desteklemek için yeterli sayıda sağlanan RU 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'yi 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. |
Sonraki adımlar
Ardından, aşağıdaki makaleleri okuyabilirsiniz: