Yüksek oranda kullanılabilir uygulamalar tasarlamak için coğrafi artıklığı kullanın

Azure Depolama gibi bulut tabanlı altyapılardan oluşan ortak bir özellik, verileri ve uygulamaları barındırmak için yüksek düzeyde kullanılabilir ve dayanıklı bir platform sağlamalarına yöneliktir. Bulut tabanlı uygulamaların geliştiricileri, kullanıcıları için bu avantajları en üst düzeye çıkarmak üzere bu platformun nasıl kullanıldığını dikkatle düşünmelidir. Azure Depolama, bölgesel bir kesinti durumunda bile yüksek kullanılabilirlik sağlamak için coğrafi olarak yedekli depolama sağlar. coğrafi olarak yedekli çoğaltma için yapılandırılan Depolama hesapları, birincil bölgede zaman uyumlu olarak çoğaltılır ve sonra yüzlerce mil olan ikincil bir bölgeye zaman uyumsuz olarak çoğaltılır.

Azure Depolama, coğrafi olarak yedekli çoğaltma için iki seçenek sunar. Bu iki seçenek arasındaki tek fark, verilerin birincil bölgede nasıl çoğaltıladır:

• Coğrafi bölge yedekli depolama (GZRS): veriler, bölgesel olarak yedekli depolama (ZRS) kullanılarak birincil bölgedeki üç Azure kullanılabilirlik alanı arasında zaman uyumlu olarak çoğaltılır ve ardından zaman uyumsuz olarak ikincil bölgeye çoğaltılır. İkincil bölgedeki verilere yönelik okuma erişimi için, Okuma Erişimli Coğrafi bölge yedekli depolamayı (RA-GZRS) etkinleştirin.

  Microsoft, en yüksek kullanılabilirlik ve dayanıklılık gerektiren senaryolar için GZRS/RA-GZRS kullanılmasını önerir.

• Coğrafi olarak yedekli depolama (GRS): veriler yerel olarak yedekli depolama (LRS) kullanılarak birincil bölgede eşzamanlı olarak üç kez çoğaltılır ve ardından zaman uyumsuz olarak ikincil bölgeye çoğaltılır. İkincil bölgedeki verilere yönelik okuma erişimi için Okuma Erişimli Coğrafi olarak yedekli depolamayı (RA-GRS) etkinleştirin.

Bu makalede, uygulamanızı birincil bölgedeki bir kesinti işleyecek şekilde nasıl tasarlayacağız. Birincil bölge kullanılamaz duruma gelirse, uygulamanız bunun yerine ikincil bölgeye karşı okuma işlemleri gerçekleştirmeye uyarlayabilir. Başlamadan önce depolama hesabınızın RA-GRS veya RA-GZRS için yapılandırıldığından emin olun.

İkincil sunucudan okurken uygulama tasarımında dikkat edilmesi gerekenler

Bu makalenin amacı, birincil veri merkezinde önemli bir olağanüstü durum oluşması durumunda bile çalışmaya devam edecek bir uygulamayı (sınırlı bir kapasiteye göre) nasıl tasarlayacağınızı gösterir. Birincil bölgeden okumayı kesintiye uğratan bir sorun olduğunda, ikincil bölgeden okuma yaparak, geçici veya uzun süreli sorunları işleyecek şekilde uygulamanızı tasarlayabilirsiniz. Birincil bölge yeniden kullanılabilir olduğunda, uygulamanız birincil bölgeden okuma 'ya dönebilir.

Uygulamanızı RA-GRS veya RA-GZRS için tasarlarken bu önemli noktaları aklınızda bulundurun:

• Azure Depolama, birincil bölgenizde depoladığınız verilerin salt okunurdur bir kopyasını bir ikincil bölgede tutar. Yukarıda belirtildiği gibi, depolama hizmeti ikincil bölgenin konumunu belirler.

• Salt okuma kopyası sonunda birincil bölgedeki verilerle tutarlıdır .

