PostgreSQL için Azure Veritabanı'nda güvenilirlik

PostgreSQL için Azure Veri Tabanı, veritabanı yönetimi işlevleri ve yapılandırma ayarları üzerinde ayrıntılı denetim ve esneklik sağlayan tam olarak yönetilen bir veritabanı hizmetidir. Hizmet, gereksinimlerinize göre yüksek kullanılabilirlik ve olağanüstü durum kurtarma özellikleri sağlar.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı PostgreSQL için Azure Veri Tabanı nasıl dayanıklı hale getirilmeye başlandığı açıklanır. Ayrıca, diğer sorun türlerinden kurtarmak için yedeklemeleri nasıl kullanabileceğinizi açıklar ve PostgreSQL için Azure Veri Tabanı hizmet düzeyi sözleşmesi (SLA) hakkındaki önemli bilgileri vurgular.

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek üzere PostgreSQL için Azure Veri Tabanı dağıtmayı ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediğini öğrenmek için bkz. Azure Well-Architected Framework'te PostgreSQL için Azure Veri Tabanı için en iyi mimari yöntemleri.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

PostgreSQL için Azure Veri Tabanı ile çalışırken, sunucuya dağıttığınız veritabanlarını desteklemek için gereken işlem ve depolama kaynaklarını temsil eden bir sunucu dağıtırsınız.

Sunucuları birden çok işlem katmanında dağıtabilirsiniz: Burstable, Genel Amaçlı ve Bellek için Optimize Edilmiş. Her katman , farklı iş yükleri için iyileştirilmiştir. Bazı Azure bölgelerinde, Azure Gizli Bilgi İşlem ile sunucuları dağıtabilirsiniz.

Genel hizmet mimarisi ve dağıtım modelleri hakkında daha fazla bilgi için bkz. PostgreSQL için Azure Veri Tabanı genel bakış.

Fiziksel mimari

• İşlem ve depolama ayrımı: PostgreSQL için Azure Veritabanı, yüksek kullanılabilirliği desteklemek için bir işlem ve depolama ayırma mimarisi kullanır. Veritabanı altyapısı bir Linux sanal makinesinde (VM) çalışırken Azure Depolama veri dosyalarını tutar ve veri dayanıklılığı sağlamak için veritabanı dosyalarının yerel olarak yedekli üç zaman uyumlu kopyasını tutar.

• Yüksek kullanılabilirlik: Sunucunuzda yüksek kullanılabilirlik yapılandırmasını etkinleştirebilirsiniz. Yüksek kullanılabilirlik yapılandırmasını etkinleştirdiğinizde, hizmet sıcak bir hazır bekleyen sunucu sağlar ve korur. Birincil sunucu, birincil sunucuda bir arıza meydana geldiğinde sıfır veri kaybını sağlamak amacıyla veri değişikliklerini bekleme sunucusuna eşzamanlı olarak çoğaltır.

  Mimari, işlem katmanını depolama katmanından ayırır, böylece hizmet farklı hata türlerini uygun şekilde işleyebilir. Daha yüksek dayanıklılık için sunucuları kullanılabilirlik alanlarına yayabilirsiniz.

  

  PostgreSQL için Azure Veri Tabanı için yüksek kullanılabilirlik mimarisini gösteren diyagram. İki sunucu yan yanadır. Sol tarafta birincil sunucu etiketli bir kutu ve bu kutunun içinde bir sanal makine ve bir disk bulunur. Sağ tarafta, üzerinde "bekleme sunucusu" etiketi bulunan, ayrıca bir sanal makine ve bir disk içeren buna karşılık gelen bir kutu vardır. Soldaki birincil sunucudan sağdaki bekleme sunucusuna doğru yatay bir ok uzanır ve bu ok, veri değişikliklerinin birincil sunucudan bekleme sunucusuna tek yönlü olarak aktarıldığı bir ilişkiyi gösteren “akış replikasyonu” etiketiyle gösterilir.

  Hazır bekleyen sunucu sanal çekirdekler, depolama alanı ve ağ ayarları da dahil olmak üzere birincil sunucuyla aynı VM yapılandırmasında dağıtılır.

  Yük devretme gerçekleştirerek sunucular arasında geçiş yapabilirsiniz. İki tür yük devretme vardır: birincil sunucu başarısız olduğunda kullanılan zorunlu yük devretmeler ve bazı bakım işlemleri sırasında ve yük devretme sırasında uygulama kapalı kalma süresini en aza indirmeniz gereken diğer senaryolarda kullanılan planlı yük devretme işlemleri.

  Durdurma, başlatma ve yeniden başlatma gibi işlemler gerçekleştirdiğinizde, bunlar hem birincil hem de beklemedeki veritabanı sunucularında aynı anda gerçekleşir. İşlem ölçeklendirme ve depolama ölçeklendirme gibi planlı olaylar önce beklemede, ardından birincil sunucuda gerçekleşir. Şu anda, sunucu bu planlanan işlemler için yük devretme gerçekleştirmez.

  Daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı'nda yüksek kullanılabilirlik.

• Yedekleme: PostgreSQL için Azure Veritabanı otomatik olarak sunucu yedeklemeleri oluşturur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Uygulamalarınız bakım, ölçeklendirme işlemleri veya ağ kesintileri sırasında oluşabilecek geçici bağlantı hatalarını işlemelidir. Şu önerileri izleyin:

Daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı'nda geçici bağlantı hatalarını işleme.

Kullanılabilirlik alanı hatalarına dayanıklılık

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.

Yüksek kullanılabilirlik yapılandırması aracılığıyla kullanılabilirlik alanı desteği türünüzü seçin. Yüksek kullanılabilirliği etkinleştirdiğinizde, hizmet birincil sunucunuzla birlikte bir bekleme sunucusu dağıtır. Bu yüksek kullanılabilirlik modeli, işlenen verilerin hatalar sırasında hiçbir zaman kaybolmamasını sağlamaya yardımcı olur. Sunucunuz hangi yüksek kullanılabilirlik dağıtım modelini kullanırsa kullansın, verileri hem birincil hem de yedek sunuculara eşzamanlı olarak kaydeder. Birincil sunucuda bir kesinti oluşursa, sunucu otomatik olarak bekleyen yedek sunucuya geçer.

Her kullanılabilirlik alanı, her bölgede otomatik olarak üç veri kopyasını depolayan yerel olarak yedekli depolama (LRS) içeren premium yönetilen disklerde veri dosyalarını ve önceden yazma günlüklerini (WAL) depolar.

PostgreSQL için Azure Veritabanı, yüksek kullanılabilirlik kullandığınızda iki kullanılabilirlik alanı yapılandırma türünü destekler:

• Alanlar arası yedekli yüksek kullanılabilirlik: Alanlar arası yedeklilik, birincil sunucuyu bir kullanılabilirlik alanına ve bekleme sunucusunu farklı bir kullanılabilirlik alanına dağıtarak en yüksek düzeyde bölge dayanıklılığı sağlar. Hazır bekleyen sunucu, birincil sunucununkine benzer işlem, depolama ve ağ yapılandırmasını kullanır. Alanlar arası yedekli yapılandırma, birincil ve hazır bekleyen sunucular arasında yığının tamamının fiziksel yalıtımını sağlar.

  Birincil ve hazır bekleyen sunucular için kullanılabilirlik alanlarını seçebilir veya Bunları Microsoft'un seçmesine izin vekleyebilirsiniz.

  Üretim sunucuları için alanlar arası yedekli dağıtımlar öneririz.

  

  Kullanılabilirlik alanlarına yayılmış alanlar arası yedekli PostgreSQL için Azure Veri Tabanı kurulumu gösteren diyagram. Üst kısımda üç bölge listelenir: kullanılabilirlik alanı 1, kullanılabilirlik alanı 2 ve kullanılabilirlik alanı 3. Kullanılabilirlik alanı 1'in altında birincil sunucu etiketli bir kutu bulunur ve bu kutunun içinde bir sanal makine ve disk bulunur ve birincil sunucunun işlem ve depolamadan oluştuğu gösterilir. Kullanılabilirlik alanı 2'nin altında, bir sanal makine ve disk de içeren hazır bekleyen sunucu etiketli eşleşen bir kutu vardır. Bu iki sunucu kutusu arasında, üzerinde “akış replikasyonu” etiketi bulunan sağa bakan bir ok yer alır; bu ok, veri değişikliklerinin soldaki birincil sunucudan sağdaki bekleme sunucusuna aktığını gösterir. Yerleşim, bölgeler arası dayanıklılığı gösterir: birincil ve yedek iki kullanılabilirlik alanına dağıtılmıştır; kullanılabilirlik alanı 3 ise kullanılmadan bırakılmıştır.

  Hizmet, verileri bekleme sunucusuna zaman uyumlu olarak çoğalttığı için yazma işlemlerinde işlem tamamlama gecikmesinde küçük bir artış yaşanabilir. Etki iş yüküne, seçili SKU'ya ve bölgeye göre değişir.

