PostgreSQL için Azure Veritabanı - Esnek Sunucuda yüksek kullanılabilirlik (Güvenilirlik)

ŞUNLAR IÇIN GEÇERLIDIR: PostgreSQL için Azure Veritabanı - Esnek Sunucu

Bu makalede, kullanılabilirlik alanları ve bölgeler arası kurtarma ile iş sürekliliğini içeren PostgreSQL için Azure Veritabanı - Esnek Sunucuda 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ı - Esnek Sunucu, 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ılabilirlik desteği sunar. Bu yüksek kullanılabilirlik modeli, hata durumunda işlenen verilerin 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 devam edebilir.

PostgreSQL için Azure Veritabanı - Esnek Sunucu, 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ı gerektirir. 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 çok özeldir.

  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ı (önceden yazılan günlükler, yani WAL), her kullanılabilirlik alanı içindeki yerel olarak yedekli depolamada (LRS) depolanır ve otomatik olarak üç veri kopyası depolanı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.

  

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

Alan yedekliliği şu için desteklenmiyor :

1. Esnek işlem katmanı.
2. 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 yaşanması durumunda, sunucu otomatik olarak yedek kopyaya devredilir.

  

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.

Yüksek kullanılabilirlik özellikleri

• Bir yedek kopya, sanal çekirdekler, depolama, ağ ayarları dahil olmak üzere birincil sunucuyla aynı Sanal Makine (VM) yapılandırmasında dağıtı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, otomatik yedeklemeler birincil veritabanı sunucusundan düzenli aralıklarla gerçekleştirilir. Aynı zamanda, işlem günlükleri yedek replikadan yedek depolamada sürekli olarak arşivlenir. 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şlatabilme.

• Küçük sürüm yükseltmeleri gibi dönemsel bakım etkinlikleri ilk olarak bekleme düğümünde gerçekleştirilir. Kapalı kalma süresini azaltmak amacıyla, bekleme düğümü birincil olarak yükseltilir, böylece iş yükleri devam edebilir. Bu sırada bakım görevleri kalan düğüme uygulanır.

Uyarı

High-Availability (HA) işlevlerinin düzgün çalıştığından max_replication_slots emin olmak için ve max_wal_senders sunucu parametresi değerlerini yapılandırmanız gerekir. High-Availability, yük devretmelerini ve sorunsuz yükseltmeleri işlemek için her birinden 4 tane gerektirir. HA kurulumu için, 5 okuma çoğaltması ve 12 mantıksal çoğaltma yuvasıyla, max_replication_slots ve max_wal_senders, her iki parametre değerini de 21 olarak ayarlamanız gerekir. Bunun nedeni, her okuma çoğaltması ve mantıksal çoğaltma yuvasının her biri için 1 gerektirmesi ve High-Availability'ın düzgün çalışması için gereken 4 tane olmasıdır. max_replication_slots ve max_wal_senders parametreleri hakkında daha fazla bilgi edinmek için belgelere başvurun.

Yüksek Kullanılabilirlik Sağlığını İzleme

PostgreSQL için Azure Veritabanı - Esnek Sunucu'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 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çevesinden yararlanıyor. 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.

Müşteriler aşağıdakiler için HA sistem durumu izleme özelliğini kullanabilir:

• Düşük performans veya ağ engelleme gibi olası sorunları ortaya koyan durum göstergeleriyle hem birincil hem de bekleme çoğaltmalarının durumu hakkında gerçek zamanlı içgörüler elde edin.
• HA durumundaki değişikliklerle ilgili zamanında bildirimler için uyarıları yapılandırarak olası kesintileri gidermek için anında işlem yapılmasını sağlayın.
• Veritabanı işlemlerini etkilemeden önce sorunları tanımlayıp gidererek yük devretme hazırlığını iyileştirin.

HA sistem durumu durumlarını yapılandırma ve yorumlama hakkında ayrıntılı bir kılavuz için PostgreSQL için Azure Veritabanı - Esnek Sunucu için Yüksek Kullanılabilirlik (HA) sistem durumu izleme ana makalesine bakın.

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

• Bekleme sunucusuna zaman uyumlu çoğaltma nedeniyle, özellikle alanlar arası yedekli bir yapılandırmayla, uygulamalar yükseltilmiş yazma ve işleme gecikmesi yaşayabilir.

