Aracılığıyla paylaş

PostgreSQL için Azure Veritabanı'nda coğrafi çoğaltma

Okuma amaçlı çoğaltma, birincil sunucuyla aynı bölgede veya farklı bir coğrafi bölgede oluşturulabilir. Coğrafi çoğaltma, olağanüstü durum kurtarma planlaması veya verileri kullanıcılarınıza yaklaştırma gibi senaryolar için yararlı olabilir.

PostgreSQL için Azure Veritabanı esnek sunucu hizmeti bölgesinde birincil sunucunuz olabilir. Ana sunucunun, PostgreSQL için Azure Veritabanı esnek sunucu örneklerini destekleyen herhangi bir genel Azure bölgesinde çoğaltmaları da olabilir. Ayrıca, 21Vianet tarafından sağlanan özel bölgeleri Azure Kamu ve Microsoft Azure'ı da destekliyoruz.

Olağanüstü durum kurtarma amacıyla eşleştirilmiş bölgeler

Desteklenen herhangi bir bölgede çoğaltma oluşturmak mümkün olsa da, özellikle olağanüstü durum kurtarma amacıyla mimari oluştururken, eşleştirilmiş bölgelerde çoğaltmaları seçmenin önemli avantajları vardır:

  • Bölge Kurtarma Sırası: Coğrafya genelindeki bir kesintide, eşleştirilmiş her kümeden bir bölgenin kurtarılması önceliklendirilir ve eşleştirilmiş bölgelerdeki uygulamaların kurtarma için her zaman hızlandırılmış bir bölgeye sahip olmasını sağlar.

  • Sıralı Güncelleştirme: Eşleştirilmiş bölgelerin güncelleştirmeleri kronolojik olarak kademelenir ve güncelleştirmeyle ilgili sorunlardan kaynaklanan kapalı kalma süresi riskini en aza indirir.

  • Fiziksel Yalıtım: Eşleştirilmiş bölgelerdeki veri merkezleri arasında en az 300 mil mesafe korunarak önemli olaylardan eşzamanlı kesinti riskini azaltır.

  • Veri Yerleşimi: Birkaç özel durumla, eşleştirilmiş kümedeki bölgeler aynı coğrafyada yer alır ve veri yerleşimi gereksinimlerini karşılar.

  • Performans: Eşleştirilmiş bölgeler genellikle düşük ağ gecikme süresi sunar ve veri erişilebilirliğini ve kullanıcı deneyimini geliştirirken, her zaman mutlak en düşük gecikme süresine sahip bölgeler olmayabilir. Birincil hedef, olağanüstü durum kurtarmayı önceliklendirmek yerine verileri kullanıcılara daha yakın bir şekilde sunmaksa, kullanılabilir tüm bölgelerin gecikme süresi açısından değerlendirilmesi çok önemlidir. Bazı durumlarda, eşlenmemiş bir bölge en düşük gecikme süresini gösterebilir. Kapsamlı bir anlayış için, bilinçli bir seçim yapmak için Azure'ın gidiş dönüş gecikmesi rakamlarına başvurabilirsiniz.

Eşleştirilmiş bölgelerin avantajlarını daha iyi anlamak için Azure'ın bölgeler arası çoğaltma belgelerine bakın.

Bölgesel Hatalar ve Kurtarma

Çeşitli bölgelerdeki Azure tesisleri son derece güvenilir olacak şekilde tasarlanmıştır. Ancak nadir durumlarda, ağ arızalarından doğal afetler gibi ciddi senaryolara kadar birçok nedenden dolayı bölgenin tamamına erişilemez hale gelebilir. Azure'ın özellikleri birden çok bölgeye dağıtılmış uygulamalar oluşturulmasına olanak tanıyarak bir bölgedeki bir hatanın diğerlerini etkilememesini sağlar.

Bölgesel Afetlere Hazırlanma