• Bloblar, tablolar ve kuyruklar için ikincil bölgeyi, birincil sunucudan ikincil bölgeye yapılan son çoğaltmanın ne zaman oluştuğunu bildiren bir son eşitleme zamanı değeri için sorgulayabilirsiniz. (Bu, şu anda RA-GRS yedekliği olmayan Azure dosyaları için desteklenmez.)

• birincil veya ikincil bölgede veri okumak ve yazmak için Depolama istemci kitaplığını kullanabilirsiniz. Ayrıca, birincil bölgeye yönelik okuma isteği zaman aşımına uğrarsa okuma isteklerini otomatik olarak ikincil bölgeye yönlendirebilirsiniz.

• Birincil bölge kullanılamaz duruma gelirse, hesap yük devretmesini başlatabilirsiniz. İkincil bölgeye yük devretmek için, birincil bölgeye işaret eden DNS girdileri, ikincil bölgeyi gösterecek şekilde değiştirilir. Yük devretme işlemi tamamlandıktan sonra, GRS ve RA-GRS hesapları için yazma erişimi geri yüklenir. Daha fazla bilgi için bkz. olağanüstü durum kurtarma ve depolama hesabı yük devretme.

Sonuçta tutarlı verileri kullanma

Önerilen çözüm, olası eski verileri çağıran uygulamaya döndürmek için kabul edilebilir olduğunu varsayar. İkincil bölgedeki veriler sonunda tutarlı olduğundan, İkincil bölgedeki bir güncelleştirmenin çoğaltma işlemi tamamlanmadan önce birincil bölge erişilemez hale gelebilir.

Örneğin, müşterinizin bir güncelleştirmeyi başarıyla gönderdiğini varsayalım, ancak güncelleştirme ikincil bölgeye yayılmadan önce birincil bölge başarısız olur. Müşteri verileri geri okumayı istediğinde, güncelleştirilmiş veriler yerine ikincil bölgeden eski verileri alırlar. Uygulamanızı tasarlarken, bu kabul edilebilir olup olmadığına ve varsa müşteriyi nasıl mesaj vereceğinize karar vermelisiniz.

Bu makalenin ilerleyen kısımlarında, ikincil veriler için son eşitleme zamanının, ikincinin güncel olup olmadığını kontrol etmek için nasıl kontrol eteceğiz.

Hizmetleri ayrı ayrı veya birlikte işleme