• Bölgesel (aynı bölge) yüksek kullanılabilirlik: Birincil ve hazır bekleyen sunucular aynı kullanılabilirlik bölgesini kullanır. Birincil sunucuda bir kesinti oluşursa ancak bölge hala iyi durumdaysa, sunucu otomatik olarak hazır bekleyen sunucuya yük devredilir. Bölgesel dağıtım, tek bir kullanılabilirlik alanında yüksek kullanılabilirlik sağlar. Sizi düğüm düzeyindeki arızalara karşı korur ve aynı zamanda planlı ve plansız kesinti durumlarında uygulamanın kesinti süresini azaltmaya yardımcı olur. Ancak, bu bölgedeki bir kesintiye karşı korunmaz.

  

  Tek bir kullanılabilirlik alanında bölgesel PostgreSQL için Azure Veri Tabanı kurulumunu gösteren diyagram. Üç bölge gösterilir: kullanılabilirlik alanı 1, kullanılabilirlik alanı 2 ve kullanılabilirlik alanı 3. Kullanılabilirlik alanı 1'de yan yana iki kutu vardır. Soldaki kutu birincil sunucu olarak etiketlenmiştir ve bu kutunun içinde bir sanal makine ve bir disk bulunur. Sağdaki kutu hazır bekleyen sunucu olarak etiketlenmiştir ve bu kutunun içinde bir sanal makine ve bir disk bulunur. Bu iki sunucu kutusu arasında, üzerinde “akış replikasyonu” etiketi bulunan sağa bakan bir ok yer alır; bu ok, veri değişikliklerinin soldaki birincil sunucudan sağdaki bekleme sunucusuna aktığını gösterir. Her iki sunucu da aynı kullanılabilirlik alanındadır. Kullanılabilirlik alanı 2 ve kullanılabilirlik alanı 3 kullanılmamış.

  Bölgesel (aynı bölge) yüksek kullanılabilirlik yalnızca aşağıdaki durumlarda kullanılabilir:

  • Bölge kullanılabilirlik alanlarını desteklemez. Bölge etkili bir şekilde tek bir bölge olarak çalışır, bu nedenle seçebileceğiniz tek yüksek kullanılabilirlik yapılandırması aynı bölgedir.
  • Bölge yedekli dağıtım için yeterli kapasiteye sahip değilse, hizmet başlangıçta her iki sunucuyu da aynı kullanılabilirlik alanına yerleştirebilir ve kapasite kullanılabilir olduğunda bunları otomatik olarak ayrı bölgelere geçirebilir. Bu seçenek, sunucuyu dağıtmak için Azure portalını veya Azure CLI'yi kullandığınızda kullanılabilir. Daha fazla bilgi için bkz. İş Açısından Kritik (yüksek kullanılabilirlik) seçeneklerini yapılandırma.

  Sunucuları aynı bölgeye yerleştirmek, aynı bölge içinde dağıttığınız uygulamalara yazma gecikmesini azaltabilir.

  Sunucular aynı bölgede olduğunda, aynı bölge içinde dağıttığınız uygulamalara yazma gecikmesi azaltılabilir.

Sunucunuzu yüksek kullanılabilirlik olmadan yapılandırdığınızda tek bir sunucuda çalışır. Bu sunucu veya bölgesi kapanırsa, sunucunuz kullanılamaz. Daha fazla bilgi için bkz . Kullanılabilirlik alanları olmayan yapılandırmalar.

Gereksinimler

• Bölge desteği: PostgreSQL için Azure Veri Tabanı, Azure bölgelerde kullanılabilirlik alanı yapılandırmalarını farklı şekilde destekler. Bölgelerin tam listesi ve kullanılabilirlik alanı desteği türleri ve her bölge için dikkat edilmesi gereken belirli noktalar için bkz. Azure bölgeler.

• İşlem katmanı: Aşağıdaki tabloda her kullanılabilirlik alanı desteği türü için işlem katmanı desteği listelenir:

  İşlem katmanı	Bölgeler arası yedeklilik	Bölgesel (aynı bölge)
  Patlama kapasitesi olan	Desteklenmiyor	Desteklenmiyor
  Genel Amaç	Destekleniyor	Destekleniyor
  Bellek Optimizasyonu Yapılmış	Destekleniyor	Destekleniyor

• Hizmet katmanı: Her iki yüksek kullanılabilirlik türü de Genel Amaçlı veya Bellek için İyileştirilmiş katmanlar gerektirir.

Değerlendirmeler

Bölge kapasitesi: Bölge yedekli dağıtım için yeterli kapasiteye sahip değilse, hizmet başlangıçta her iki sunucuyu da aynı kullanılabilirlik alanına yerleştirebilir ve kapasite kullanılabilir olduğunda bunları otomatik olarak ayrı bölgelere geçirebilir. Bu seçenek, sunucuyu dağıtmak için Azure portalını veya Azure CLI'yi kullandığınızda kullanılabilir. Daha fazla bilgi için bkz. İş Açısından Kritik (yüksek kullanılabilirlik) seçeneklerini yapılandırma.

Maliyet

Yüksek kullanılabilirliği etkinleştirdiğinizde, bir bekleme sunucusu oluşturulur ve birincil sunucuyla aynı hızda faturalandırılır. Kullanılabilirlik alanı yapılandırması maliyeti etkilemez. Kullanılabilirlik alanları içinde veya arasında veri çoğaltma için ücret alınmaz. Yedekleme depolama biriminize bağlı olarak, yedekleme depolama alanı için de faturalandırılabilirsiniz. Ayrıntılı fiyatlandırma bilgileri için bkz. PostgreSQL için Azure Veritabanı fiyatlandırması.

Kullanılabilirlik alanı desteğini yapılandırma

Bir sunucu için kullanılabilirlik alanı desteğini yapılandırmak için yüksek kullanılabilirlik ayarlarını yapılandırın.

• Alanlar arası yedekli sunucu oluşturma: Yüksek kullanılabilirlik ve alanlar arası yedeklilik etkinleştirilmiş bir sunucu oluşturmayı öğrenmek için bkz. Hızlı Başlangıç: PostgreSQL için Azure Veri Tabanı sunucusu oluşturma.

• Mevcut sunucular için kullanılabilirlik alanı yapılandırmasını değiştirin: Yüksek kullanılabilirlik ayarlarını değiştirerek mevcut sunucuların kullanılabilirlik alanı yapılandırmasını değiştirin. Ayrıntılı adımlar için bkz. Mevcut sunucular için yüksek kullanılabilirliği etkinleştirme.

  Birincil veya bekleme sunucusu için kullanılan bölgeyi değiştiremezsiniz. Sunucuyu yeniden oluşturmanız gerekir.

  Tavsiye

  Yüksek kullanılabilirlik yapılandırmasını değiştirmeden önce sunucu etkinliği düşük olana kadar beklemenizi öneririz.

• Yüksek kullanılabilirliği devre dışı bırak: Yüksek kullanılabilirliği devre dışı bırakmak bekleyen sunucuyu kaldırır, bu nedenle sunucunuz kullanılabilirlik alanındaki kesintilere karşı dayanıklı değildir. Daha fazla bilgi için bkz. Yüksek kullanılabilirliği devre dışı bırakma.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, yüksek kullanılabilirlik ve kullanılabilirlik alanı desteğine sahip sunucuları yapılandırdığınızda ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arası işlem: PostgreSQL istemci uygulamaları, veritabanı sunucusu adını kullanarak birincil sunucuya bağlanır. PostgreSQL için Azure Veri Tabanı, birincil kullanılabilirlik alanındaki birincil sunucunun tüm veritabanı bağlantılarını ve sorgularını işlediği etkin-pasif bir yapılandırma kullanır. Bekleme sunucusu normal işlemler sırasında istemci trafiğine hizmet vermez.

• Bölgeler arası veri çoğaltma: Birincil sunucu değişiklikleri bekleme sunucusuna eşzamanlı olarak çoğaltır. Hem birincil hem de hazır bekleyen sunucular yazma işlemini onaylayana kadar işlemler tamamlanmış olarak kabul edilmez.

  Bir uygulama veri yazdığında ve işlediğinde, PostgreSQL ilk olarak değişikliği birincil sunucudaki WAL'da kaydeder. Birincil sunucu, PostgreSQL akış protokolunu kullanarak bu günlükleri hazır bekleyen sunucuya akışla aktarır. Hazır bekleyen sunucu WAL'yi beklemede depoladıktan sonra, birincil sunucu yazma işlemini onaylar. Uygulama yalnızca bu onaydan sonra işlemini işler. Bu onaylama süreci, günlüklerin yedek sunucuya uygulanmasını beklemez.

  Çoğaltmanın etkileri, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak farklıdır:

  • Alanlar arası yedekli: Sunucular ayrı bölgelerde olduğundan, bu yaklaşım bölge hatası sırasında sıfır veri kaybı sağlar. Bu durum bazen bölge hataları için sıfır kurtarma noktası hedefine (RPO) ulaşmak olarak da adlandırılır.

    Ancak bölgeler arası çoğaltma, az miktarda ek gecikme süresine neden olabilir. Gecikme süresinin etkisi uygulamaya bağlıdır. Çoğu uygulama için ek gecikme süresi göz ardı edilebilir.

  • Bölgesel: Her iki sunucu da aynı bölgede olduğundan, bölgeler arasında hiçbir trafik çoğaltılmaz.

  Uyarı

  Sistem, günlük verisini gerçek zamanlı olarak yedek sunucuya çoğaltır. Birincil sunucudaki bir tablonun yanlışlıkla bırakılması veya yanlış veri güncelleştirmeleri gibi tüm kullanıcı hataları bekleme sunucusuna çoğaltılır. Bu tür hatalardan kurtarmak için beklemeyi kullanamazsınız ve yedeklemeden belirli bir noktaya geri yükleme yapmanız gerekir. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölge hatası sırasındaki davranış

Bu bölümde, sunucuları yüksek kullanılabilirlik ve kullanılabilirlik alanı desteğiyle yapılandırdığınızda ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: Azure, hem birincil hem de bekleme sunucularının durumunu düzenli aralıklarla denetler. Birden çok ping işleminden sonra, eğer sağlık izleme birincil sunucuya ulaşılamadığını tespit ederse, hizmet bekleme sunucusuna otomatik yük devretme başlatır. Sistem durumu izleme algoritması, hatalı pozitif durumları önlemek için birden çok veri noktası kullanır.

  Kullanılabilirlik alanı başarısız olursa, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak davranış farklıdır:

  • Bölge yedekliliği: PostgreSQL için Azure Veritabanı, kullanılabilirlik alanı hatalarını otomatik olarak algılar. Olası yüksek kullanılabilirlik durum türlerini görüntülemek için bkz. Yüksek Kullanılabilirlik (HA) sistem durumu izleme. Bir bölge başarısız olduğunda Azure, işlem yapmanıza gerek kalmadan bekleme sunucusuna zorlamalı yük devretme başlatır.

  • Bölgesel: Bölgesel sunucuyu barındıran kullanılabilirlik alanı kullanılamaz duruma gelirse, hem birincil hem de bekleme sunucuları kullanılamaz. Bu senaryoda, hizmet otomatik yük devretme sağlamaz. Bölge kesintisini algılamaktan ve alanlar arası yedekli yedeklemeleri başka bir kullanılabilirlik alanındaki veya bölgedeki ayrı bir sunucuya geri yükleme gibi kurtarma eylemleri gerçekleştirmek sizin sorumluluğundadır.

• Bildirim: PostgreSQL için Azure Veri Tabanı'da yüksek kullanılabilirlik durumu izleme, yüksek kullanılabilirlik özellikli örneklerin sistem durumuna ve hazırlığına sürekli bir genel bakış sağlar. İzleme özelliği Azure Kaynak Durumu'nun üzerine kuruludur ve veritabanınızın yük devretme hazırlığını veya genel kullanılabilirliğini etkileyebilecek sorunları algılayabilir ve uyarır. Proaktif sorun gidermeyi etkinleştirmek ve veritabanınızın çalışma süresini ve performansını korumaya yardımcı olmak için bağlantı durumu, yük devretme durumu ve veri çoğaltma durumu gibi önemli ölçümleri değerlendirin.

  HA sistem durumu değerlerini yapılandırma ve yorumlamaya ilişkin ayrıntılı kılavuz için bkz. Yüksek Kullanılabilirlik (HA) sistem durumu izleme.

• Etkin istekler: Kullanılabilirlik alanı kullanılamaz duruma geldiğinde, etkilenen bölgedeki sunuculara yönelik devam eden istekler sonlandırılabilir. Uygulamaların bu istekleri yeniden denemesi gerekir. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

• Beklenen veri kaybı: Veri kaybı miktarı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Bölge yedekli: Farklı bölgelerdeki birincil ve bekleme sunucuları arasında eşzamanlı çoğaltma nedeniyle bölge yük devretmesi sırasında sıfır veri kaybı beklenir.

  • Bölgesel: Etkilenen bölgedeki sunuculardaki veriler, bölge kurtarana kadar kullanılamaz.

• Beklenen kapalı kalma süresi: Kapalı kalma süresi, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Bölge yedekliliği: Yük devretme genellikle 60-120 saniye içinde tamamlanır. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

  • Bölgesel: Etkilenen bir bölgedeki sunucular, kullanılabilirlik alanı kurtarana kadar kullanılamaz.

• Dağıt -ılması: Trafiği yeniden yönlendirme davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Alanlar arası yedekli: Yük devretmeden sonra, eski yedek sunucu yeni ana sunucu olur ve yeni bağlantıları kabul eder. Azure, kurtarıldıktan sonra özgün birincil bölgede otomatik olarak yeni bir bekleme sunucusu oluşturur. Tüm ayrıntılar için bkz. Zorlamalı yük devretme.

  • Bölgesel: Bir bölge kullanılamıyorsa, sunucunuz kullanılamaz. Başka bir kullanılabilirlik alanında veya bölgede önceden oluşturduğunuz ayrı bir sunucunuz varsa, trafiği bu sunucuya yönlendirmek sizin sorumluluğundadır.

Bölge kurtarma

Bölge kurtarma davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

• Alanlar arası yedekli: Kullanılabilirlik alanı kurtarıldığında PostgreSQL için Azure Veritabanı, kurtarılan bölgede bekleyen sunucuyu otomatik olarak yeniden oluşturur ve geçerli birincil sunucuyla eşitler. Kurtarılan bölge, bekleme konumu olarak görev görür. Gereksiz kesintileri önlemek için hizmet birincil rolü otomatik olarak özgün bölgeye geri taşımaz. Planlı bir yük devretmeyi manuel olarak başlatabilirsiniz eğer birincil bölgeyi özgün bölgeye döndürmek istiyorsanız.

• Bölgesel: Bölge iyi durumda olduktan sonra, bölgedeki sunucular yeniden kullanılabilir duruma gelir. İş yüklerinizin gerektirdiği tüm bölge kurtarma yordamlarından ve veri eşitlemeden siz sorumlusunuz.

Bölge hataları için test

Bölge hataları için test seçenekleri, örneğinizin kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

• Bölgeye yedekli: Zorunlu yük devretme başlatarak uygulamanızın kesinti toleransını test edebilirsiniz. Zorlamalı yük devretme, iş yükünüzü çalıştırırken planlanmamış bir kesinti senaryosu simülasyonu yapmanızı ve uygulama kapalı kalma sürenizi gözlemlemenizi sağlar. Simülasyonları üretim dışı bir ortamda veya sessiz bir zamanda çalıştırmanızı öneririz. Daha fazla bilgi için Zorlamalı yük devretmeyi başlatma konusuna bakın.

• Bölgesel: Tam bölge kesintisi simülasyonu yapamazsınız ancak bölge kesintisine benzer bir şekilde sunucunuzun kullanılamadığının benzetimini yapabilirsiniz. Daha fazla bilgi için bkz. Sunucunun hesaplamayı durdurması.

Bölge genelindeki hatalara dayanıklılık

PostgreSQL için Azure Veritabanı, daha hızlı kurtarma için veritabanınızın eşitlenmiş bir kopyasını farklı bir bölgede tutmak için kullanabileceğiniz bölgeler arası okuma çoğaltmalarını destekler.

Bölgeler arası kurtarma sağlamak için desteklenen bölgelerde coğrafi olarak yedekli yedeklemeler de kullanabilirsiniz. Ancak yedeklemeler genellikle replikasyona göre daha fazla kapalı kalma süresine ve veri kaybına neden olur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölgeler arası okuma replikaları

Veritabanlarınızı bölge düzeyindeki hatalardan korumak için okuma amaçlı çoğaltmalar dağıtabilirsiniz. Her okuma amaçlı çoğaltma ayrı bir PostgreSQL için Azure Veritabanı sunucusudur. İkinci bir Azure bölgesine okuma replikası yerleştirdiğinizde, veritabanı sunucunuz bölge genelindeki bir soruna karşı dayanıklılık sağlayabilir. İsteğe bağlı olarak farklı Azure bölgelerinde olabilecek en fazla beş okuma amaçlı çoğaltma dağıtabilirsiniz. PostgreSQL'in fiziksel çoğaltma teknolojisi, okuma amaçlı çoğaltmaları zaman uyumsuz olarak güncelleştirir ve birincil çoğaltmayı öteleyebilir. Bölgeler arası okuma replikaları, isteğe bağlı olarak, küresel olarak dağıtılmış uygulamalar için gecikme süresini azaltmak veya birincil sunucudan okuma trafiğini başka yere yönlendirmek amacıyla yalnızca okuma iş yüklerine hizmet verebilir. Okuma amaçlı çoğaltma özellikleri ve dikkat edilmesi gerekenler hakkında daha fazla bilgi için Okuma amaçlı çoğaltmalar bölümüne bakın.

Sanal uç noktalar okuma-yazma ve salt okunur uç noktalar sağlar ve bir çoğaltma yükseltildiğinde trafiği otomatik olarak yönlendirir, bu da kapalı kalma süresini yük devretme olayları sırasında en aza indirmeye yardımcı olur. Uygulama dayanıklılığını geliştirmek için bölgeler arası okuma çoğaltmalarıyla sanal uç noktaların kullanılmasını kesinlikle öneririz. Daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı'nda okuma amaçlı çoğaltmalar için sanal uç noktalar.

Birincil bölgeniz başarısız olursa, ikincil çoğaltmanızın birincil olması için bir yükseltme tetikleyebilirsiniz. Okuma replikalarını nasıl kullandığınıza bağlı olarak farklı yük devretme türleri uygun olabilir. Bölge hatalarına dayanıklılık sağlamak için okuma amaçlı çoğaltmalar kullandığınızda, genellikle sanal uç noktanızı güncelleştiren birincil sunucuya yükseltme yaklaşımını kullanırsınız. Bölge kesintisi sırasında zorunlu bir terfi gerçekleştirmeniz gerekebilir, bu da çoğaltılmamış veriler için veri kaybına neden olabilir. Birincil bölgenin iyi durumda olduğu planlı senaryolarda, veri kaybını önlemek için planlı bir yükseltme gerçekleştirmeyi seçebilirsiniz. Daha fazla bilgi için, bkz Azure Veritabanı'nda PostgreSQL için okuma amaçlı çoğaltmaları yükseltme.

Gereksinimler

• Bölge desteği: PostgreSQL için Azure Veritabanı'nı destekleyen herhangi bir bölgede bölgeler arası okuma çoğaltmaları oluşturabilirsiniz. Azure’un eşleştirilmiş bölgeleriyle sınırlı değilsiniz.

• İşlem katmanları: Genel Amaçlı ve Bellek için İyileştirilmiş işlem katmanları okuma amaçlı çoğaltmaları destekler. Esnek katman, okuma replikalarını desteklemez.

Değerlendirmeler

• Yapılandırma farklılıkları: Okuma amaçlı çoğaltmalar tüm yapılandırma ayarlarını birincil sunucudan devralmayabilir. Yük devri gerçekleştikten sonra gerekli ayarları yapılandırmayı planlayın. Birincil sunucunuz ve çoğaltmalarınız simetrik olmalıdır; bu da bazı ayarlar için aynı katmanlara, depolama boyutlarına ve değerlere sahip olmaları gerektiği anlamına gelir. Bölge hataları sırasında, zorlamalı yükseltmeler için simetrik sunucu gereksiniminden feragat edilebilir, ancak beklenmeyen sorunlardan kaçınmak için mümkün olduğunda simetrik yapılandırmaya sahip olmak iyi bir uygulamadır. Daha fazla bilgi için bkz . Yapılandırma yönetimi.

• Çoğaltma gecikmesini izleme: Zaman uyumsuz çoğaltma işlemi, birçok faktöre bağlı olarak değişebilen bir çoğaltma gecikmesi gerektirir. Çoğaltma gecikmesi yüksek olduğunda sunucunuzda sorunlarla karşılaşabilirsiniz. Sorunları yükseltmeden önce azaltabilmeniz için çoğaltma gecikmesini izlemek önemlidir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

• Yüksek kullanılabilirlik: Okuma amaçlı kopyalarda yüksek kullanılabilirlik etkinleştirilemez ve terfi ettirildiklerinde de yüksek kullanılabilirliğe sahip olmazlar. Bir replikayı terfi ettikten sonra yüksek erişilebilirlik yapılandırması yapmak sizin sorumluluğunuzdadır.

Yükseltme işlemiyle ilgili dikkat edilmesi gereken diğer faktörler için bkz . Önemli noktalar.

Maliyet

Okuma amaçlı çoğaltmalar işlem ve depolama maliyetlerinin yanı sıra çoğaltma için bölgeler arası veri aktarımı ücretlerine neden olur. Ayrıntılı fiyatlandırma bilgileri için bkz. PostgreSQL için Azure Veritabanı fiyatlandırması ve Bant genişliği fiyatlandırması.

Çoklu bölge desteğini yapılandırma

• Okuma amaçlı çoğaltma oluşturma: Okuma amaçlı çoğaltma oluşturmayı öğrenmek için bkz. Okuma amaçlı çoğaltma oluşturma. Birincil sunucu çalıştırılıp erişilebilir olduğu sürece, birincil sunucuyu oluşturduktan sonra çoğaltmaları yapılandırabilirsiniz.

  Sanal uç nokta oluşturmak için bkz. Sanal uç nokta oluşturma.

• Okuma amaçlı çoğaltmayı silme: Okuma amaçlı çoğaltmayı silmeyi öğrenmek için bkz. Okuma amaçlı çoğaltmayı silme.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, sunucunuz başka bir bölgede ve sanal uç noktada bir okuma çoğaltması ile yapılandırıldığında ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır:

• Bölgeler arasında trafik yönlendirme: Normal işlemlerde, sanal uç noktanız okuma-yazma uç noktası trafiğini birincil bölgedeki birincil sunucuya yönlendirir. Sanal uç noktanın salt okunur uç noktasını da kullanıyorsanız, trafiği yapılandırdığınız replika hangisiyse ona yönlendirir.

• Bölgeler arasında veri çoğaltma: Bölgeler arası okuma çoğaltmaları, birincil sunucu performansı üzerindeki etkiyi en aza indirmek için zaman uyumsuz çoğaltma kullanır. Çoğaltma gecikmesi miktarı, yazma yükü ve birincil sunucu ile çoğaltmalar arasındaki gecikme süresi gibi birçok faktöre bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak daha uzun olabilir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

Bölge hatası sırasındaki davranış

Bu bölümde, sunucunuz başka bir bölgede ve sanal uç noktada okuma amaçlı bir çoğaltmayla yapılandırıldığında ve birincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır:

• Algılama ve yanıt: Birincil bölgedeki bir kesintiyi algılamak ve okuma replikasını el ile yeni birincil sunucu olarak terfi ettirmekten sorumlusunuz. Bölge kesintisi sırasında zorunlu yükseltme gerçekleştirmeniz gerekir ve bu da kurtarılmamış verilerin kaybolmasına neden olur.

  Önemli

  Yükseltmeyi tetikleme sorumluluğu size bağlıdır. Azure, bölge hatası olsa bile okuma amaçlı çoğaltmaları otomatik olarak yükseltmez.

  Yükseltmeyi başlatmaya yönelik ayrıntılı adımlar için bkz. Okuma çoğaltmasını ana sisteme değiştirme.

• Bildirim: Microsoft, bir bölge kapatıldığında size otomatik olarak bildirim vermez. Bununla birlikte, tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Birincil duruma yükseltme işlemi, birincil bölgeye olan tüm etkin bağlantıları sonlandırır. Yükseltme işlemi tamamlandıktan sonra uygulamaların yükseltilen çoğaltmayla bağlantı oluşturmayı yeniden denemesi gerekir.

• Beklenen veri kaybı: Bölge kesintisi sırasında zorunlu yükseltme gerçekleştirmeniz gerekir ve bu da kurtarılmamış verilerin kalıcı olarak kaybolmasına neden olur.

  Veri kaybı miktarı, kesinti sırasındaki çoğaltma gecikmesine bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak daha uzun olabilir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

• Beklenen kapalı kalma süresi: Zorlamalı yükseltme genellikle tetiklenmeden sonra 1-3 dakika içinde tamamlanır. Uygulamaların doğru uç noktaya yeniden bağlanması da gerekebilir. Sanal uç noktalar zorlamalı yükseltme işleminin bir parçası olarak güncelleştirilir. Uygulamalar, yükseltme tamamlandıktan sonra doğru çoğaltmaya hızla yeniden bağlandığından emin olmak için uç noktanın DNS kayıtlarının yaşam süresine (TTL) uygun olmalıdır.

• Trafik yeniden yönlendirme: Sunucunun sanal uç noktası, uygulama trafiğini otomatik olarak yeni birincil çoğaltmaya yönlendirir.

  Uyarı

  Bir okuma replikası birincil sunucu durumuna yükseltildikten sonra, üzerinde yüksek kullanılabilirlik yapılandırması etkin olmaz. Yüksek kullanılabilirlik yapılandırmasını el ile etkinleştirmeniz veya kendi otomasyon süreçlerinize eklemeniz gerekir.

Bölge geri kazanımı

Sanal uç noktaları kullandığınızda, birincil bölüm kurtarıldıktan sonra eski birincil sunucu otomatik olarak okuma replikası olarak yapılandırılır. Birincil işlemleri tercih ettiğiniz birincil bölgeye döndürmek için başka bir yükseltme gerçekleştirebilirsiniz.

Bölge hataları testi

İşlemlerinizin geçerli olduğundan ve özelliklerin kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) gereksinimlerinizi karşıladığından emin olmak için düzenli olarak okuma-çoğaltma yükseltme yordamlarını test edin.

Okuma replikasını, tüm bölgeler iyi durumda olsa bile istediğiniz zaman birincil sunucu olacak şekilde terfi ettirebilirsiniz. Test için:

• Zorlamalı yükseltme testi gerçekleştirebilirsiniz. Veri kaybına neden olabileceği için bu testleri üretim dışı bir ortamda gerçekleştirmenizi öneririz. Zorlamalı yükseltme testi, bölge kesintisi sırasında gördüğünüz davranışın benzetimini yapmaya yardımcı olur.
• Planlı bakım veya veri kaybını önlemek istediğiniz test senaryoları için bunun yerine planlı yükseltme kullanın. Ancak planlı yükseltme, bölge kesintisi sırasında yükseltmeden farklı bir süreç izler, bu nedenle gerçek bir bölge kesintisi sırasındaki davranışı yansıtmayabilir.

Adım adım yönergeler için bkz. Okuma amaçlı çoğaltmayı birincile değiştirme.

Olağanüstü durum kurtarma stratejinizin bir parçası olarak, düzenli olarak tam kurtarma tatbikatları çalıştırın. Bu alıştırmalar veri doğrulama, uygulama işlevselliği testi ve belgelenmiş geri alma prosedürlerini içermelidir.

Yedekleme ve geri yükleme

PostgreSQL için Azure Veri Tabanı verilerinizi otomatik olarak yedekler. Bu yedeklemeler belirli bir noktaya kurtarma özellikleri sağlar ve yanlışlıkla bozulmaya ve verilerin silinmesine karşı korunmanıza yardımcı olur. Microsoft yedeklemeleri tamamen yönetir. Sunucunun kullanılabilirliğini kesintiye uğratmaz ve hem tam yedeklemeleri hem de işlem günlüğü yedeklemelerini içerir.

• Yedekleme depolama alanı: Sunucuyu kullanılabilirlik alanları olan bir bölgeye dağıtırsanız, hizmet, sunucunun yüksek kullanılabilirlik yapılandırmasından bağımsız olarak yedeklemeleri alanlar arası yedekli depolamada (ZRS) depolar. Kullanılabilirlik alanları olmayan bölgelerde dağıtılan sunucular için, hizmet yedeklemeleri yerel olarak yedekli depolamada (LRS) depolar.

  Eşleştirilmiş Azure bölgelerinde, bölge arızalarına karşı ek koruma sağlamak için yedekleri Azure’daki eşleştirilmiş bölgeye çoğaltan coğrafi olarak yedekli yedek depolamasını sunucu oluşturulurken yapılandırabilirsiniz. Hizmet, yedekleri eş zamansız olarak çoğaltır.

  Varsayılan yedekleme saklama süresi yedi gündür, ancak saklama süresini 35 güne kadar uzatabilirsiniz. Azure Backup'ı 10 yıla kadar el ile yedeklemelerin uzun süreli depolaması için de kullanabilirsiniz. Tüm yedeklemeler şifrelenir.

• Geri yükleme: Belirli bir noktaya kurtarma, yedekleme saklama süresi içinde veritabanınızı istediğiniz an geri yüklemenize olanak tanır. Geri yükleme işlemi, kullanıcı tarafından sağlanan yeni bir sunucu adıyla yeni bir veritabanı sunucusu oluşturur. Yeni sunucuyu kullanarak as-is veya ondan veri kopyalayabilirsiniz.

  Coğrafi olarak yedekli bir yedeklemeyi geri yüklerken, eşleştirilmiş bölgede yeni bir sunucu oluşturursunuz.

  Bu özellik yanlışlıkla yapılan veri değişikliklerinden, uygulama hatalarından veya test senaryolarından kurtarmak için kullanışlıdır.

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

Daha fazla bilgi için bkz . PostgreSQL için Azure Veritabanı'nda yedekleme ve geri yükleme.

Hizmet bakımına dayanıklılık

PostgreSQL için Azure Veri Tabanı, temelindeki donanım, işletim sistemi ve veritabanı altyapısına düzeltme eki uygulanması da dahil olmak üzere kritik bakım görevlerini otomatik olarak gerçekleştirir. Hizmet, planlı bakımın bir parçası olarak güvenlik güncelleştirmelerini, yazılım güncelleştirmelerini ve ikincil sürüm yükseltmelerini içerir.

Sunucunuzun bakım pencereleri sırasında kullanılabilir durumda kaldığından emin olmak için şu önerileri izleyin:

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için bkz. Çevrimiçi hizmetler için SLA'lar.

PostgreSQL için Azure Veri Tabanı, sunucunun yapılandırmasına bağlı olarak farklı kullanılabilirlik SLA'ları sağlar:

• Bölge yedekli yüksek erişilebilirlik ile yapılandırılan sunucular, %99,99 SLA çalışma süresi sunar.
• Bölgesel yüksek kullanılabilirlik ile yapılandırılan sunucular, 99,95%çalışma süresi SLA'sı sunar.
• Yüksek kullanılabilirlik olmadan yapılandırılan sunucular, 99,9%çalışma süresi SLA'sı sunar.

İlgili içerik

• Azure güvenilirliği
• Azure PostgreSQL Veritabanı için mimari en iyi uygulamalar
• PostgreSQL için Azure Veritabanı ile iş sürekliliğine genel bakış
• PostgreSQL için Azure Veritabanı'nda coğrafi olağanüstü durum kurtarma
• Dayanıklılık ve kurtarılabilirlik ilkelerini uygulamak için Terraform betikleri