Olası bölgesel afetlere karşı hazırlıklı olmak, uygulamalarınızın ve hizmetlerinizin kesintisiz çalışmasını sağlamak için kritik öneme sahiptir. PostgreSQL için Azure Veritabanı esnek sunucu örneğiniz için güçlü bir acil durum planı düşünüyorsanız, önemli adımlar ve dikkat edilmesi gerekenler şunlardır:

  1. Coğrafi olarak çoğaltılmış bir okuma çoğaltması oluşturma: Okuma amaçlı çoğaltmanın birincil bölgenizden ayrı bir bölgede ayarlanması önemlidir. Bu, birincil bölgenin kesintiyle karşı karşıya olması durumunda sürekliliği sağlar.
  2. Sunucu simetrisini güvence altına alma: Bölgesel kesintileri işlemek için en çok önerilen "birincil sunucuya yükselt" eylemidir, ancak bir sunucu simetri gereksinimiyle birlikte gelir. Bu, hem birincil hem de çoğaltma sunucularının belirli ayarların aynı yapılandırmalarına sahip olması gerektiği anlamına gelir. Bu eylemi kullanmanın avantajları şunlardır:
    • Sanal uç noktaları kullanıyorsanız uygulama bağlantı dizesi değiştirmeniz gerekmez.
    • Etkilenen bölge yeniden çevrimiçi olduktan sonra özgün birincil sunucunun işlevini otomatik olarak sürdürdüğü ancak yeni bir çoğaltma rolüne sahip olduğu sorunsuz bir kurtarma işlemi sağlar.
  3. Sanal uç noktaları ayarlama: Sanal uç noktalar, kesinti olması durumunda uygulamanızın başka bir bölgeye sorunsuz bir şekilde geçişini sağlar. Uygulamanızın bağlantı dizesi değişiklik gereksinimini ortadan kaldırır.
  4. Okuma amaçlı çoğaltmayı yapılandırma: Birincil sunucudaki tüm ayarlar okuma amaçlı çoğaltmaya çoğaltılmaz. Tüm gerekli yapılandırmaların ve özelliklerin (örneğin, PgBouncer) okuma çoğaltmanızda uygun şekilde ayarlandığından emin olmak çok önemlidir. Daha fazla bilgi için Yapılandırma yönetimi bölümüne bakın.
  5. Yüksek Kullanılabilirlik (HA) için hazırlanma: Kurulumunuz yüksek kullanılabilirlik gerektiriyorsa, yükseltilen çoğaltmada otomatik olarak etkinleştirilmez. Yükseltme sonrasında etkinleştirmeye hazır olun. Kapalı kalma süresini en aza indirmek için bu adımı otomatikleştirmeyi göz önünde bulundurun.
  6. Düzenli test: Mevcut eşikleri, hedefleri ve yapılandırmaları doğrulamak için düzenli olarak bölgesel olağanüstü durum senaryolarının simülasyonunu yapma. Uygulamanızın bu test senaryoları sırasında beklendiği gibi yanıt verdiğine emin olun.
  7. Azure'ın genel yönergelerini izleyin: Azure güvenilirlik ve olağanüstü durumlara hazırlıklı olma konusunda kapsamlı yönergeler sağlar. Bu kaynaklara danışmak ve en iyi yöntemleri hazırlık planınızla tümleştirmek son derece faydalıdır.

Proaktif olmak ve bölgesel afetlere önceden hazırlanmak, uygulamalarınızın ve verilerinizin dayanıklılığını ve güvenilirliğini güvence altına alır.

Kesintiler SLA'nızı etkilediğinde

Uygulamanızın hizmet düzeyi sözleşmesini (SLA) tehdit eden belirli bir bölgedeki PostgreSQL için Azure Veritabanı esnek sunucu örneğinde uzun süreli bir kesinti yaşanırsa, aşağıda açıklanan her iki eylemin de hizmet temelli olmadığını unutmayın. Her ikisi için de kullanıcı müdahalesi gerekir. Sürecin tamamını mümkün olduğunca otomatikleştirmek ve sağlam bir izleme sağlamak en iyi yöntemdir. Kesinti sırasında hangi bilgilerin sağlandığı hakkında daha fazla bilgi için Hizmet kesintisi sayfasına bakın. Bir bölge azaltma senaryosunda yalnızca zorlamalı yükseltme mümkündür; bu da veri kaybı miktarının çoğaltma ile birincil arasındaki geçerli gecikmeye kabaca eşit olduğu anlamına gelir. Bu nedenle gecikmeyi izlemek çok önemlidir. Aşağıdaki adımları göz önünde bulundurun:

Birincil sunucuya yükseltme

Bu seçenek, sanal uç noktaların yapılandırılması koşuluyla uygulamanızdaki bağlantı dizesi güncelleştirilmesini gerektirmez. Etkinleştirildikten sonra, yazıcı uç noktası farklı bir bölgedeki yeni birincile yeniden yönlendirir ve Azure portalındaki çoğaltma durumu sütununda "Yeniden Yapılandırma" görüntülenir. Etkilenen bölge geri yüklendikten sonra, eski birincil sunucu otomatik olarak devam eder, ancak şimdi bir çoğaltma rolündedir.

Bağımsız sunucuya yükseltme ve çoğaltmadan kaldırma

Bu durumda, tek uygulanabilir seçenek budur. Sunucuyu tanıtdıktan sonra uygulamanızın bağlantı dizesi güncelleştirmeniz gerekir. Özgün bölge geri yüklendikten sonra eski birincil bölge yeniden etkin hale gelebilir. Gereksiz maliyetlerle karşılaşmamak için kaldırdığınızdan emin olun. Önceki topolojiyi korumak istiyorsanız okuma amaçlı çoğaltmayı yeniden oluşturun.

İlgili içerik

  • Last updated on