PostgreSQL için Azure Veritabanı'nda yüksek kullanılabilirlik (Güvenilirlik)

Bu makalede, kullanılabilirlik alanları ve bölgeler arası kurtarma ile iş sürekliliğini içeren PostgreSQL için Azure Veritabanı'nda yüksek kullanılabilirlik açıklanmaktadır. Azure'da güvenilirlik hakkında daha ayrıntılı bir genel bakış için bkz . Azure güvenilirliği.

PostgreSQL için Azure Veritabanı, aynı kullanılabilirlik alanı içinde (bölgesel) veya kullanılabilirlik alanları arasında (alanlar arası yedekli) fiziksel olarak ayrılmış birincil ve hazır bekleyen çoğaltmalar sağlayarak yüksek kullanılabilirliği destekler. Bu yüksek kullanılabilirlik modeli, işlenen verilerin hatalar sırasında hiçbir zaman kaybolmamasını sağlamak için tasarlanmıştır. Yüksek kullanılabilirlik (HA) kurulumunda veriler hem birincil hem de hazır bekleyen sunuculara eşzamanlı olarak taahhüt edilir. Model, veritabanının yazılım mimarinizde tek bir hata noktası haline gelmemesi için tasarlanmıştır. Yüksek kullanılabilirlik ve kullanılabilirlik alanı desteği hakkında daha fazla bilgi için bkz . Kullanılabilirlik alanı desteği.

Kullanılabilirlik alanı desteği

Kullanılabilirlik alanları , her Azure bölgesinde fiziksel olarak ayrı veri merkezi gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

PostgreSQL için Azure Veritabanı, yüksek kullanılabilirlik yapılandırmaları için hem alanlar arası yedekli hem de bölgesel modelleri destekler. Her iki yüksek kullanılabilirlik yapılandırması da hem planlı hem de plansız olaylar sırasında sıfır veri kaybıyla otomatik yük devretme özelliğini etkinleştirir.

• Bölge yedekli. Bölge yedekli yüksek kullanılabilirlik, otomatik yük devretme yeteneğine sahip farklı bir bölgeye yedek bir kopya dağıtır. Alanlar arası yedeklilik en yüksek kullanılabilirlik düzeyini sağlar, ancak alanlar arasında uygulama yedekliliğini yapılandırmanız gerekir. Bu nedenle, kullanılabilirlik alanı düzeyindeki hatalara karşı koruma istiyorsanız ve kullanılabilirlik alanları arasında gecikme süresi kabul edilebilir olduğunda alanlar arası yedekliliği seçin. Eşzamanlı çoğaltma nedeniyle yazma ve işlem tamamlama üzerinde bazı gecikmeler yaşanabilir ancak okuma sorgularını etkilemez. Bu etki iş yüklerinize, seçtiğiniz SKU türüne ve bölgeye özgüdür.

  Hem birincil hem de bekleme sunucuları için bölgeyi ve kullanılabilirlik alanlarını seçebilirsiniz. Hazır bekleyen çoğaltma sunucusu, birincil sunucuyla benzer işlem, depolama ve ağ yapılandırmasıyla aynı bölgedeki seçilen kullanılabilirlik alanında sağlanır. Veri dosyaları ve işlem günlüğü dosyaları (WAL olarak da bilinen önceden yazma günlükleri), her kullanılabilirlik alanı içinde yerel olarak yedekli depolamada (LRS) depolanır ve üç veri kopyasını otomatik olarak depolar. 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.

  

Alanlar arası yedekli seçeneği yalnızca kullanılabilirlik alanlarını destekleyen bölgelerde kullanılabilir.

Alanlar arası yedeklilik şu durumlar için desteklenmez:

• Seri hale dönüştürülebilir işlem katmanı

• Tek bölgeli kullanılabilirliğe sahip bölgeler

• Bölgesel. Tek bir kullanılabilirlik alanında en yüksek kullanılabilirlik düzeyini elde etmek ancak en düşük ağ gecikme süresine sahip olmak istediğinizde bölgesel bir dağıtım seçin. Birincil veritabanı sunucunuzu dağıtmak için bölgeyi ve kullanılabilirlik bölgesini seçebilirsiniz. Hazır bekleyen çoğaltma sunucusu, birincil sunucuyla aynı kullanılabilirlik alanında (benzer işlem, depolama ve ağ yapılandırmasıyla) otomatik olarak sağlanır ve yönetilir. Bölgesel yapılandırma, veritabanlarınızı düğüm düzeyindeki hatalardan korur ve planlı ve plansız kapalı kalma süresi olayları sırasında uygulama kapalı kalma süresini azaltmaya yardımcı olur. Birincil sunucudaki veriler, eşzamanlı modda bekleyen replika sunucuya kopyalanır. Birincil sunucuda herhangi bir kesinti olursa, sunucu otomatik olarak yedek üniteye yük devreder.

  

Bölgesel dağıtım seçeneği, Esnek Sunucu dağıtabileceğiniz tüm Azure bölgelerinde kullanılabilir.

Uyarı

Hem bölgesel hem de alanlar arası yedekli dağıtım modelleri mimari olarak aynı şekilde davranır. Aşağıdaki bölümlerde yer alan çeşitli tartışmalar, aksi belirtilmedikçe her ikisi için de geçerlidir.

Portalda bölgesel dayanıklılığı yapılandırma

Yüksek kullanılabilirliği (HA) iki şekilde yapılandırabilirsiniz: yedekli HA, bekleme sunucusunu maksimum dayanıklılık için farklı bir kullanılabilirlik alanına yerleştirir veya bekleme sunucusunu birincil sunucuyla aynı bölgeye dağıtarak gecikme süresini en aza indirir.

Yapılandırmayı basitleştirmek ve bölgesel dayanıklılığı sağlamak için portal, iki radyo düğmesi içeren bir Bölgesel Dayanıklılık seçeneği sağlar: Etkin ve Devre Dışı. Etkin seçeneğinin seçilmesi, bekleme sunucusunu farklı bir kullanılabilirlik alanında (alanlar arası yedekli HA modu) oluşturmaya çalışır. Bölge alanlar arası yedekli HA'yı desteklemiyorsa, aynı bölge HA'sını etkinleştirmek için geri dönüş onay kutusunu (aşağıdaki görüntüde vurgulanmış) seçebilirsiniz.

Geri dönüş onay kutusunu seçtiğinizde sistem, bekleme sunucusunu aynı bölgede oluşturur. Daha sonra bölgesel kapasite kullanılabilir duruma gelirse Azure, PITR veya okuma çoğaltmaları kullanarak alanlar arası yedekli bir HA yapılandırmasına geçmeyi seçebilmeniz için sizi bilgilendirir. Onay kutusunu seçmezseniz ve bölgesel kapasite mevcut değilse, HA etkinleştirme başarısız olur. Bu tasarım, alanlar arası yedekli HA'yı varsayılan olarak zorunlu tutarken aynı bölge HA için denetimli bir geri dönüş sağlar ve iş yüklerinin el ile müdahale olmadan tam bölge dayanıklılığına ulaşmasını sağlar.

Yüksek kullanılabilirlik özellikleri

• Yedekteki kopya, tüm sanal çekirdekler, depolama ve ağ ayarları dahil olmak üzere birincil sunucuyla aynı VM yapılandırmasında konumlandırılır.

• Mevcut veritabanı sunucusu için kullanılabilirlik alanı desteği ekleyebilirsiniz.

• Yüksek erişilebilirliği devre dışı bırakarak bekleyen kopyayı kaldırabilirsiniz.

• Alanlar arası yedekli kullanılabilirlik için birincil ve hazır bekleyen veritabanı sunucularınız için kullanılabilirlik alanları seçebilirsiniz.

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

• Alanlar arası yedekli ve bölgesel modellerde, birincil veritabanı sunucusu düzenli aralıklarla otomatik yedeklemeler gerçekleştirir. Aynı zamanda, hazır kopya işlem günlüklerini yedek depolama biriminde sürekli olarak arşivler. Bölge kullanılabilirlik alanlarını destekliyorsa yedekleme verileri alanlar arası yedekli depolamada (ZRS) depolanır. Kullanılabilirlik alanlarını desteklemeyen bölgelerde yedekleme verileri yerel yedekli depolamada (LRS) depolanır.

• İstemciler her zaman birincil veritabanı sunucusunun son ana bilgisayar adına bağlanır.

• Sunucu parametrelerinde yapılan tüm değişiklikler yedek kopyaya da uygulanır.

• Statik sunucu parametresi değişikliklerini almak için sunucuyu yeniden başlatabilirsiniz.

• Küçük sürüm yükseltmeleri gibi düzenli bakım etkinlikleri öncelikle bekleme modunda gerçekleştirilir. 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.

Uyarı

Yüksek kullanılabilirlik işlevlerinin düzgün çalışması için max_replication_slots ve max_wal_senders sunucu parametre değerlerini yapılandırın. Yüksek kullanılabilirlik, yük devretmeleri ve sorunsuz yükseltmeleri işlemek için her birinin dört tane olmasını gerektirir. Beş okuma çoğaltması ve 12 mantıksal çoğaltma yuvası içeren yüksek kullanılabilirlik kurulumu için hem hem max_replication_slots de max_wal_senders parametre değerlerini 21 olarak ayarlayın. Bu yapılandırma gereklidir çünkü her bir okuma replikası ve mantıksal replikasyon yuvası için birer taneye ihtiyaç vardır; ayrıca yüksek erişilebilirliğin düzgün çalışabilmesi için dört adet daha gereklidir. max_replication_slots ve max_wal_senders parametreleri hakkında daha fazla bilgi için belgelere bakın.

Yüksek kullanılabilirlik sağlığını izleme

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. Bu izleme özelliği, veritabanınızın yük devretme hazırlığını veya genel kullanılabilirliğini etkileyebilecek sorunları algılamak ve bunlarla ilgili uyarı almak için Azure'ın Kaynak Durumu Denetimi (RHC) çerçevesini uygular. Ha sistem durumu izleme, bağlantı durumu, yük devretme durumu ve veri çoğaltma durumu gibi önemli ölçümleri değerlendirerek proaktif sorun gidermeye olanak tanır ve veritabanınızın çalışma süresini ve performansını korumaya yardımcı olur.

Aşağıdakiler için HA sistem durumu izlemesini kullanın:

• Performansın düşmesi veya ağ engelleme gibi olası sorunları ortaya koyan durum göstergeleriyle hem birincil hem de hazır bekleyen çoğaltmaların durumu hakkında gerçek zamanlı içgörüler elde edin.
• Olası kesintileri gidermek için anında işlem gerçekleştirebilmeniz için HA durumundaki değişikliklerle ilgili zamanında bildirimler için uyarılar ayarlayın.
• Veritabanı işlemlerini etkilemeden önce sorunları tanımlayıp gidererek yük devretme hazırlığını iyileştirin.

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.

Yüksek kullanılabilirlik sınırlamaları

• Bekleme sunucusuna eşzamanlı çoğaltma nedeniyle, özellikle bölgeye dayanıklı bir yapılandırmayla, uygulamalar artmış yazma ve işleme gecikmesi yaşayabilir.

• Yedek çoğaltmayı okuma sorguları için kullanamazsınız.

• Birincil sunucudaki iş yükü ve etkinliğe bağlı olarak, yedek kopyanın yükseltilebilmesi için önce kurtarılması gerektiğinden geçiş süreci 120 saniyeden uzun sürebilir.

• Hazır bekleyen sunucu genellikle WAL dosyalarını 40 MB/sn'de kurtarır. Daha büyük sürümlerde bu oran 200 MB/sn'ye kadar artabilir. İş yükünüz bu sınırı aşarsa, yük devretme sırasında veya yeni bir yedek oluşturduktan sonra kurtarma işleminin tamamlanması için uzun süre bekleme ile karşılaşabilirsiniz.

• Birincil veritabanı sunucusunun yeniden başlatılması, yedekleme kopyasını da yeniden başlatır.

• Ek beklemeyi yapılandıramazsınız.

• Yönetilen bakım penceresi sırasında müşteri tarafından başlatılan yönetim görevlerini zamanlayamazsınız.

• Ö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.

• HA özellikli esnek bir sunucuda mantıksal kod çözme veya mantıksal çoğaltma yapılandırıyorsanız:

  • PostgreSQL 16 ve önceki sürümlerde, mantıksal çoğaltma yuvaları varsayılan olarak yük devretme sonrasında bekleme sunucusunda korunmaz.
  • Yük devretme sonrasında mantıksal çoğaltmanın çalışmaya devam etmesini sağlamak için pg_failover_slots uzantısını etkinleştirmeniz ve destekleyici ayarları hot_standby_feedback = on gibi yapılandırmanız gerekir.
  • PostgreSQL 17'den başlayarak yuva eşitlemesi yerel olarak desteklenir. Doğru PostgreSQL yapılandırmalarını (sync_replication_slots, hot_standby_feedback) etkinleştirirseniz, mantıksal çoğaltma yuvaları yük devretmeden sonra otomatik olarak korunur ve uzantı gerekmez.
  • Kurulum adımları ve önkoşullar için PG_Failover_Slots uzantısı belgelerine bakın.

• Özel (sanal ağ) ile özel uç noktalarla genel erişim arasında kullanılabilirlik alanlarını yapılandırma desteklenmez. Sanal ağ içindeki kullanılabilirlik alanlarını (bir bölgedeki kullanılabilirlik alanları arasında yayılmış) veya özel uç noktalarla genel erişimi yapılandırmanız gerekir.

• Kullanılabilirlik alanlarını yalnızca tek bir bölge içinde yapılandırabilirsiniz. Bölgeler arasında kullanılabilirlik alanlarını yapılandıramazsınız.

SLA

• Bölgesel model, yaklaşık %99,95 çalışma süresi için bir SLA sunar.

• Alanlar arası yedeklilik modeli, yaklaşık 99,99%için bir SLA için çalışma süresi sunar.

Kullanılabilirlik alanı etkinleştirilmiş postgreSQL için Azure Veritabanı oluşturma

Azure Veritabanı, yüksek kullanılabilirlik için kullanılabilirlik alanlarıyla PostgreSQL için nasıl oluşturulacağını öğrenmek için Hızlı Başlangıç: Azure portalında PostgreSQL için Azure Veritabanı oluşturma'ya bakın.

Kullanılabilirlik alanı yeniden dağıtımı ve geçişi

Hem alanlar arası yedekli hem de bölgesel dağıtım modellerinde esnek sunucunuzda yüksek kullanılabilirlik yapılandırmasını etkinleştirmeyi veya devre dışı bırakmayı öğrenmek için bkz. Esnek Sunucuda yüksek kullanılabilirliği yönetme.

Yüksek kullanılabilirlik bileşenleri ve iş akışı

İşlem tamamlama

Uygulama işlemi, önce birincil sunucudaki WAL'a günlük kaydı yapıp ardından yazma ve işlemi tamamlama işlemini tetikler. 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 ek gidiş dönüş, uygulamanıza gecikme süresi ekler. Etki yüzdesi uygulamaya bağlıdır. Bu onaylama süreci, günlüklerin yedek sunucuya uygulanmasını beklemez. Yedek sunucu, yükseltilene kadar kurtarma modunda kalır.

Sağlık kontrolü

Esnek sunucu sistem durumu izleme, 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.

Yük devretme modları

Esnek sunucu iki yük devretme modunu destekler: Planlı yük devretme ve Plansız yük devretme. Her iki modda da çoğaltma kesintiye uğradığında, yedek sunucu birincil sunucuya yükseltilmeden önce kurtarma çalıştırır ve okuma/yazma için açılır. Otomatik DNS girişleri yeni birincil sunucu uç noktasıyla güncelleştirildiğinde, uygulamalar aynı uç noktayı kullanarak sunucuya bağlanabilir. Uygulamanızın bağlantıyı koruyabilmesi için arka planda yeni bir bekleme sunucusu oluşturulur.

Yüksek kullanılabilirlik durumu

Sistem, birincil ve bekleme sunucularının durumunu sürekli izler. Sorunları düzeltmek için bir yedek sunucuya yük devretmeyi tetiklemek de dahil olmak üzere uygun eylemleri gerçekleştirir. Aşağıdaki tabloda olası yüksek kullanılabilirlik durumları listeleniyor:

Statü	Açıklama
Başlatılıyor	Yeni bir hazır bekleyen sunucu oluşturma işleminde.
Verileri Çoğaltma	Hazır bekleyen oluşturulduktan sonra asenkron olarak ana sisteme yetişiyor.
Sağlıklı	Çoğaltma sabit durumda ve iyi durumda.
Yük Devretme	Veritabanı sunucusu yedek sunucuya yük devretme sürecinde.
BeklemeYi Kaldırma	Şu anda hazır bekleyen sunucuyu silme işleminde.
Etkin Değil	Yüksek kullanılabilirlik etkinleştirilmedi.

Uyarı

Sunucu oluşturma sırasında veya daha sonra yüksek kullanılabilirliği etkinleştirebilirsiniz. Oluşturma sonrası aşamasında yüksek kullanılabilirliği etkinleştirir veya devre dışı bırakırsanız, birincil sunucu etkinliği düşük olduğunda bunu yapın.

Kararlı durum işlemleri

PostgreSQL istemci uygulamaları, VERITABANı sunucusu adını kullanarak birincil sunucuya bağlanır. Birincil sunucu doğrudan uygulama okuma işlemlerine hizmet eder. Aynı zamanda, uygulama işlemlerinin onayını alır ve yalnızca günlük verileri hem birincil sunucuda hem de yedek kopyada kalıcı olduktan sonra yazar. Bu ek gidiş dönüş nedeniyle, uygulamalar yazma ve işlemeler için yükseltilmiş gecikme süresi bekleyebilir. Portalda yüksek erişilebilirlik durumunu izleyebilirsiniz.

1. İstemciler esnek sunucuya bağlanır ve yazma işlemleri gerçekleştirir.
2. Değişiklikler bekleme sitesine yansıtılır.
3. Ana bir onay alır.
4. Yazma ve commit işlemleri onaylanır.

Yüksek erişilebilirlik sunucularını belirli bir noktadan geri yükleme

Sistem, yüksek kullanılabilirlikle yapılandırılmış esnek sunucular için günlük verilerini gerçek zamanlı olarak yedek sunucuya çoğaltır. Birincil sunucudaki tüm kullanıcı hataları (bir tablonun yanlışlıkla bırakılması veya yanlış veri güncelleştirmeleri gibi) bekleme çoğaltmasına çoğaltılır. Böylece, bu tür mantıksal hatalardan kurtulmak için bekleme modunu kullanamazsınız. Bu tür hatalardan kurtulmak için yedeklemeden belirli bir noktaya geri yükleme yapmanız gerekir. Esnek sunucunun belirli bir noktaya geri yükleme özelliğini kullanarak hata oluşmadan önceki zamana geri yükleyebilirsiniz. Yeni veritabanı sunucusu, yüksek kullanılabilirlikle yapılandırılmış veritabanları için kullanıcı tarafından sağlanan yeni bir sunucu adıyla tek bölgeli esnek sunucu olarak geri yüklenir. Geri yüklenen sunucuyu birkaç kullanım örneği için kullanabilirsiniz:

• Üretim için geri yüklenen sunucuyu kullanın ve isteğe bağlı olarak aynı bölgede veya aynı bölgede başka bir konumda yedek kopya ile yüksek kullanılabilirliği etkinleştirin.

• Bir nesneyi geri yüklemek istiyorsanız, nesneyi geri yüklenen veritabanı sunucusundan dışarı aktarın ve üretim veritabanı sunucunuza aktarın.

• Veritabanı sunucunuzu test ve geliştirme amacıyla kopyalamak veya başka amaçlarla geri yüklemek istiyorsanız belirli bir noktaya geri yüklemeyi gerçekleştirebilirsiniz.

Belirli bir noktaya esnek sunucu geri yüklemesini nasıl yapacağınızı öğrenmek için bkz Esnek bir sunucunun belirli bir noktaya geri yüklemesi.

Yük devretme desteği

Planlı yük devretme

Planlı kapalı kalma süresi olayları, Azure'un periyodik olarak gerçekleştirdiği yazılım güncelleştirmelerini ve küçük sürüm yükseltmelerini içerir. Birincil sunucuyu tercih edilen kullanılabilirlik alanına döndürmek için planlı yük devretme de kullanabilirsiniz. Yüksek kullanılabilirliği yapılandırdığınızda, uygulamalar birincil sunucuya erişmeye devam ederken bu işlemler önce yedek kopyaya uygulanır. İşlem yedek çoğaltmayı güncelleştirdikten sonra, birincil sunucu bağlantılarını keser ve aynı veritabanı sunucusu adına sahip birincil sunucu olarak yedek çoğaltmayı etkinleştiren bir yük devretme işlemi başlatır. İstemci uygulamaları aynı veritabanı sunucusu adıyla yeni birincil sunucuya yeniden bağlanır ve işlemlerini sürdürebilir. İşlem, eski birincil sunucuyla aynı bölgede yeni bir hazır bekleyen sunucu oluşturur.

Kullanıcı tarafından başlatılan ölçekleme-işlem veya ölçekleme-depolama gibi diğer işlemler için, işlem değişiklikleri önce yedekte, ardından birincil sisteme uygulanır. Şu anda hizmet, yedek sisteme geçiş yapmaz. Bu nedenle, ölçeklendirme işlemi birincil sunucuda çalışırken uygulamalarda kısa bir kesinti yaşanır.

Bu özelliği, bekleme sunucusuna daha kısa kapalı kalma süresiyle yük devretmek için de kullanabilirsiniz. Örneğin, birincil sunucunuz, planlanmamış bir yük devretme işlemi sonrasında, uygulamanın yer aldığı kullanılabilirlik alanından farklı bir bölgede olabilir. Uygulamanızla birlikte birlikte kullanmak için birincil sunucuyu önceki bölgeye geri getirmek istiyorsunuz.

Bu özelliği yürütürken, işlem ilk olarak bekleme sunucusunu hazırlayarak son işlemlere ayak uydurduğundan emin olur ve uygulamanın okuma ve yazma işlemlerini gerçekleştirmeye devam etmesini sağlar. İşlem, yedek duruma geçirmeyi teşvik eder ve birincil bağlantıları keser. İşlem arka planda yeni bir bekleme sunucusu oluştururken uygulamanız birincil sunucuya yazmaya devam edebilir. Aşağıdaki tabloda planlı yük devretme ile ilgili adımlar açıklanmaktadır:

Step	Açıklama	Uygulama kapalı kalma süresi bekleniyor mu?
1	Yedek sunucunun ana sunucuya yetişmesini bekleyin.	Hayı
2	İç izleme sistemi yük devretme iş akışını başlatır.	Hayı
3	Hazır sunucu, birincil günlük dizisi numarasına (LSN) yaklaşınca uygulama yazma işlemleri engellenir.	Yes
4	Bekleme sunucusu bağımsız bir sunucu olarak yükseltilir.	Yes
5	DNS kaydı, yeni hazır bekleyen sunucunun IP adresiyle güncelleştirilir.	Yes
6	Uygulama yeniden bağlanır ve yeni birincil ile okuma/yazma işlemine devam eder.	Hayı
7	Başka bir bölgede yeni bir hazır bekleyen sunucu oluşturulur.	Hayı
8	Yedek sunucu, kurulumu sırasında kaçırdığı günlükleri (Azure Blob'dan) kurtarmaya başlar.	Hayı
9	Birincil sunucu ile hazır bekleyen sunucu arasında sabit bir durum oluşturulur.	Hayı
10	Planlı yük devretme işlemi tamamlandı.	Hayı

Uygulama kapalı kalma süresi 3. adımda başlar ve 5. adımdan sonra çalışmaya devam edebilir. Geri kalan adımlar, uygulama yazma ve işlemelerini etkilemeden arka planda gerçekleşir.

Tavsiye

Esnek sunucuyla, veritabanlarındaki etkinliklerin düşük olması beklendiğinde tercih ettiğiniz bir günde 60 dakikalık bir pencere seçerek isteğe bağlı olarak Azure tarafından başlatılan bakım etkinlikleri zamanlayabilirsiniz. Azure bakım görevleri, düzeltme eki yükleme veya küçük sürüm yükseltmeleri gibi, bu zaman aralığında gerçekleşir. Özel bir pencere seçmezseniz, sistem sunucunuz için yerel saatle 23:00 ile 07:00 arasında bir saatlik bir pencere ayırır. Azure tarafından başlatılan bu bakım faaliyetleri, kullanılabilirlik alanlarıyla yapılandırılmış esnek sunucular için yedek replikası üzerinde de gerçekleştirilir.

Olası planlı kapalı kalma süresi olaylarının listesi için bkz . Planlı kapalı kalma süresi olayları.

Plansız failover

Planlanmamış kapalı kalma süreleri, temel alınan donanım hataları, ağ sorunları ve yazılım hataları gibi öngörülemeyen kesintilerin bir sonucu olarak oluşabilir. Yüksek kullanılabilirlikle yapılandırılan veritabanı sunucusu beklenmedik şekilde kapanırsa, işlem bekleme çoğaltmasını etkinleştirir ve istemciler işlemlerini sürdürebilir. Yüksek kullanılabilirlik (HA) yapılandırmazsanız ve yeniden başlatma girişimi başarısız olursa, işlem otomatik olarak yeni bir veritabanı sunucusu sağlar. Planlanmamış bir kapalı kalma süresi önlenemez ancak esnek sunucu, insan müdahalesi gerektirmeden kurtarma işlemlerini otomatik olarak gerçekleştirerek kapalı kalma süresinin azaltılmasına yardımcı olur.

Olası senaryolar da dahil olmak üzere planlanmamış yük devretmeler ve kapalı kalma süresi hakkında bilgi için bkz Planlanmamış kapalı kalma süresinin azaltılması.

Yük devretme testi (zorunlu yük devretme)

Zorunlu yük devretme ile üretim iş yükünüzü çalıştırırken planlanmamış bir kesinti senaryosunu simüle edebilir ve uygulamanın kesinti süresini gözlemleyebilirsiniz. Birincil sunucunuz yanıt vermemeye başladığında zorlamalı yük devretme de kullanabilirsiniz.

Zorlamalı yük devretme, birincil sunucuyu devre dışı bırakır ve yedek yükseltme işleminin gerçekleştirildiği yük devretme iş akışını başlatır. Bekleme sunucusu, son işlenen verilere kadar kurtarma işlemini tamamladığında ana sunucu olarak yükseltilir. DNS kayıtları güncelleştirilir ve uygulamanız yükseltilen birincil sunucuya bağlanabilir. Arka planda yeni bir hazır bekleyen sunucu oluşturulurken uygulamanız birincil sunucuya yazmaya devam edebilir ve bu da çalışma süresini etkilemez.

Aşağıdaki tabloda, zorunlu yük devretme sırasındaki adımlar açıklanmaktadır.

Step	Açıklama	Uygulama kapalı kalma süresi bekleniyor mu?
1	Birincil sunucu, yük devretme isteğini aldıktan kısa bir süre sonra durur.	Yes
2	Birincil sunucu çalışmadığı için uygulama çalışmaz duruma gelir.	Yes
3	İç izleme sistemi hatayı algılar ve hazır bekleyen sunucuya yük devretme başlatır.	Yes
4	Bekleme sunucusu, bağımsız bir sunucu olarak tam olarak yükseltilmeden önce kurtarma moduna girer.	Yes
5	Yük devretme işlemi, yedek kurtarma işleminin tamamlanmasını bekler.	Yes
6	Sunucu hazır olduktan sonra, işlem DNS kaydını aynı ana bilgisayar adıyla güncelleştirir, ancak beklemenin IP adresini kullanır.	Yes
7	Uygulama yeni birincil sunucuya yeniden bağlanabilir ve işlemi sürdürebilir.	Hayı
8	Tercih edilen bölgede bir hazır bekleyen sunucu oluşturulur.	Hayı
9	Yedek sunucu, kurulumu sırasında kaçırdığı günlükleri (Azure Blob'dan) kurtarmaya başlar.	Hayı
10	Birincil sunucu ile hazır bekleyen sunucu arasında sabit bir durum oluşturulur.	Hayı
11	Zorlamalı yük devretme işlemi tamamlandı.	Hayı

Uygulama kapalı kalma süresi 1. adımdan sonra başlar ve 6. adım bitene kadar devam eder. Diğer adımlar, uygulama yazma ve işlemelerini etkilemeden arka planda çalışır.

Önemli

Uçtan uca yük devretme işlemi, (a) birincil hatadan sonra bekleme sunucusuna yük devretmeyi ve (b) sabit durumda yeni bir bekleme sunucusu oluşturmayı içerir. Uygulamanız, yedek sisteme yük devretme tamamlanana kadar kapalı kaldığından, genel uçtan uca yük devretme işlemi yerine uygulamanızın/istemcinizin perspektifinden kapalı kalma süresini ölçün.

Zorunlu yük devretme işlemi sırasında dikkat edilmesi gereken hususlar

• Genel uçtan uca işlem süresi, uygulamanın yaşadığı gerçek kapalı kalma süresinden daha uzun olabilir.

  Önemli

  Kapalı kalma süresini uygulama perspektifinden her zaman gözlemleyin!

• Anında, arka arkaya yük devretme işlemi yapmayın. Yük devretmeler arasında en az 15-20 dakika bekleyin, böylece yeni yedek sunucu tamamen etkinleştirilebilir.

• Kapalı kalma süresini azaltmak için düşük etkinlik döneminde zorlamalı yük devretme gerçekleştirin.

Yük devretme sonrasında PostgreSQL istatistikleri için en iyi yöntemler

PostgreSQL yük devretme işleminden sonra en iyi veritabanı performansını korumak için pg_statistic ve pg_stat_* tablolarının farklı rollerini anlamak gerekir. pg_statistic Tabloda, sorgu planlayıcısı için kritik öneme sahip olan iyileştirici istatistikleri depolanıyor. Bu istatistikler, tablolar içindeki veri dağıtımlarını içerir ve hata geçişi sonrasında bozulmadan kalır ve sorgu planlayıcısının doğru, geçmiş veri dağıtım bilgilerine göre sorgu yürütmenin etkili bir şekilde iyileştirilmesini sağlamaya devam eder.

Buna karşılık, tarama sayısı, okunan kümeler ve güncellemeler gibi etkinlik istatistiklerini kaydeden pg_stat_* tablolar, yük devretme sonrasında sıfırlanır. Bu tür bir tabloya örnek olarak, kullanıcı tanımlı tablolar için etkinliği izleyen bir örnek verilmiştir pg_stat_user_tables. Bu sıfırlama, yeni birincilin operasyonel durumunu doğru bir şekilde yansıtır, ancak aynı zamanda otomatik vakum işlemini ve diğer operasyonel verimlilikleri bilgilendirebilecek geçmiş etkinlik ölçümlerinin kaybı anlamına da gelir.

Bu ayrım göz önünde bulundurulduğunda PostgreSQL yük devretme işleminden sonra komutunu çalıştırın ANALYZE . Bu işlem, pg_stat_* tabloları pg_stat_user_tables gibi yeni etkinlik istatistikleriyle güncelleyerek otomatik temizleme sürecine yardımcı olur ve veritabanının performansının yeni rolünde en iyi durumda kalmasını sağlar. Bu proaktif adım, veritabanının geçerli durumuyla uyumlu hale getirmek için temel iyileştirici istatistiklerini koruma ve etkinlik ölçümlerini yenileme arasındaki boşluğu kapatır.

Bölge küçültme deneyimi

Bölgesel: Bölge düzeyinde bir hatadan kurtarmak için yedeklemeyi kullanarak belirli bir noktaya geri yükleme gerçekleştirebilirsiniz . En son verileri geri yüklemek için en son zamanı içeren özel bir geri yükleme noktası seçebilirsiniz. Yeni bir esnek sunucu, etkilenmeyen başka bir bölgeye dağıtılır. Geri yükleme için geçen süre, önceki yedeklemeye ve kurtarılması gereken işlem günlüklerinin hacmine bağlıdır.

Belirli bir noktaya geri yükleme hakkında daha fazla bilgi için bkz Azure Veritabanı-Esnek Sunucuda PostgreSQL için yedekleme ve geri yükleme.

Alanlar arası yedekli: Esnek sunucu, sıfır veri kaybıyla 60-120 saniye içinde otomatik olarak hazır bekleyen sunucuya yük devreder.

Kullanılabilirlik alanları olmayan yapılandırmalar

Bu önerilmez, ancak esnek sunucunuzu yüksek kullanılabilirlik etkinleştirilmeden yapılandırabilirsiniz. Yüksek kullanılabilirlik olmadan yapılandırılan esnek sunucular için hizmet, üç veri kopyasıyla yerel olarak yedekli depolama, alanlar arası yedekli yedekleme (desteklendiği bölgelerde) ve kilitlenen sunucuyu otomatik olarak yeniden başlatmak ve sunucuyu başka bir fiziksel düğüme yeniden yerleştirmek için yerleşik sunucu dayanıklılığı sağlar. Bu yapılandırma, %99,9 çalışma süresi SLA'sı sunar. Planlı veya plansız yük devretme olayları sırasında, sunucu devre dışı kalırsa, hizmet aşağıdaki otomatik yordamı kullanarak sunucuların kullanılabilirliğini korur:

1. Yeni bir bilgi işlem Linux VM'si sağlanır.
2. Veri dosyaları içeren depolama alanı yeni sanal makineye eşlenir.
3. PostgreSQL veritabanı altyapısı yeni sanal makinede çevrimiçine getirilir.

Aşağıdaki resimde VM ile depolama hatası arasındaki geçiş gösterilmektedir.

Bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği

Bölge genelinde bir olağanüstü durum oluşursa Azure, başka bir bölgeden yararlanarak olağanüstü durum kurtarma ile bölgesel veya büyük coğrafya olağanüstü durumlarına karşı koruma sağlayabilir. Azure olağanüstü durum kurtarma mimarisi hakkında daha fazla bilgi için bkz: Azure'den Azure'a olağanüstü durum kurtarma mimarisi.

Esnek sunucu, planlanan ve planlanmamış kapalı kalma süresi olayları sırasında verileri koruyan ve görev açısından kritik veritabanlarınız için kapalı kalma süresini azaltan özellikler sağlar. Güçlü dayanıklılık ve kullanılabilirlik sunan Azure altyapısının üzerine kurulan esnek sunucu, hata koruması sağlayan, kurtarma süresi gereksinimlerini karşılayan ve veri kaybı riskini azaltan iş sürekliliği özellikleri sunar. Uygulamalarınızı tasarlarken, kurtarma süresi hedefi (RTO) ve veri kaybına maruz kalma - kurtarma noktası hedefi (RPO) gibi kapalı kalma süresi toleransını göz önünde bulundurun. Örneğin, iş açısından kritik veritabanınız bir test veritabanından daha sıkı çalışma süresi gerektirir.

Çok bölgeli coğrafyada olağanüstü durum kurtarma

Coğrafi yedekli yedekleme ve geri yükleme

Coğrafi olarak yedekli yedekleme ve geri yükleme, olağanüstü durum oluşursa sunucunuzu farklı bir bölgede geri yükleme olanağı sağlar. Ayrıca bir yıl boyunca yedekleme nesnelerinin en az yüzde 99,9999999999999999 (16 dokuz) dayanıklılığını sağlar.

Coğrafi olarak yedekli yedeklemeyi yalnızca sunucuyu oluşturduğunuzda yapılandırabilirsiniz. Sunucuyu coğrafi olarak yedekli yedeklemeyle yapılandırdığınızda, yedekleme verileri ve işlem günlükleri depolama çoğaltması aracılığıyla eşleştirilmiş bölgeye zaman uyumsuz olarak kopyalanır.

Coğrafi olarak yedekli yedekleme ve geri yükleme hakkında daha fazla bilgi için bkz . Coğrafi olarak yedekli yedekleme ve geri yükleme.

Okuma amaçlı replikalar

Veritabanlarınızı bölge düzeyindeki hatalardan korumak için bölgeler arası okuma amaçlı çoğaltmalar dağıtabilirsiniz. Okuma amaçlı kopyalar, PostgreSQL'in fiziksel çoğaltma teknolojisi kullanılarak zaman uyumsuz olarak güncelleştirilir ve ana sunucunun gerisinde kalabilir. Genel amaçlı ve bellek açısından optimize edilmiş işlem katmanları okuma replikalarını destekler.

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.

Kesinti algılama, bildirim ve yönetim

Sunucunuzu coğrafi olarak yedekli yedeklemeyle yapılandırdıysanız, eşleştirilmiş bölgede coğrafi geri yükleme gerçekleştirebilirsiniz. Bu bölgeye kopyalanan en son kullanılabilir verilere geri yüklenmek üzere yeni bir sunucu kurulur.

Bölgeler arası okuma replikaları da kullanabilirsiniz. Bir bölge hatası oluşursa, okuma çoğaltmasını bağımsız bir okunabilir ve yazılabilir sunucuya terfi ettirerek olağanüstü durum kurtarma işlemi gerçekleştirebilirsiniz. Beklenen RPO, veri kaybı olasılığı ile 5 dakikaya kadar olabilir. Ancak, ciddi bir bölgesel hata durumunda, RPO hata anındaki replikasyon gecikmesine yakın olabilir.

Bölgesel olağanüstü durum sonrasında planlanmamış kapalı kalma süresini azaltma ve kurtarma hakkında daha fazla bilgi için bkz . Planlanmamış kapalı kalma süresini azaltma.

İlgili içerik

• PostgreSQL için Azure Veritabanı belgeleri
• Azure'da güvenilirlik