• Yedek çoğaltma okuma sorgularında kullanılamaz.

• Birincil sunucudaki iş yüküne ve etkinliğe bağlı olarak, yedek çoğaltmanın yükseltilebilmesi için yük devretme işlemi 120 saniyeden uzun sürebilir.

• Hazır bekleyen sunucu genellikle WAL dosyalarını 40 MB/sn'de kurtarır. Daha büyük SKU'lar için 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 bekleme yapılandırması desteklenmez.

• Yönetilen bakım penceresi sırasında müşteri tarafından başlatılan yönetim görevlerinin yapılandırılması zamanlanamaz.

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

• Mantıksal kod çözme veya mantıksal çoğaltma, kullanılabilirlik ile yapılandırılmış bir Flexible Sunucu ile yapılandırıldığında, yedek sunucuya yük devretme durumunda, mantıksal çoğaltma yuvaları yedek sunucuya kopyalanmaz. Mantıksal çoğaltma yuvalarını korumak ve yük devretme sonrasında veri tutarlılığını sağlamak için PG Yük Devretme Yuvaları uzantısının kullanılması önerilir. Bu uzantıyı etkinleştirme hakkında daha fazla bilgi için lütfen belgelere bakın.

• Özel (VNET) 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ı yalnızca tek bir bölge içinde yapılandırılır. Kullanılabilirlik alanları bölgeler arasında yapılandırılamaz.

Hizmet Seviyesi Anlaşması (SLA)

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

• Alanlar arası yedeklilik modeli %99,99 SLA'sı çalışma süresi sunar.

PostgreSQL için Azure Veritabanı oluşturma - Kullanılabilirlik alanı etkinleştirilmiş Esnek Sunucu

Kullanılabilirlik alanları ile yüksek kullanılabilirlik için PostgreSQL için Azure Veritabanı - Esnek Sunucu oluşturmayı öğrenmek için, Hızlı Başlangıç: Azure portalında PostgreSQL için Azure Veritabanı - Esnek Sunucu oluşturma bölümüne 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

İşlem tarafından tetiklenen yazma işlemleri ve onaylamalar ilk olarak birincil sunucudaki WAL'e kaydedilir. Bunlar daha sonra Postgres akış protokolü kullanılarak hazır bekleyen sunucuya akışla gönderilir. Günlükler yedek sunucu depolama alanında kalıcı hale geldikten sonra, birincil sunucuya yazmanın tamamlandığı bilgisi verilir. Ancak o zaman uygulama işleminin işlenmesini onaylar. Bu ek gidiş dönüş, uygulamanıza daha fazla gecikme süresi ekler. Etki yüzdesi uygulamaya bağlıdır. Bu onaylama süreci, günlüklerin yedek sunucuya uygulanmasını beklemez. Hazır bekleyen sunucu, yükseltilene kadar sürekli olarak kurtarma modundadır.

Sağlık kontrolü

Esnek sunucu sistem durumu izleme, hem birincil hem de bekleme durumunu düzenli aralıklarla denetler. Birden çok ping işleminden sonra, durum izlemesi birincil sunucuya ulaşılamadığını tespit ederse, hizmet bekleme sunucusuna otomatik yük devretme işlemini başlatır. Sistem durumu izleme algoritması, hatalı pozitif durumları önlemek için birden çok veri noktasına dayanı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 kesildikten sonra, hazır bekleyen sunucu birincil olarak terfi ettirilmeden önce kurtarma işlemini gerçekleştirir ve okuma/yazma işlemlerine açılır. Otomatik DNS girişleri yeni birincil sunucu uç noktasıyla güncelleştirildikten sonra, 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

Birincil ve hazır bekleyen sunucuların durumu sürekli olarak izlenir ve bekleyen sunucuya yük devretme tetikleme de dahil olmak üzere sorunları gidermek için uygun eylemler yapılır. Aşağıdaki tabloda olası yüksek kullanılabilirlik durumları listelenmiştir:

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şamada yüksek kullanılabilirliği etkinleştiriyor veya devre dışı bırakıyorsanız, birincil sunucu etkinliği düşük olduğunda çalışmanız önerilir.

Kararlı durum işlemleri

PostgreSQL istemci uygulamaları, veritabanı sunucusu adı kullanılarak birincil sunucuya bağlanır. Uygulama okuma işlemleri doğrudan birincil sunucudan sunulur. Aynı zamanda, işlemeler ve yazma işlemleri yalnızca günlük verileri hem birincil sunucuda hem de yedek kopyada kalıcı olarak kaydedildikten sonra uygulamaya onaylanır. 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 yedek siteye aktarılır.
3. Ana bir onay alır.
4. Yazmalar/işlemeler kabul edilir.

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

Yüksek kullanılabilirlik ile yapılandırılmış esnek sunucular için log verileri gerçek zamanlı olarak yedek sunucuya çoğaltılır. Birincil sunucu üzerinde meydana gelen, kullanıcıya ait, bir tablonun yanlışlıkla silinmesi veya hatalı veri güncellemeleri gibi hatalar, bekleme yedeğine aktarılır. Bu nedenle, bu tür mantıksal hataları gidermek 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:

• Onarılmış sunucuyu üretim için kullanabilir ve isteğe bağlı olarak aynı bölgede veya aynı bölgede farklı bir bölgede bekleyen bir replika ile yüksek kullanılabilirliği etkinleştirebilirsiniz.

• 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ılabilirlik içinde yapılandırıldığında, uygulamalar birincil sunucuya erişmeye devam ederken bu işlemler ilk olarak bekleme çoğaltmasına uygulanır. Hazır bekleyen çoğaltma güncellendikten sonra, birincil sunucu bağlantıları kapatılır ve bir yük devretme işlemi tetiklenir, bu da yedek çoğaltmanın aynı veritabanı sunucusu adıyla birincil sunucu olarak etkinleşmesine neden olur. İstemci uygulamalarının aynı veritabanı sunucusu adıyla yeni birincil sunucuya yeniden bağlanması gerekir ve işlemlerine devam edebilir. Eski birincil sunucuyla aynı bölgede yeni bir hazır bekleyen sunucu oluşturulur.

Hesaplama ölçekleme veya depolama ölçekleme gibi kullanıcı tarafından başlatılan diğer işlemler için, değişiklikler önce yedek sistemde, ardından ana sistemde uygulanır. Şu anda hizmet, hazır bekleyen sunucuya geçmiyor ve bu nedenle birincil sunucuda ölçeklendirme işlemi yapılırken uygulamalar kısa bir kesinti yaşıyor.

Bu özelliği, bekleme sunucusuna daha kısa kapalı kalma süresiyle yük devretmek için de kullanabilirsiniz. Örneğin, planlanmamış bir yük devretmenin ardından birincil sisteminizin uygulamadan farklı bir kullanılabilirlik alanında bulunması mümkün olabilir. Uygulamanızla birlikte birlikte kullanmak için birincil sunucuyu önceki bölgeye geri getirmek istiyorsunuz.

Bu özellik yürütülürken, bekleme sunucusu ilk olarak son işlemlere yetiştiğinden emin olmak için hazırlanır ve uygulamanın okuma/yazma işlemleri gerçekleştirmeye devam etmesini sağlar. Yedek daha sonra terfi edilir ve birincil sunucuya olan bağlantılar kesilir. Arka planda yeni bir hazır bekleyen sunucu oluşturulurken uygulamanız birincil sunucuya yazmaya devam edebilir. Planlı yük devretme ile ilgili adımlar şunlardır:

Adım	Açıklama	Uygulama kapalı kalma süresi bekleniyor mu?
1	Birincil sunucuya yetişmesi için hazır bekleyen sunucuyu 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	Uygulamanın yeniden bağlanması ve yeni ana sunucu ile okuma/yazma işlemine devam etmesi.	Hayır
7	Başka bir bölgede yeni bir hazır bekleyen sunucu oluşturulur.	Hayır
8	Yedek sunucu, kurulumu 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 işlemi sürdürebilir. Geri kalan adımlar, uygulama yazma ve işlemelerini etkilemeden arka planda gerçekleşir.

Tavsiye

Esnek sunucuyla, tercih ettiğiniz bir günde veritabanlarındaki etkinliklerin düşük olması beklenen 60 dakikalık bir pencere seçerek isteğe bağlı olarak Azure tarafından başlatılan bakım etkinliklerini zamanlayabilirsiniz. Düzeltme eki uygulama veya ikincil sürüm yükseltmeleri gibi Azure bakım görevleri bu zaman aralığı sırasında gerçekleşir. Özel bir pencere seçmezseniz, sunucunuz için saat 23:00 - 07:00 arasında 1 saat penceresi ayrılmış bir sistem seçilir. Azure tarafından başlatılan bu 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 hatası, 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, bekleme çoğaltması etkinleştirilir ve istemciler işlemlerini sürdürebilir. Yüksek kullanılabilirlik (HA) ile yapılandırılmamışsa, yeniden başlatma girişimi başarısız olursa otomatik olarak yeni bir veritabanı sunucusu sağlanır. 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üresini azaltmaya 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 testleri (zorunlu yük devretme testi)

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. Yedek sunucu, son işlenen verilere kadar kurtarma işlemini tamamladıktan sonra birincil 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.

Zorunlu yük devretme sırasında uygulanan adımlar şunlardır:

Adım	Açıklama	Uygulama kapalı kalma süresi bekleniyor mu?
1	Birincil sunucu, yük devretme isteği alındıktan kısa bir süre sonra durdurulur.	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 çalışmaya başladığında, DNS kaydı aynı ana bilgisayar adıyla, ancak yedeğin IP adresi kullanılarak güncellenir.	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	Yedek sunucu, kurulumu 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üresinin 1. adımdan sonra başlaması beklenir ve 6. adım tamamlanana kadar devam eder. Geri kalan adımlar, uygulama yazma ve işlemelerini etkilemeden arka planda gerçekleşir.

Ö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. Bekleme konumuna yük devretme tamamlanana kadar uygulamanız kapalı kalma süresine neden olduğundan, lütfen genel uçtan uca yük devretme işlemi yerine uygulama/istemci perspektifinden kapalı kalma süresini ölçün.

Zorlamalı yük devretme gerçekleştirirken dikkat edilmesi gerekenler

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

  Ö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 hazır bekleyen sunucunun tam olarak kurulmasını sağlayın.

• Kapalı kalma süresini azaltmak için düşük etkinlik dönemi sırasında zorunlu yük devretme yapmanız önerilir.

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ı korumaya yönelik birincil mekanizma, pg_statistic ve pg_stat_* tablolarının farklı rollerini anlamaktır. Tablo, pg_statistic sorgu planlayıcısı için çok önemli olan iyileştirici istatistiklerini barındırır. 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.

Bundan farklı olarak, tarama sayısı, okunan tanımlama grupları 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 işletim durumunu doğru yansıtacak şekilde tasarlanmış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 devretmesinin ardından en iyi yöntem komutunu çalıştırmaktır 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 devredilir.

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 yedekli depolama alanı, 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ırmada %99,9 çalışma süresi garantisi sunulmaktadır. 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 söz konusu olduğunda Azure, başka bir bölgeyi kullanarak 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ı dikkate almanız gerekir. Ö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 durumunda 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 yedekleme yalnızca sunucu oluşturma sırasında yapılandırılabilir. Sunucu coğrafi olarak yedekli yedeklemeyle yapılandırıldığında, 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 çoğaltmaları dağıtılabilir. Okuma amaçlı çoğaltmalar PostgreSQL'in fiziksel çoğaltma teknolojisi kullanılarak zaman uyumsuz olarak güncelleştirilir ve birincil çoğaltmayı öteleyebilir. Okuma replikaları genel amaçlı ve bellek iyileştirmeli hesaplama katmanlarında desteklenir.

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

Sunucunuz coğrafi olarak yedekli yedeklemeyle yapılandırılmışsa, 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. Bölge hatası durumunda, okuma çoğaltmanızı bağımsız bir okuma-yazma sunucusu haline getirerek olağanüstü durum kurtarma işlemi gerçekleştirebilirsiniz. Ciddi bir bölgesel arıza durumu haricinde, RPO'nun 5 dakikaya kadar olması (veri kaybı olabilir) beklenir; ağır bir bölgesel arıza durumunda ise, RPO'nun hata anındaki çoğaltma gecikmesine yakın olması mümkündür.

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.

Sonraki adımlar

PostgreSQL için Azure Veritabanı belgeleri

Azure'da güvenilirlik