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, tüm çözümlerin kullanılabilirlik gereksinimleri için yüksek kullanılabilirlik elde etmek üzere birden çok özellik ve yapılandırma seçeneği sağlamak üzere tasarlanmıştır.
Azure Cosmos DB'yi etkileyen bir kesintinin başlangıcı ile tam kullanılabilirliğe kurtarma arasındaki süreyi belirtmek için RTO (Kurtarma Süresi Hedefi) ve son doğru geri yükleme ile Azure Cosmos DB'yi etkileyen kesintinin başlangıcı arasındaki süreyi belirtmek için RPO (Kurtarma Noktası Hedefi) terimlerini kullanacağız.
Not
Beklenen ve en yüksek RPO'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'nun tüm bölge kesintisinden farklı olmasıdır.
Bu makalede, çözümünüzün gerektirdiği kullanılabilirlik özelliklerini elde etmek için 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, yönetilen çok kiracılı bir hizmettir. Kullanıcıların herhangi bir düzeltme eki uygulama ve planlı bakım konusunda endişelenmeleri gerekmez. Azure Cosmos DB, sistem tarafından gerçekleştirilen tüm otomatik bakım işlemleri aracılığıyla kullanılabilirlik ve P99 gecikme süresi için SLA'ları garanti eder.
Garantili kullanılabilirlik SLA'ları için SLA'lar bölümüne bakın.
Çoğaltma kesintileri
Çoğaltma kesintileri, bir Azure bölgesinde dağıtılan bir Azure Cosmos DB kümesindeki tek tek düğümlerin kesintilerine işaret eder. Azure Cosmos DB, dört çoğaltma çekirdeği içinde 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, uygulama değişikliği veya yapılandırma gerektirmeden tek tek düğüm kesintileri için RTO = 0 ve RPO = 0'a neden olur.
Birçok Azure bölgesinde Azure Cosmos DB kümenizi kullanılabilirlik alanları arasında dağıtmak mümkündür; bu da kullanılabilirlik alanları fiziksel olarak ayrı olduğundan ve ayrı güç kaynağı, ağ ve soğutma sağladığı için SLA'ların artmasına neden olur. bkz. Kullanılabilirlik Alanları. Azure Cosmos DB hesabı kullanılabilirlik alanları kullanılarak dağıtıldığında, Azure Cosmos DB bir bölge kesintisinde bile RTO = 0 ve RPO = 0 sağlar.
Kullanıcılar fazladan kullanıcı girişi olmadan tek bir Azure bölgesinde dağıtım yaparken, 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. Hem SLA'lar hem de fiyat SLA'lar bölümünde raporlanmıştır.
Alanlar arası yedeklilik yalnızca Azure Cosmos DB hesabına yeni bölge eklenirken yapılandırılabilir. Mevcut bölgeler için bölge yedekliliği, bölge yedekliliği etkinleştirilerek etkinleştirilebilir. Tek bir bölge hesabı için bunun için geçici olarak yük devredecek bir bölge eklenmesi, ardından bölge yedekliliği etkinleştirilmiş istenen bölgenin kaldırılması ve eklenmesi gerekir.
Azure Cosmos DB hesabı varsayılan olarak 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ölgeleri arasında dağıtılmışsa tüm verilerinizin N x 4 kopyası olur. Veri dağıtımına daha ayrıntılı bir genel bakış için bkz. Arka planda genel veri dağıtımı. 2'den 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.
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.
Bölge kesintileri
Bölge kesintileri, tüm kullanılabilirlik alanları genelinde bir Azure bölgesindeki tüm Azure Cosmos DB düğümlerini etkileyen kesintilere işaret eder. Nadir görülen bölge kesintilerinde, Azure Cosmos DB çeşitli dayanıklılık ve kullanılabilirlik sonuçlarını destekleyecek şekilde yapılandırılabilir.
Dayanıklılık
Azure Cosmos DB hesabı tek bir bölgede dağıtıldığında genellikle veri kaybı olmaz ve 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 felaketlerden kaynaklanabilecek tam veri kaybına karşı koruma sağlamak için 2 farklı yedekleme modu sağlar:
- Sürekli yedeklemeler , yedeklemenin her bölgede her 100 saniyede bir alınmasını sağlar ve ikinci ayrıntı düzeyiyle verilerinizi istenen herhangi bir noktaya geri yükleme olanağı sağlar. Her bölgede yedekleme, o bölgede işlenen verilere bağımlı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ümlerin tam yedeklemelerini alır. 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ırılan tutarlılık düzeyine bağlıdır. Aşağıdaki tabloda tüm tutarlılık düzeyleri için Azure Cosmos DB hesabının RPO'sunun en az 2 bölgede dağıtıldı olması gerekir.
|Tutarlılık düzeyi||Bölge kesintisi durumunda RPO|
|Oturum, Tutarlı Ön Ek, Son||< 15 dakika|
|Sınırlanmış Eskime Durumu||Kahraman&T|
|Güçlü||0|
K = Bir öğenin "K" sürümlerinin (güncelleştirmeler) sayısı.
T = Son güncelleştirmeden bu yana "T" zaman aralığı.
Çok bölgeli hesaplarda en düşük K ve T değeri 100.000 yazma işlemi veya 300 saniyedir. Bu, Sınırlanmış Eskime Durumu kullanılı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 Tutarlılık düzeyleri'ne bakın.
Kullanılabilirlik
Çözümünüz bölge kesintileri sırasında sürekli kullanılabilirlik gerektiriyorsa Azure Cosmos DB, verilerinizi birden çok bölgede çoğaltacak ve gerektiğinde kullanılabilir bölgelere saydam bir şekilde yük devredecek şekilde yapılandırılabilir.
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) bölgeyle ayarlamanız veHizmet Tarafından Yönetilen yük devretmeyi etkinleştirmeniz önerilir.
Hizmet tarafından yönetilen yük devretme, Dayanıklılık bölümüne göre veri kaybı maliyetiyle kullanılabilirliği korumak için Azure Cosmos DB'nin çok bölgeli 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. Uygulamadan herhangi bir değişiklik yapılmasını gerektirmezler. Birden çok okuma bölgesini ve hizmet tarafından yönetilen yük devretmeyi etkinleştirme yönergeleri için Bkz. 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 önerilir. Bu, Azure Cosmos DB'nin hesap veritabanlarının kullanılabilir bölgelere otomatik olarak yük devretmesini sağlar. Bu yapılandırma olmadığında, el ile yük devretme bölge bağlantısı olmaması nedeniyle başarılı olmadığından, hesap yazma bölgesi kesintisinin tüm süresi boyunca yazma kullanılabilirliği kaybıyla karşılaşır.
Birden çok yazma bölgesi
Azure Cosmos DB, birden çok bölgede yazmaları kabul etmek üzere yapılandırılabilir. Bu, coğrafi olarak dağıtılmış uygulamalarda yazma gecikme süresini azaltmak için kullanışlıdır. Azure Cosmos DB hesabı birden çok yazma bölgesi için yapılandırıldığında güçlü tutarlılık desteklenmez ve yazma çakışmaları ortaya çıkabilir. Birden çok yazma bölgesi yapılandırmasındaki çakışmaları çözme hakkında daha fazla bilgi için Birden çok yazma bölgesi kullanırken çakışma türleri ve çözüm ilkeleri bölümüne bakın.
İç Azure Cosmos DB mimarisi göz önünde bulundurulduğunda, birden çok yazma bölgesinin kullanılması, 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 devretme ile tek yazma bölgesidir.
Çakışma çözümleme bölgesi
Azure Cosmos DB hesabı çok bölgeli yazma işlemleriyle yapılandırıldığında, bölgelerden biri yazma çakışmaları durumunda bir arbiter görevi görür. Bu tür çakışmalar gerçekleştiğinde, tutarlı çözüm için bu bölgeye yönlendirilirler.
Bölge kesintisi sırasında bekleyebileceğinizler
Tek bölgeli hesapların istemcisi, hizmet geri yüklenene kadar okuma ve yazma kullanılabilirliği kaybıyla karşılaşır.
Çok bölgeli hesaplar aşağıdaki tabloya 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. Hizmet geri yüklenene kadar yazma kullanılabilirliğini kaybeden güçlü tutarlılığa sahip 2 bölge dışında tüm yapılandırmalar için okuma veya yazma kullanılabilirliği kaybı olmaz veya hizmet tarafından yönetilen yük devretme etkinleştirildiğinde bölge başarısız olarak işaretlenir 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 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, kesinti sona erdiğinde yazma kullanılabilirliği otomatik olarak geri yüklenene kadar istemciler yazma kullanılabilirliği kaybıyla karşılaşır. Hizmet tarafından yönetilen yük devretme istemcileri, hizmetler tercihlerinize göre seçilen yeni bir yazma bölgesine yük devretmeyi yönetene kadar yazma kullanılabilirliği kaybıyla karşılaşır.||Güçlü tutarlılık düzeyi seçilmediyse, bazı veriler kalan etkin bölgelere çoğaltılmamış olabilir. Bu, bu bölümde açıklandığı gibi seçilen tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, kurtarılmamış veriler kaybolabilir.||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ı olmaz. Kesinti sona erdiğinde sağlanan RU'ları uygun şekilde yeniden ayarlayın. NoSQL'ler için API kullanan hesaplar, başarısız bölgedeki çoğaltılmamış verileri çakışma akışınızdan da kurtarabilir.|
|Birden çok yazma bölgesi||Bölgesel kesintiler||Hizmet tarafından yönetilen yük devretme ile tek yazma bölgesine benzer şekilde geçici yazma kullanılabilirliği kaybı olasılığı. Ç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, kurtarılmamış veriler kaybolabilir.||Kesinti sırasında, kalan bölgelerde ek trafiği desteklemek için yeterli 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, NoSQL hesapları için API için yapılandırılmış çakışma çözümleme yöntemini ve diğer API'leri kullanan hesaplar için Son Yazma Kazançlarını kullanarak başarısız bölgedeki çoğaltılmamış verileri otomatik olarak kurtarı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ılabilir durumda değilse çağrılar otomatik olarak geçerli yazma bölgesine döner.
Uygulama kodunuzda okuma bölgesi kesintisini işlemek için değişiklik 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. 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ığı garantileri Azure Cosmos DB tarafından kabul edilmeye devam eder.
Azure bölgesinin kalıcı olarak kurtarılamaz durumda 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ılmışsa veri kaybı olmaz. Kalıcı olarak kurtarılamayan bir yazma bölgesinin nadir olması durumunda, çok bölgeli bir Azure Cosmos DB hesabı Dayanıklılık bölümünde 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ükseltecektir. 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ı durumunda başarılı olmaz. Bunun nedeni, bölgeler arasında bağlantı gerektiren yük devretme yordamının gerektirdiği tutarlılık denetimidir.
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. Kurtarılan bölgeye yazma bölgesi olarak geri dönebilirsiniz. PowerShell, Azure CLI veya Azure portal kullanarak bölgeleri değiştirebilirsiniz. Yazma bölgesini değiştirmeden önce, sırasında veya sonrasında veri veya kullanılabilirlik kaybı olmaz ve uygulamanız yüksek oranda kullanılabilir olmaya devam eder.
SLA’lar
Aşağıdaki tabloda çeşitli hesap yapılandırmalarının yüksek kullanılabilirlik özelliği özetlemektedir:
|KPI||AZ'ler olmadan tek bölgeli||AZ'ler ile tek bölge||AZ olmadan çok bölgeli, tek bölgeli yazma işlemleri||AZ'ler ile çok bölgeli, tek bölgeli yazma işlemleri||AZ ile veya AZ olmadan ç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ı yok, geçici yazma kullanılabilirliği kaybı|
|Fiyat (1)||Yok||Sağlanan RU/sn x 1,25 oranı||Sağlanan RU/sn x n bölge||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 istek birimleri (RU) 1,25 faktörüyle çarpılır.
2 1,25 oranı yalnızca AZ'nin etkinleştirildiği bölgelere uygulanır.
Önemli
İç Azure Cosmos DB mimarisi göz önüne alındığında, birden çok yazma bölgesi kullanmak, bölge kesintisi sırasında yazma kullanılabilirliğini garanti etmez. Bölge kesintisi durumunda yüksek kullanılabilirlik elde etmek için en iyi yapılandırma, hizmet tarafından yönetilen yük devretme ile tek bir yazma bölgesidir.
Yüksek oranda kullanılabilir uygulamalar oluşturma
Bu 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ı, güçlü tutarlılık kullanıyorsanız en az iki bölgeye ve üç 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 devretme ile 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 yazma bölgesiyle yapılandırılmış ç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ızın yükünü 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. Uygulamanızın uçtan uca yüksek kullanılabilirliğini test etmek için, uygulama testi veya olağanüstü durum kurtarma (DR) tatbikatlarınızın bir parçası olarak 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 ardından uygulamanızın yük devretmesini izleyin. İşlem tamamlandı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ölgelerde Azure Cosmos DB kesintisi sırasında el ile yük devretmeyi çağırmayın çünkü veri tutarlılığını korumak için bölgeler bağlantısı gerektirir ve başarılı olmaz.
- Genel olarak dağıtılmış bir veritabanı ortamında tutarlılık düzeyi ile bölge genelinde kesinti olması halinde 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 sonra tamamen kurtarılmadan önce kabul edilebilir en uzun süreyi anlamanız gerekir. Bir uygulamanın tam olarak kurtarılması için gereken süre, kurtarma süresi hedefi (RTO) olarak bilinir. Ayrıca, kesintiye neden olan bir olaydan sonra kurtarılırken uygulamanın kaybetmeye dayanabileceği en son veri güncelleştirmeleri süresini de anlamanız gerekir. Kaybetmeyi göze alabileceğiniz güncelleştirme süresi kurtarma noktası hedefini (RPO) olarak bilinir. Azure Cosmos DB için RPO ve RTO'yu görmek için bkz . Tutarlılık düzeyleri ve veri dayanıklılığı
Azure Cosmos DB bölge kesintisi sırasında bekleyebileceğinizler
Tek bölgeli hesaplar için istemciler okuma ve yazma kullanılabilirliği kaybıyla karşılaşır.
Çok bölgeli hesaplar aşağıdaki tabloya bağlı olarak farklı davranışlarla karşılaşır.
|Bölgeleri yazma||Yük devretmeyi Service-Managed||Beklentiler||Ne yapılmalı|
|Tek yazma bölgesi||Etkin değil||Güçlü tutarlılık kullanmadığında okuma bölgesinde kesinti olması durumunda, tüm istemciler diğer bölgelere yönlendirilir. Okuma veya yazma kullanılabilirliği kaybı yok. Veri kaybı yok. Güçlü tutarlılık kullanılırken, ikiden az okuma bölgesi kaldıysa okuma bölgesi kesintisi yazma kullanılabilirliğini etkileyebilir. Yazma bölgesinde kesinti olması durumunda istemciler yazma kullanılabilirliği kaybıyla karşılaşır. Güçlü tutarlılık düzeyi seçilmediyse, bazı veriler kalan etkin bölgelere çoğaltılmamış olabilir. Bu, bu bölümde açıklandığı gibi seçilen tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, kurtarılmamış veriler kaybolabilir. 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 devretmeyi tetiklemeyin çünkü başarılı olmaz. Kesinti sona erdiğinde sağlanan RU'ları uygun şekilde yeniden ayarlayın.|
|Tek yazma bölgesi||Etkin||Güçlü tutarlılık kullanmadığında okuma bölgesinde kesinti olması durumunda, tüm istemciler diğer bölgelere yönlendirilir. Okuma veya yazma kullanılabilirliği kaybı yok. Veri kaybı yok. Güçlü tutarlılık kullanılırken, ikiden az okuma bölgesi kaldıysa okuma bölgesi kesintisi yazma kullanılabilirliğini etkileyebilir. Yazma bölgesinde kesinti olması durumunda, Azure Cosmos DB tercihlerinize göre yeni bir yazma bölgesi olarak otomatik olarak yeni bir bölge seçene kadar istemciler yazma kullanılabilirliği kaybı yaşar. Güçlü tutarlılık düzeyi seçilmediyse, bazı veriler kalan etkin bölgelere çoğaltılmamış olabilir. Bu, bu bölümde açıklandığı gibi seçilen tutarlılık düzeyine bağlıdır. Etkilenen bölgede kalıcı veri kaybı yaşanırsa, kurtarılmamış veriler kaybolabilir.||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ı olmaz. Kesinti sona erdiğinde, yazma bölgesini özgün bölgeye geri taşıyabilir ve sağlanan RU'ları uygun şekilde yeniden ayarlayabilirsiniz. NoSQL'ler için API kullanan hesaplar, başarısız bölgedeki çoğaltılmamış verileri çakışma akışınızdan da 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 dakika eskime durumunu <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, kurtarılmamış veriler kaybolabilir.||Kesinti sırasında, kalan bölgelerde ek trafiği desteklemek için yeterli 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, NoSQL hesapları için API için yapılandırılmış çakışma çözümleme yöntemini ve diğer API'leri kullanan hesaplar için Son Yazma Kazançlarını kullanarak başarısız bölgedeki çoğaltılmamış verileri otomatik olarak kurtarır.|
Sonraki adımlar
Daha sonra aşağıdaki makaleleri okuyabilirsiniz: