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

PostgreSQL için Azure Veritabanı , veritabanı yönetimi işlevleri ve yapılandırma ayarları üzerinde ayrıntılı denetim ve esneklik sağlamak üzere tasarlanmış 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, PostgreSQL için Azure Veritabanı'nın geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca, diğer sorun türlerinden kurtarmak için yedeklemeleri nasıl kullanabileceğinizi açıklar ve PostgreSQL için Azure Veritabanı hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek üzere PostgreSQL için Azure Veritabanı'nın nasıl dağıtılacağı ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediği hakkında bilgi edinmek için bkz. Azure Well-Architected Framework'te PostgreSQL için Azure Veritabanı için mimari en iyi 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 Veritabanı ile çalışırken, veritabanı sunucunuzu desteklemek için gereken işlem ve depolama kaynaklarını temsil eden bir sunucu dağıtırsınız. Sunucuya bir veya daha fazla veritabanı dağıtırsınız.

Sunucular, her biri farklı iş yükleri için iyileştirilmiş birden çok işlem katmanında dağıtılabilir: Ani Yük Kaldırılabilir, Genel Amaçlı ve Bellek Optimizeli. 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 Veritabanı nedir?.

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ı linux sanal makinesinde çalışırken veri dosyaları, veri dayanıklılığını sağlamak için veritabanı dosyalarının yerel olarak yedekli zaman uyumlu üç kopyasını tutan Azure depolama alanında depolanır.

• Yüksek kullanılabilirlik: İsteğe bağlı olarak 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 sunucudaki veri değişiklikleri, birincil sunucu hatası sırasında sıfır veri kaybı sağlamak için bekleme sunucusuna zaman uyumlu olarak çoğaltılır.

  Mimari, işlem katmanını depolama katmanından ayırarak hizmetin farklı hata türlerini uygun şekilde işlemesini sağlar. Daha yüksek dayanıklılık için sunucuları kullanılabilirlik alanlarına yayabilirsiniz.

  

  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 devretmeler.

  Durdurma, başlatma ve yeniden başlatma gibi işlemler hem birincil hem de hazır bekleyen veritabanı sunucularında aynı zamanda gerçekleştirilir. Ölçek bilgi işlem ve ölçek depolama 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:

• Uygulamanız geçici hatalarla karşılaştığında üstel geri alma kullanarak işlemi yeniden deneyin. Yeniden denemeler arasındaki gecikmeyi artırın ve deneme sayısını sınırlayın. Yeniden deneme sayısı üst sınırından sonra işlem yine başarısız olursa, bunu bir hata olarak kabul edin.
• Mümkün olduğunda, yeniden denemeleri otomatik olarak işleyen istemci kitaplıklarını (sürücüler olarak da adlandırılır) kullanın.
• Yazma işlemleri sırasında meydana gelen geçici hatalar daha dikkatli bir şekilde ele alınmalıdır. Yazma işlemlerinizin idemponent olmasını göz önünde bulundurun, böylece birden çok kez güvenli bir şekilde yürütülebilirler.

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ına rağmen kullanılabilirlik alanı desteği türünüzü seçebilirsiniz. Yüksek kullanılabilirliği etkinleştirmek, birincil sunucunuzla birlikte bir hazır bekleyen sunucu 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, veriler hem birincil hem de bekleme sunucularına eşzamanlı olarak kaydedilir. Birincil sunucuda bir kesinti oluşursa, sunucu otomatik olarak bekleyen yedek sunucuya geçer.

Veri dosyaları ve önceden yazma günlükleri (WAL' ler), her kullanılabilirlik alanındaki premium yönetilen disklerde depolanır ve her bölgede otomatik olarak üç veri kopyasını depolayan yerel olarak yedekli depolama (LRS) bulunur.

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 sunucuyla benzer işlem, depolama ve ağ yapılandırması 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.

  

  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 seviyesindeki hatalara karşı korur ve planlı veya plansız çalışma kesintisi durumlarında uygulamanın kesinti süresini azaltmaya yardımcı olur. Ancak, bu bölgedeki bir kesintiye karşı korunmaz.

  

  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 ve 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ölgede olduğundan, aynı bölge içinde dağıttığınız uygulamalara yazma gecikmesini azaltabilir.

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 Veritabanı'nın kullanılabilirlik alanı yapılandırmaları desteği Azure bölgeleri arasında farklılık gösterir. Bölgelerin tam listesi ve kullanılabilirlik alanı desteği türleri ve bu bölgeyle ilgili dikkat edilmesi gereken belirli noktalar için bkz. Azure bölgeleri.

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

  Fiyatlandırma katmanı	Bölgesel olarak yedekli	Bölgesel (aynı bölge)
  Patlama kapasitesi olan	Desteklenmiyor	Destekleniyor
  Genel Amaç	Destekleniyor	Destekleniyor
  Bellek Optimizasyonu Yapılmış	Destekleniyor	Destekleniyor

• Hizmet katmanı: Alanlar arası yedeklilik için Genel Amaçlı veya Bellek için İyileştirilmiş katmanlar gerekir.

  Bölgesel (aynı bölge) dağıtımları tüm fiyatlandırma katmanlarında desteklenir.

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, hazır bekleyen sunucu 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ırabilirsiniz.

• 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ıç: Azure portalında PostgreSQL için Azure Veritabanı 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ştirebilirsiniz. Ayrıntılı adımlar için bkz. Mevcut sunucular için yüksek kullanılabilirliği etkinleştirme.

  Birincil sunucu veya hazır bekleyen sunucu oluşturulduktan sonra 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ğinin düşük olmasını beklemek iyi bir fikirdir.

• 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 sunucular yüksek kullanılabilirlik ve kullanılabilirlik alanı desteğiyle yapılandırıldığında 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 Veritabanı, tüm veritabanı bağlantılarının ve sorgularının birincil kullanılabilirlik alanındaki birincil sunucu tarafından işlendiğ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: Verilerde yapılan değişiklikler birincil ve bekleme sunucuları arasında zaman uyumlu olarak çoğaltılır. Hem birincil hem de hazır bekleyen sunucular yazma işlemini onaylayana kadar işlemler tamamlanmış olarak kabul edilmez.

  Uygulama tarafından tetiklenen işlem, ilk günlüğü birincil sunucudaki WAL'e yazar ve onaylar. Birincil sunucu, Postgres akış protokolunu kullanarak bu günlükleri hazır bekleyen sunucuya akışla aktarır. Yedek sunucu depolaması günlükleri kalıcı hale getirdiğinde, birincil sunucu yazma işleminin tamamlandığını kabul eder. 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 ve çoğu uygulama için 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 verilerini bekleme sunucusuna gerçek zamanlı olarak ç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 nedenle, bu tür hatalardan kurtarmak için beklemeyi kullanamazsınız ve yedeklemeden belirli bir noktaya geri yükleme gerçekleştirmeniz 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ırıldığında 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.

  Bölge hatası durumunda, 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 durumu türleri. 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 Veritabanı'nda yüksek kullanılabilirlik (HA) sistem durumu izleme, HA ö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 sağlık durumlarını yapılandırma ve yorumlama hakkında ayrıntılı bir kılavuz için bkz. PostgreSQL için Azure Veritabanı Yüksek Kullanılabilirlik (HA) sağlık 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ı kurtarılana 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. Hizmet, gereksiz kesintileri önlemek için 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 kesintisi sırasında gerçekleşenlere 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. Tetikleyebileceğiniz farklı yük devretme işlemleri, okuma amaçlı çoğaltmaları nasıl kullandığınıza bağlı olarak değişir. 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.

Uyarı

Bu bölüm, okuma amaçlı çoğaltmaların bölgesel çapta meydana gelen başarısızlıklara karşı nasıl dayanıklılık sağlayabileceğine dair bazı önemli bilgileri özetlemektedir. Ayrıca, performansı geliştirmek ve yüksek ölçekli coğrafi olarak dağıtılmış kullanıcı tabanlarını desteklemek için okuma amaçlı çoğaltmaları da kullanabilirsiniz. Daha fazla bilgi için bkz Okuma çoğaltmaları.

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 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 devretme işlemi sonrasında 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 çoğaltma gecikmesi gerektirir ve bu da çeşitli faktörlere bağlı olarak değişebilir. Çoğaltma gecikmesi çok 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 sürecine uygulanabilecek ek hususlar için Azure Database for PostgreSQL'de okuma replikalarını terfi ettirme - Dikkate Alınması Gerekenler bölümüne bakın.

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ı.

Çok bölgeli desteği 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ıldığı ve erişilebilir olduğu sürece, birincil sunucu oluşturulduktan sonra çoğaltmalar yapılandırılabilir.

  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, trafik yapılandırdığınız çoğaltıcıya yönlendirilir.

• 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 de dahil olmak üzere bir dizi faktöre bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak çok 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: Ana bölgeye yönelik tüm etkin bağlantılar kesilir. Terfi işlemi tamamlandıktan sonra uygulamaların terfi edilen replika ile bağlantı kurmayı 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 çok 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ı

  Okuma replikası birincil sunucu olarak terfi ettikten sonra, yüksek kullanılabilirlik yapılandırması etkinleştirilmiş değildir. 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 RTO ve RPO gereksinimlerinizi karşıladığından emin olmak için okuma replikası yükseltme işlemlerinizi düzenli olarak 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. Planlı yükseltmenin, bölge kesintisi sırasında yükseltmeden farklı bir süreç izlediğini unutmayın.

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 Veritabanı, belirli bir noktaya kurtarma özellikleri sağlayan yedeklemeleri otomatik olarak gerçekleştirir ve verilerin yanlışlıkla bozulmasına ve silinmesine karşı korunmanıza yardımcı olur. Yedeklemeler tamamen Microsoft tarafından yönetilir, sunucunun kullanılabilirliğini kesintiye uğratmaz ve hem tam yedeklemeleri hem de işlem günlüğü yedeklemelerini içerir.

• Yedekleme depolama alanı: Sunucu alanlar arası yedekli yüksek kullanılabilirlik ile yapılandırılmışsa, yedeklemeler alanlar arası yedekli depolamada (ZRS) depolanır. Yüksek kullanılabilirlik olmadan veya bölgesel (tek bölgeli) yüksek kullanılabilirlikle yapılandırılan sunucular için yedeklemeler yerel olarak yedekli depolamada (LRS) depolanır.

  Çiftleri olan Azure bölgelerinde, bölge hatalarına karşı ek koruma için yedekleri Azure eşleştirilmiş bölgesine çoğaltmak üzere sunucu oluşturma zamanında coğrafi olarak yedekli (GRS) yedekleme depolama alanı yapılandırabilirsiniz. Yedeklemeler zaman uyumsuz olarak çoğaltılır.

  Varsayılan yedekleme saklama süresi 7 gündür ve saklama süresini 35 güne kadar uzatma seçeneği vardır. 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 ve bu sunucuya as-is kullanabilir veya 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 Veritabanı, temel alınan donanım, işletim sistemi ve veritabanı altyapısına düzeltme eki uygulama gibi kritik hizmet görevlerini otomatik olarak işler. 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:

• Yüksek kullanılabilirliği etkinleştir: Bakım sırasında, güncelleştirme işleminin bir parçası olarak sunucunun yeniden başlatılması gerekebilir. Yüksek kullanılabilirliği etkinleştirdiyseniz bakım işlemleri genellikle kapalı kalma süresini en aza indirmek için sıralı güncelleştirmeleri kullanır. Küçük sürüm yükseltmeleri gibi periyodik bakım etkinlikleri önce yedek kopyada gerçekleşir. Kesinti süresini azaltmak amacıyla, yedekteki düğüm birincil olarak yükseltilir, böylece bakım görevleri kalan düğüme uygulanırken iş yükleri devam edebilir. Bu sıralama, sunucunuzun alanlar arası yedekli veya bölgesel yüksek kullanılabilirlik kullanıp kullanmadığını belirler.

  Yüksek kullanılabilirlik etkin olmayan sunucular için bakım işlemleri sırasında kısa bir kapalı kalma süresi bekleyebilirsiniz. Yüksek kullanılabilirlik etkinleştirildiğinde, bakım işlemleri genellikle en az kesintiyle veya hiç kesinti olmadan tamamlanır.

• Özel bakım pencerelerini yapılandırma: Bakım zamanlamasını sistem tarafından yönetilecek şekilde yapılandırabilir veya iş operasyonlarınız üzerindeki etkiyi en aza indirmek için özel bir bakım penceresi tanımlayabilirsiniz. İş etkisini en aza indirmek için düşük etkinlik dönemlerinde bakım zamanlayın. Daha fazla bilgi için bkz. Bakım programı.

• Yeniden deneme mantığını uygulama: Uygulamalarınızın bakım yeniden başlatmaları sırasında oluşabilecek kısa bağlantı kesintileriyle başa çıkabileceğinden emin olun. Uygulamalarınızın bu tür sorunlara dayanıklı olmasını sağlamak için bkz. Geçici hatalara dayanıklılık kılavuzu.

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 Veritabanı, sunucunun yapılandırmasına göre 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
• PostgreSQL için Azure Veritabanı Dayanıklılık Çözüm Hızlandırıcısı - Bu makalede açıklanan dayanıklılık ve kurtarılabilirlik ilkelerinin çoğunu uygulayan Terraform betikleri.