Büyük olasılıkla, diğer hizmetler hala tamamen işlevsel olduğu sürece bir hizmetin kullanılamaz hale gelmesi mümkündür. Her hizmet için yeniden denemeler ve salt okuma modunu ayrı ayrı (blob 'lar, kuyruklar, tablolar) işleyebilir veya tüm depolama hizmetleri için yeniden denemeleri idare edebilirsiniz.

Örneğin, uygulamanızda kuyruklar ve Bloblar kullanıyorsanız, bunların her biri için yeniden denenebilir hataları işlemek üzere ayrı bir kod koymaya karar verebilirsiniz. Daha sonra blob hizmetinden yeniden deneme yaparsanız, ancak kuyruk hizmeti hala çalışıyorsa, yalnızca uygulamanızın Blobları işleyen kısmı etkilenecektir. Tüm depolama hizmeti yeniden denemeleri genel olarak işlemeye karar verirseniz ve BLOB hizmeti çağrısı yeniden denenebilir bir hata döndürürse, hem blob hizmetine hem de kuyruk hizmetine yönelik istekler etkilenecektir.

Sonuçta bu, uygulamanızın karmaşıklığına bağlıdır. Sorunları hizmet 'e göre işleyememeye karar verebilir, ancak tüm depolama hizmetleri için okuma isteklerini ikincil bölgeye yeniden yönlendirmek ve birincil bölgedeki herhangi bir depolama hizmetiyle ilgili bir sorun tespit ettiğinizde uygulamayı salt okuma modunda çalıştırmak isteyebilirsiniz.

Diğer önemli noktalar

Bunlar, bu makalenin geri kalanında tartıştığımız diğer önemli noktalardır.

• Devre kesici modelini kullanarak okuma isteklerinin yeniden denemelerini işleme

• Sonuçta tutarlı veriler ve son eşitleme zamanı

• Test Etme

Uygulamanızı salt okuma modunda çalıştırma

Birincil bölgedeki bir kesinti için etkin bir şekilde hazırlanması için, hem başarısız okuma isteklerini hem de başarısız güncelleştirme isteklerini işleyebilmelisiniz (Bu durumda, bu örnekte bu durum, güncelleştirmeler ve silinmeler). Birincil bölge başarısız olursa, okuma istekleri ikincil bölgeye yeniden yönlendirilebilir. Ancak, ikincil salt okunurdur, güncelleştirme istekleri ikinciye yeniden yönlendirilemiyor. Bu nedenle, uygulamanızı salt okuma modunda çalışacak şekilde tasarlamanız gerekir.

örneğin, Azure Depolama hiçbir güncelleştirme isteği gönderilmeden önce denetlenen bir bayrak ayarlayabilirsiniz. Güncelleştirme isteklerinden biri aracılığıyla geldiğinde, bunu atlayabilir ve müşteriye uygun bir yanıt döndürebilirsiniz. Sorun çözümlenene kadar belirli özellikleri devre dışı bırakmak ve kullanıcılara bu özelliklerin geçici olarak kullanılamadığını bildirmek isteyebilirsiniz.

Her hizmet için hataları ayrı olarak işlemeye karar verirseniz, uygulamanızı hizmet tarafından salt okuma modunda çalıştırma özelliğini de gerçekleştirmeniz gerekir. Örneğin, etkinleştirilebilen ve devre dışı bırakılabilirler her hizmet için salt okuma bayraklarınız olabilir. Daha sonra, bu bayrağı kodunuzda uygun yerlerde işleyebilirsiniz.

Uygulamanızı salt okuma modunda çalıştırmak, bir yandan büyük bir uygulama yükseltmesi sırasında sınırlı işlevsellik sağlama olanağı sunar. Uygulamanızı salt okuma modunda çalışacak şekilde tetikleyip ikincil veri merkezini işaret ederken, yükseltme yaparken birincil bölgedeki verilere hiç kimsenin erişemeyeceğinden emin olabilirsiniz.

Salt okuma modunda çalışırken güncelleştirmeleri işleme

Salt okuma modunda çalışırken güncelleştirme isteklerini işlemenin birçok yolu vardır. Bu kavrama kapsamlı bir şekilde ele alınmayacağız, ancak genellikle göz önünde bulundurmanız gereken birkaç desen vardır.

• Kullanıcıya yanıt verebilir ve şu anda güncelleştirmeleri kabul etmelerinizi söyleyebilirsiniz. Örneğin, bir iletişim yönetimi sistemi müşterilerin iletişim bilgilerine erişmesini sağlayabilir, ancak güncelleştirme yapamaz.

• Güncelleştirmelerinizi başka bir bölgede sıraya alabilirsiniz. Bu durumda, bekleyen güncelleştirme isteklerinizi farklı bir bölgedeki bir kuyruğa yazar ve ardından birincil veri merkezi yeniden çevrimiçi olduktan sonra bu istekleri işlemek için bir yola sahip olursunuz. Bu senaryoda, müşterinin, istenen güncelleştirmenin daha sonra işlenmek üzere kuyruğa alındığından emin olmanız gerekir.

• Güncelleştirmelerinizi, başka bir bölgedeki bir depolama hesabına yazabilirsiniz. Ardından, birincil veri merkezi yeniden çevrimiçi olduğunda, verilerin yapısına bağlı olarak, bu güncelleştirmeleri birincil verilerle birleştirmenin bir yolu olabilir. Örneğin, adında bir tarih/saat damgasıyla ayrı dosyalar oluşturuyorsanız, bu dosyaları birincil bölgeye geri kopyalayabilirsiniz. Bu, günlüğe kaydetme ve IoT verileri gibi bazı iş yükleri için geçerlidir.

Yeniden denemeleri işleme

Azure Depolama istemci kitaplığı, hangi hataların yeniden denenebileceği belirlemenize yardımcı olur. Örneğin, bir 404 hatası (kaynak bulunamadı) yeniden denenmeyecek ve bu durum başarılı bir şekilde sonuçlandığı için yeniden denenmez. Diğer taraftan, bir 500 hatası sunucu hatası olduğundan yeniden denenebilir ve sorun yalnızca geçici bir sorun olabilir. Daha fazla ayrıntı için .NET depolama istemci kitaplığındaki üs Alretry sınıfına yönelik açık kaynak kodunu inceleyin. (ShouldRetry yöntemini arayın.)

Okuma istekleri

Birincil depolamayla ilgili bir sorun varsa okuma istekleri ikincil depolamaya yönlendirilebilir. En sonunda tutarlı verileri kullanmabölümünde belirtildiği gibi, uygulamanızın eski verileri okuyabilmesi için kabul edilebilir olması gerekir. İkincili verilere erişmek için depolama istemci kitaplığını kullanıyorsanız, Locationmode özelliği için bir değer ayarlayarak aşağıdakilerden birine bir okuma isteğinin yeniden deneme davranışını belirtebilirsiniz:

• Yalnızca Primary( varsayılan)

• PrimaryThenSecondary

• Yalnızca Secondary

• SecondaryThenPrimary

Locationmode öğesini primarythensecondary olarak belirlediğinizde, birincil uç noktaya ilk okuma isteği yeniden denenebilecek bir hata vererek başarısız olursa istemci, ikincil uç noktaya otomatik olarak başka bir okuma isteği oluşturur. Hata bir sunucu zaman aşımı ise, istemci, hizmetten yeniden denenebilir bir hata vermeden önce zaman aşımı süresinin dolmasını beklemek zorunda kalır.

Yeniden denenebilir bir hataya nasıl yanıt vereceğinize karar verirken dikkate alınması gereken temel olarak iki senaryo vardır:

• Bu yalıtılmış bir sorundur ve birincil uç noktaya yapılan sonraki istekler yeniden denenebilir bir hata döndürmez. Bunun gerçekleşebileceği bir örnek, geçici bir ağ hatası olduğunda gerçekleşir.

  Bu senaryoda, yalnızca seyrek olduğu için Locationmode 'U primarythensecondary olarak ayarlanmış önemli bir performans cezası yoktur.

• Bu, birincil bölgedeki depolama hizmetlerinden en az birinde ve birincil bölgedeki bu hizmete yapılan tüm sonraki isteklerin bir süre için yeniden denenebilir hata döndürmesine neden olabilir. Bunun bir örneği, birincil bölgenin tamamen erişilemez olması durumunda oluşur.

  Bu senaryoda, tüm okuma istekleriniz önce birincil uç noktayı deneyip zaman aşımının dolmasını bekleyeceği ve ardından ikincil uç noktasına geçecek olduğu için bir performans cezası vardır.

Bu senaryolarda, birincil uç noktayla ilgili devam eden bir sorun olduğunu belirlemeli ve LocationMode özelliğini SecondaryOnly olarak ayarerek tüm okuma isteklerini doğrudan ikincil uç noktasına gönderebilirsiniz. Şu anda uygulamayı salt okunur modda çalıştıracak şekilde de değiştirebilirsiniz. Bu yaklaşım Devre Kesici Düzeni olarak bilinir.

İstekleri güncelleştirme

Bağlantı Hattı Kesici düzeni, güncelleştirme isteklerine de uygulanabilir. Ancak güncelleştirme istekleri salt okunur olan ikincil depolama alanına yönlendirilememektedir. Bu istekler için LocationMode özelliğini PrimaryOnly (varsayılan) olarak ayarlanmış şekilde bırakmanız gerekir. Bu hataları işlemek için bu isteklere bir ölçüm (satırda 10 hata gibi) uygulayabilir ve eşiğiniz karşı geldiğinde uygulamayı salt okunur moda dönüştürebilirsiniz. Devre Kesici düzeni hakkında bir sonraki bölümde açıklananlar ile aynı yöntemleri kullanarak güncelleştirme moduna dönebilirsiniz.

Devre Kesici düzeni

Uygulamanıza Devre Kesici desenini kullanmak, bunun tekrar tekrar başarısız olma olasılığı olan bir işlemi yeniden denemesini önlenebilir. İşlem üstel olarak yeniden denenirken zaman almak yerine uygulamanın çalışmaya devam eder. Ayrıca hatanın ne zaman düzeltilmiştir, bu sırada uygulamanın işlemi yeniden deneye çalışa olduğunu algılar.

Devre kesici desenini uygulama

Birincil uç noktayla ilgili devam eden bir sorun olduğunu belirlemek için istemcinin ne sıklıkta yeniden denenebilir hatalarla karşılaştığını izleyebilirsiniz. Her durum farklı olduğundan, ikincil uç noktasına geçiş yapmak ve uygulamayı salt okunur modda çalıştırmak için kullanmak istediğiniz eşiğe karar vermelidir. Örneğin, bir satırda başarılı bir şekilde 10 hata olursa anahtarı gerçekleştirmeye karar velisiniz. Bir diğer örnek de isteklerin %90'lık bir süre içinde başarısız olmasıdır.

İlk senaryo için yalnızca hataların sayısını tutarak maksimum sayıya ulaşmadan önce başarılı olması durumunda s sayımı sıfır olarak ayarlayın. İkinci senaryo için, bunu uygulamanın bir yolu MemoryCache nesnesini kullanmaktır (.NET'te). Her istek için önbelleğe bir CacheItem ekleyin, değeri başarılı (1) veya başarısız (0) olarak ayarlayın ve sona erme süresini 2 dakika (veya zaman kısıtlamanız ne olursa olsun) olarak ayarlayın. Bir girişin sona erme tarihine ulaşılırsa, giriş otomatik olarak kaldırılır. Bu size 2 dakikalık bir zaman penceresi sağlar. Depolama hizmetine her istekte bulunuyorken öncelikle MemoryCache nesnesi genelinde bir Linq sorgusu kullanarak değerleri toplar ve sayıya bölerek başarı yüzdelerini hesaplarsınız. Yüzde başarı oranı bir eşiğin altına düştüğünde (%10 gibi) okuma istekleri için LocationMode özelliğini SecondaryOnly olarak ayarlayın ve devam etmeden önce uygulamayı salt okunur moda geçin.

Anahtarın ne zaman kullanılmaya devam etmek gerektiğini belirlemek için kullanılan hataların eşiği, uygulamanıza hizmetten hizmete değişiklik gösterebilir, bu nedenle bunları yapılandırılabilir parametreler olarak düşünebilirsiniz. Burada, daha önce de belirtildiği gibi her hizmetten ayrı veya bir tane olarak yeniden denenebilir hataları işlemeye karar verirsiniz.

Bir diğer önemli nokta da bir uygulamanın birden çok örneğini işleme ve her örnekte yeniden denenebilir hatalar algılasanız ne yapmaları olduğudur. Örneğin, aynı uygulama yüklü olarak çalışan 20 VM'ler olabilir. Her örneği ayrı ayrı mı işleyebilirsiniz? Bir örnekte sorun olursa yanıtı yalnızca bu örnekle sınırlamak mı yoksa bir örnekte sorun olduğunda tüm örneklerin aynı şekilde yanıt vermesini mi denemek istiyorsunuz? Örnekleri ayrı ayrı işleme, yanıtın eşgüdüme almaya çalışmadan çok daha basittir, ancak bunu nasıl yapacaksınız, uygulamanın mimarisine bağlıdır.

Hata sıklığını izleme seçenekleri

İkincil bölgeye ne zaman geçiş yapmak ve uygulamayı salt okunur modda çalıştıracak şekilde değiştirmek için birincil bölgedeki yeniden deneme sıklığını izlemek için üç ana seçeneğiniz vardır.

• Depolama isteklerinize geçiş ettiğiniz OperationContext nesnesinde Yeniden Deneme olayı için bir işleyici ekleyin; bu, bu makalede görüntülenen ve eşlik eden örnekte kullanılan yöntemdir. bu olaylar, istemci bir isteği yeniden her yeniden denemesi sırasında, istemcinin birincil uç noktada ne sıklıkta yeniden denenebilir hatalarla karşılaştığını izlemenizi sağlar.

  • .NET v12 SDK
  • .NET v11 SDK

  Şu anda Azure Depolama istemci kitaplıklarının 12.x sürümünü yansıtan kod parçacıkları oluşturmak için çalışıyoruz. Daha fazla bilgi için bkz. Azure Depolama v12 İstemci Kitaplıkları.

• Özel bir yeniden deneme ilkesinde Evaluate yönteminde, yeniden deneme her olduğunda özel kod çalıştırabilirsiniz. Bu size yeniden deneme davranışınızı değiştirme fırsatı da verir.

  • .NET v12 SDK
  • .NET v11 SDK

  Şu anda Azure Depolama istemci kitaplıklarının 12.x sürümünü yansıtan kod parçacıkları oluşturmak için çalışıyoruz. Daha fazla bilgi için bkz. Azure Depolama v12 İstemci Kitaplıkları.

• Üçüncü yaklaşım, uygulamanıza, sistem durumunu belirlemek için birincil depolama uç noktanıza sahte okuma istekleriyle (küçük bir blobu okuma gibi) sürekli ping atan özel bir izleme bileşeni uygulamaktır. Bu bazı kaynakları alır ancak önemli bir miktar değildir. Eşiğinize ulaşan bir sorun keşfedilse secondaryOnly ve salt okunur moda geçişini gerçekleştirebilirsiniz.

Bir noktada, birincil uç noktayı kullanmaya ve güncelleştirmelere izin vermeye geri dönmek istemeyebilirsiniz. Yukarıda listelenen ilk iki yöntemden birini kullanıyorsanız, rastgele seçilen bir süre veya işlem sayısı gerçekleştirildikten sonra birincil uç noktasına geri dönüp güncelleştirme modunu etkinleştirebilirsiniz. Ardından yeniden deneme mantığını yeniden ekleyebilirsiniz. Sorun düzeltildi ise birincil uç noktayı kullanmaya ve güncelleştirmelere izin vermeye devam eder. Sorun devam ediyorsa, ayarlıyorsanız, ayarlıyorsanız başarısız olduktan sonra ikincil uç nokta ve salt okunur moda bir kez daha geri döner.

Üçüncü senaryo için, birincil depolama uç noktasına ping işlemi yeniden başarılı olursa, PrimaryOnly'ye geçişini tetikler ve güncelleştirmelere izin vermeye devam edersiniz.

Nihai tutarlı verileri işleme

Coğrafi olarak yedekli depolama, işlemleri birincil bölgeden ikincil bölgeye çoğaltarak çalışır. Bu çoğaltma işlemi, ikincil bölgedeki verilerin sonunda tutarlı olduğunu garantiler. Bu, birincil bölgedeki tüm işlemlerin sonunda ikincil bölgede görünecek olduğu, ancak görünmeden önce bir gecikmenin olduğu ve işlemlerin ikincil bölgeye ilk olarak birincil bölgede uygulandığı sırayla ulaşacakları garantinin olmadığını gösterir. İşlemleriniz ikincil bölgeye sırasıyla geliyorsa, hizmet yakalanıncaya kadar ikincil bölgedeki verilerinizin tutarsız durumda olduğunu düşünebilirsiniz.

Aşağıdaki tabloda, bir çalışanın ayrıntılarını güncelleştirin ve bunları yöneticiler rolünün bir üyesi yapın. Bu örnek için çalışan varlığını güncelleştirmeniz ve yönetici rolü varlığını toplam yönetici sayısıyla güncelleştirmeniz gerekir. Güncelleştirmelerin ikincil bölgede sırayla nasıl uygulandığına dikkat edin.

Bu örnekte, istemci, T5 adresindeki ikincil bölgeden okuma yapmak için anahtar olduğunu varsayalım. Şu anda yönetici rolü varlığını başarıyla okuyabilir, ancak varlık, ikincil bölgede şu anda yönetici olarak işaretlenen çalışan varlık sayısıyla tutarlı olmayan yönetici sayısı için bir değer içerir. İstemciniz bu değeri, tutarsız bilgiler olması riskiyle tek bir şekilde görüntüleyebilir. Alternatif olarak, istemci, güncelleştirmeler sıralı olmadığından ve kullanıcıyı bu olguyu bilgilendirdiğinden, yönetici rolünün potansiyel olarak tutarsız bir durumda olduğunu belirlemeyi deneyebilir.

İstemci potansiyel olarak tutarsız veriler olduğunu tanımak için, bir depolama hizmetini sorgulayarak istediğiniz zaman alabileceğiniz son eşitleme zamanının değerini kullanabilir. Bu, İkincil bölgedeki verilerin en son tutarlı olduğu ve hizmetin bu noktadan önce tüm işlemleri uyguladığı zamanı gösterir. Yukarıdaki örnekte, hizmet çalışan varlığı ikincil bölgeye eklendikten sonra, son eşitleme zamanı T1 olarak ayarlanır. Hizmet, T6 olarak ayarlandığında, İkincil bölgedeki çalışan varlığını güncelleştirene kadar T1 konumunda kalır. İstemci T5 adresinde varlığı okurken son eşitleme saatini alıyorsa, varlığı varlığındaki zaman damgasıyla karşılaştırabilir. Varlıktaki zaman damgası son eşitleme zamanından daha sonra ise, varlık potansiyel olarak tutarsız bir durumda olur ve uygulamanız için uygun eylemi gerçekleştirebilirsiniz. Bu alanın kullanılması için son birincil güncelleştirmenin ne zaman tamamlandığını bilmeniz gerekir.

Son eşitleme zamanını nasıl denetleyeceğinizi öğrenmek için bkz. depolama hesabı Için Son eşitleme zamanı özelliğini denetleme.

Test Etme

Yeniden denenebilir hata ile karşılaştığında uygulamanızın beklendiği gibi davrandığını test etmek önemlidir. Örneğin, bir sorun algıladığında uygulamanın ikinciye ve salt okuma moduna geçiş yapması ve birincil bölge yeniden kullanılabilir olduğunda geri geçiş yapmanız gerekir. Bunu yapmak için yeniden denenebilir hata benzetimi yapmak ve ne sıklıkta gerçekleştikleri denetlemek için bir yol gerekir.

Bir betikteki HTTP yanıtlarını kesme ve değiştirme için Fiddler kullanabilirsiniz. bu betik, birincil uç noktanıza gelen yanıtları tanımlayabilir ve HTTP durum kodunu Depolama istemci kitaplığının yeniden denenebilir hatası olarak tanıyacağı bir şekilde değiştirebilirsiniz. Bu kod parçacığı, 502 durumunu döndürmek için employeedata tablosuna yönelik okuma isteklerine yapılan yanıtları Izleyen bir Fiddler betiğinin basit bir örneğini gösterir:

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[yourstorageaccount\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

Sonraki adımlar

Anahtarın birincil ve ikincil uç noktalar arasında geri ve ileri nasıl yapılacağını gösteren tam bir örnek için, bkz. Azure örnekleri – RA-GRS depolama Ile devre kesici modelini kullanma.