PostgreSQL için Azure Veri Tabanı esnek sunucuda yüksek kullanılabilirlik

PostgreSQL için Azure Veri Tabanı, fiziksel olarak ayrılmış birincil ve bekleme ç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ğlar. Yüksek kullanılabilirlik (HA) yapılandırmasında sistem, verileri hem birincil hem de yedek sunucuya eşzamanlı olarak kaydeder. Model, veritabanı yazılım mimarinizde tek bir hata noktası olmayacak şekilde tasarlanmıştır.

Çoğu bölgede varsayılan olarak hizmet, bekleyen çoğaltmanızı birincil çoğaltmanızdan farklı bir kullanılabilirlik alanına dağıtır (alanlar arası yedekli). Ayrıca, birincil ve hazır bekleyen çoğaltmaları aynı kullanılabilirlik alanı içinde (bölgesel) dağıtabilirsiniz.

Yüksek kullanılabilirlik özellikleri

• Birincil sunucu ve bekleme çoğaltması sanal çekirdekler, depolama ve ağ ayarları dahil olmak üzere aynı sanal makine yapılandırmasını kullanır.

• Kullanılabilirlik alanı desteğini mevcut bir veritabanı sunucusuna ekleyebilirsiniz.

• Mimari, bekleme sunucusuna ek olarak, quorum commit’i sürdürmek için ayrı bir kullanılabilirlik alanında bir WAL çoğaltma sunucusu içerir. Hazır bekleyen sunucunun geçici olarak kullanılamadığı senaryolarda, kalıcılığı sağlamak için birincil sunucuda ve WAL çoğaltma sunucusunda işlemler işlenir. Yedek sunucu tekrar erişilebilir olduğunda, birincil sunucuyla otomatik olarak eşitlenir. Bu mimari, kaydedilmiş kayıtların kalıcı bir şekilde kalıcı olmasını sağlamaya yardımcı olur.

• Yük devri gerçekleşirse, işlem yalnızca yedek sunucuyu yeni birincil sunucu durumuna yükseltir. WAL replika sunucusu yükseltilmez ve yalnızca commit çoğunluğunun korunmasına yardımcı olmak için kullanılır.

• Yüksek erişilebilirliği devre dışı bırakarak bekleme modundaki replikayı kaldırabilirsiniz.

• Birincil ve bekleme veritabanı sunucularınız için bölge yedekliliğine sahip yüksek kullanılabilirlik sağlamak amacıyla kullanılabilirlik bölgeleri seçebilirsiniz.

• Hem birincil hem de bekleme veritabanı sunucularında aynı anda durdurma, başlatma ve yeniden başlatma gibi işlemler gerçekleştirirsiniz.

• 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. Alanlar arası yedekli sunucular için yedekleme verileri alanlar arası yedekli depolamada (ZRS) depolanır. Alanlar arası yedeklilik olmadan yapılandırılan sunucular, bölgesel (tek bölgeli) sunucular ve kullanılabilirlik alanlarını desteklemeyen bölgelerde yedekleme verileri yerel olarak yedekli depolamada (LRS) depolanır.

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

• Parametrelerde yapılan tüm değişiklikler bekleme kopyasına da uygulanır.

• Statik parametre 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. Kapalı kalma süresini azaltmak için işlem, bakım görevleri kalan düğüm üzerinde uygulanırken iş yüklerinin çalışmaya devam edebilmesi amacıyla yedek düğümü birincil konuma yükseltir.

Uyarı

Yüksek kullanılabilirlik işlevlerinin düzgün çalışmasını sağlamak için max_replication_slots ve max_wal_senders 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 belgelerine bakın.

Kullanılabilirlik alanı destek türleri

PostgreSQL için Azure Veri Tabanı, yüksek kullanılabilirlik yapılandırmaları için hem zone 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

• Aynı bölge (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.

  

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

Bölge arızalarından toparlanma

• Zone-yedekli: PostgreSQL için Azure Veri Tabanı, 60-120 saniye içinde otomatik olarak bekleyen sunucuya geçiş yaparak sıfır veri kaybıyla işlemeye devam eder.

• Bölgesel: Bir bölge başarısız olursa hem birincil hem de bekleme sunucuları kullanılamaz. Bölge düzeyinde bir hatadan kurtulmak için yedeklemeyi kullanarak belirli bir an için geri yükleme yapabilirsiniz. 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. PostgreSQL için Azure Veri Tabanı-Flexible Server'da Yedekleme ve Geri Yükleme.

Servis Düzeyi Sözleşmesi (SLA)

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

Yüksek kullanılabilirlik olmadan PostgreSQL için Azure Veritabanı

Önerilmiyor olsa da, 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 alanı ve kilitlenen sunucuyu otomatik olarak yeniden başlatmak ve sunucuyu başka bir fiziksel düğüme yeniden dağıtmak için yerleşik sunucu dayanıklılığı sağlar. Bu yapılandırma, yüksek kullanılabilirliğe sahip sunuculardan daha düşük bir ç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 Linux hesaplama sanal makinesi oluşturulur.
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.

İş Açısından Kritik (Yüksek Kullanılabilirlik) seçeneklerini yapılandırma

Yüksek kullanılabilirliği (HA) iki şekilde yapılandırabilirsiniz: alanlar arası yedekli HA, bekleme sunucusunu maksimum alan dayanıklılığı 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.

İş Açısından Kritik (Yüksek Kullanılabilirlik) bölümü, alanlar arası yedekli yapılandırmaya sahip hazır bekleyen bir HA sunucusu oluşturma seçeneği sağlar. Yapılandırmayı basitleştirmek ve bölge dayanıklılığını 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, bunun yerine aynı bölge (bölgesel) HA'yı etkinleştirmek için geri dönüş onay kutusunu 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 hale gelirse Azure iş yüklerinizi otomatik olarak aynı bölgeLI HA'dan alanlar arası yedekli HA'ya geçirir. 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 sonunda tam bölge dayanıklılığına ulaşmasını sağlar.

Kullanılabilirlik alanı etkinleştirilmiş bir PostgreSQL için Azure Veri Tabanı oluşturma

Kullanılabilirlik alanlarıyla yüksek kullanılabilirlik için PostgreSQL için Azure Veri Tabanı oluşturmayı öğrenmek için bkz. Quickstart: Azure portalında PostgreSQL için Azure Veri Tabanı oluşturma.

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 sağlığını izleme

PostgreSQL için Azure Veri Tabanı'da 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 devretmeye hazır olma durumunu veya genel kullanılabilirliğini etkileyebilecek sorunları algılamak ve bunlarla ilgili uyarı almak için Azure 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 sistem durumlarını yapılandırma ve yorumlama hakkında ayrıntılı bir kılavuz için bkz. PostgreSQL için Azure Veri Tabanı için High Availability (HA) sistem durumu izleme.

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

• Birincil ve hazır bekleyen sunucu arasındaki çoğaltma senkron.

• Bekleyen HA sunucusunu 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.

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

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ü	Tanım
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 bölgesel (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 tarafından zamanlanmış periyodik yazılım güncellemelerini 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.

Tavsiye

Alanlar arası yedekli esnek bir sunucunuz olduğunda, birincil sunucuyu kapalı kalma süresini azaltarak tercih edilen bir kullanılabilirlik alanına döndürmek için planlı bir yük devretme 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. Planlanan yük devretme işlemi birincil bölgeyi özgün bölgesine geri taşır ve eski birincil ile aynı bölgede yeni bir bekleme sunucusu 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 az 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	Tanım	Uygulama kapalı kalma süresi bekleniyor mu?
1	Yedek sunucunun ana sunucuya yetişmesini bekleyin.	Hayır
2	İç izleme sistemi yük devretme iş akışını başlatır.	Hayır
3	Hazır sunucu, birincil günlük dizisi numarasına (LSN) yaklaşınca uygulama yazma işlemleri engellenir.	Evet
4	Bekleme sunucusu bağımsız bir sunucu olarak yükseltilir.	Evet
5	DNS kaydı, yeni hazır bekleyen sunucunun IP adresiyle güncelleştirilir.	Evet
6	Uygulama yeniden bağlanır ve yeni birincil ile okuma/yazma işlemine devam eder.	Hayır
7	Yeni bir hazır bekleyen sunucu oluşturulur. Alanlar arası yedekli sunucular için yeni sunucu başka bir bölgededir.	Hayır
8	Bekleme sunucusu, yapılandırılması sırasında kaçırdığı günlükleri (Azure Blob'dan) kurtarmaya başlar.	Hayır
9	Birincil sunucu ile hazır bekleyen sunucu arasında sabit bir durum oluşturulur.	Hayır
10	Planlı yük devretme işlemi tamamlandı.	Hayır

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ı beklenirken tercih ettiğiniz bir günde 60 dakikalık bir pencere seçerek isteğe bağlı olarak Azure başlatılan bakım etkinlikleri zamanlayabilirsiniz. Azure düzeltme eki yükleme veya ikincil sürüm güncellemeleri gibi bakım görevleri bu pencere sırası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. Bu Azure tarafından başlatılan bakım etkinlikleri, kullanılabilirlik alanlarıyla yapılandırılmış esnek sunucular için yedek kopya ü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 kesintiler nedeniyle oluşabilir. Yüksek kullanılabilirlikle yapılandırdığınız 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ış kapalı kalma süresini önleyemezsiniz 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ı.

Zorlamalı yük devretme

Üretim iş yükünüzü çalıştırırken planlanmamış bir kesinti senaryosunu simüle etmek için yük devretme testi amacıyla zorunlu yük devretme kullanın. Uygulamanızın kapalı kalma 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	Tanım	Uygulama kapalı kalma süresi bekleniyor mu?
1	Birincil sunucu, yük devretme isteğini aldıktan kısa bir süre sonra durur.	Evet
2	Birincil sunucu çalışmadığı için uygulama çalışmaz duruma gelir.	Evet
3	İç izleme sistemi hatayı algılar ve hazır bekleyen sunucuya yük devretme başlatır.	Evet
4	Bekleme sunucusu, bağımsız bir sunucu olarak tam olarak yükseltilmeden önce kurtarma moduna girer.	Evet
5	Yük devretme işlemi, yedek kurtarma işleminin tamamlanmasını bekler.	Evet
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.	Evet
7	Uygulama yeni birincil sunucuya yeniden bağlanabilir ve işlemi sürdürebilir.	Hayır
8	Tercih edilen bölgede bir hazır bekleyen sunucu oluşturulur.	Hayır
9	Bekleme sunucusu, yapılandırılması sırasında kaçırdığı günlükleri (Azure Blob'dan) kurtarmaya başlar.	Hayır
10	Birincil sunucu ile hazır bekleyen sunucu arasında sabit bir durum oluşturulur.	Hayır
11	Zorlamalı yük devretme işlemi tamamlandı.	Hayır

Uygulama kapalı kalma süresi 1. adımdan sonra başlar ve 6. adım bitene kadar devam eder. Kalan 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_* görünümlerinin ayrı 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, pg_stat_* görünümleri, tarama sayısı, okunan tanımlama grupları ve güncellemeler gibi çalışma zamanına ait etkinlik istatistiklerini sağlar, bu veriler bellekte depolanır ve yük devretme sonrasında sıfırlanır. Kullanıcı tanımlı tablolar için etkinliği izleyen örneğidir 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üne alındığında, PostgreSQL failover işleminden sonra ANALYZE çalıştırmayı değerlendirmelisiniz. Bu işlem, pg_stat_* verilerini (örneğin, pg_stat_user_tables) güncel vakum etkinliği istatistikleriyle günceller; böylece otomatik vakum sürecine yardımcı olur ve bu da veritabanı performansının yeni rolünde optimal 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.

HA ile mantıksal çoğaltma desteği

PostgreSQL için Azure Veri Tabanı Esnek Sunucu'da Yüksek Kullanılabilirlik (HA) ile mantıksal çoğaltma veya mantıksal kod çözme kullanılırken, yük devretme sırasında çoğaltma yuvalarının nasıl davrandığını ve çoğaltmanın sürekliliğini sağlamayı anlamak önemlidir.

PostgreSQL 16 ve öncesi

PostgreSQL 16 ve önceki sürümlerde, yük devretme sonrasında bekleme sunucusunda mantıksal çoğaltma yuvaları otomatik olarak korunmaz. Yük devretme arasında mantıksal çoğaltmayı korumak için şunları gerçekleştirmeniz gerekir:

• Uzantıyı pg_failover_slots etkinleştirme
• Şu gibi gerekli ayarları yapılandırın:
  • hot_standby_feedback = on

Bu yapılandırmalar olmadan, çoğaltma yuvaları yeni birincil sunucuda kullanılamadığından yük devretme sonrasında mantıksal çoğaltma devre dışı kalabilir.

PostgreSQL 17 ve üzeri

PostgreSQL 17'den başlayarak, mantıksal çoğaltma yuvası eşitlemesi yerel olarak desteklenir. Bu özelliği doğru şekilde yapılandırdığınızda sistem, çoğaltma yuvalarını bekleme sunucusuna otomatik olarak senkronize eder.

Bu davranışı etkinleştirmek için:

• sync_replication_slots değerini on olarak ayarlayın.
• hot_standby_feedback değerini on olarak ayarlayın.

Bu ayarlarla, sistem yük devretme sırasında mantıksal çoğaltma yuvalarını korur ve çoğaltma uzantı gerektirmeden devam edebilir. Ayrıntılar için PG_Failover_Slots uzantısı belgelerine bakın.

Dikkat edilmesi gereken önemli hususlar

• Birincil sunucuda mantıksal çoğaltma yuvalarını yönetirsiniz, ancak ha yük devretme işleminden sonra mantıksal çoğaltmanın devam ettiğinden emin olmak için hazır bekleyen sunucunun da bu yuvalara sahip olması gerekir .
• Sistem görünümleri (örneğin, sorgulama pg_replication_slots) yalnızca birincil durumun halini gösterir ve yuvaların yedek sistemle senkronize edilip edilmediğini onaylamaz. Sistem birincil sunucuda sağlıklı görünebilir, ancak bekleme durumundaki mantıksal çoğaltma yuvalarını koruyabilmek için yük devretmeye hazır olmayabilir.

Mantıksal çoğaltma yük devretme hazırlığını izleme

Yük devretme hazırlığını doğrulamaya yardımcı olmak için Azure İzleyici'deki logical_replication_slot_sync_status (Önizleme) metriğini kullanın.

Önemli

Bu ölçümü yaymak için parametresinin metrics.collector_database_activity olarak onayarlandığından emin olun.

Bu ölçüm, mantıksal replikasyon slotlarının HA ana sunucu ve yedek arasında eşitlenip eşitlenmediğini gösterir.

• 1 yuvaların birincil ve yedek arasında eşitlendiğini gösterir.
• 0 yuvaların yedekte eşitlenmediğini gösterir.

Ölçüm değeri 0 ise, mantıksal çoğaltma mevcut birincilde çalışmaya devam edebilir, ancak yük devretmeden sonra devam etmeyebilir. Mantıksal çoğaltma ölçümlerinin tam listesi için bkz. Mantıksal çoğaltma izleme.

Uyarı

Bu eşitleme durumu, HA düğümleri arasındaki durumu yansıtır ve yalnızca birincil düğümdeki sistem görünümleri kullanılarak doğrulanamaz. Özellikle planlı bakım veya yük devretme olaylarından önce mantıksal çoğaltmanın yük devretmeye hazır olmadığını algılamak için uyarılarla bu ölçümü kullanmayı göz önünde bulundurun. Bu ölçüm sürekli süre boyunca 0 olarak kaldığında uyarıları yapılandırmayı göz önünde bulundurun.