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. Model ayrıca veritabanı yazılım mimarinizde tek bir hata noktası haline gelmeyecek şekilde 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
Azure kullanılabilirlik alanları, her Azure bölgesindeki en az üç fiziksel ayrı veri merkezi grubudur. Her bölgedeki veri merkezleri bağımsız güç, soğutma ve ağ altyapısı ile donatılmıştır. Yerel bölge hatası durumunda kullanılabilirlik alanları, bir bölge etkileniyorsa, bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik kalan iki bölge tarafından desteklenecek şekilde tasarlanmıştır.
Hatalar, yazılım ve donanım arızalarından deprem, sel ve yangın gibi olaylara kadar değişebilir. Azure hizmetlerinin yedekliliği ve mantıksal yalıtımı ile hatalara dayanıklılık elde edilir. Azure'daki kullanılabilirlik alanları hakkında daha ayrıntılı bilgi için bkz . Bölgeler ve kullanılabilirlik alanları.
Azure kullanılabilirlik alanlarının etkinleştirildiği hizmetler, doğru güvenilirlik ve esneklik düzeyini sağlayacak şekilde tasarlanmıştır. Bunlar iki şekilde yapılandırılabilir. Alanlar arasında otomatik çoğaltma ile alanlar arası yedekli veya belirli bir bölgeye sabitlenmiş örneklerle bölgesel olabilir. Bu yaklaşımları da birleştirebilirsiniz. Bölgesel ve alanlar arası yedekli mimari hakkında daha fazla bilgi için bkz. kullanılabilirlik alanlarını ve bölgelerini kullanmak için Öneriler.
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.
Alanlar arası yedekli. Alanlar arası yedekli yüksek kullanılabilirlik, otomatik yük devretme özelliğine sahip farklı bir bölgeye yedekli çoğaltma 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.
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.
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, zaman uyumlu modda bekleyen çoğaltmaya çoğaltılır. Birincil sunucuda herhangi bir kesinti olması durumunda, sunucu otomatik olarak hazır bekleyen çoğaltmaya devredilir.
Not
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.
Önkoşullar
Alanlar arası yedeklilik:
Alanlar arası yedeklilik seçeneği yalnızca kullanılabilirlik alanlarını destekleyen bölgelerde kullanılabilir.
Alanlar arası yedeklilik şu için desteklenmez :
- PostgreSQL için Azure Veritabanı – Tek Sunuculu SKU.
- Seri hale dönüştürülebilir işlem katmanı.
- Tek bölgeli kullanılabilirliğe sahip bölgeler.
Bölgesel:
- Bölgesel dağıtım seçeneği, Esnek Sunucu dağıtabileceğiniz tüm Azure bölgelerinde kullanılabilir.
Yüksek kullanılabilirlik özellikleri
Yedek çoğaltma, sanal çekirdekler, depolama, ağ ayarları gibi birincil sunucuyla aynı VM yapılandırmasında dağıtılır.
Mevcut veritabanı sunucusu için kullanılabilirlik alanı desteği ekleyebilirsiniz.
Yüksek kullanılabilirliği devre dışı bırakarak bekleme çoğaltmasını 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 depolamada bekleyen çoğaltmadan 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 de bekleme çoğaltmasına uygulanır.
Statik sunucu parametresi değişikliklerini almak için sunucuyu yeniden başlatabilme.
İkincil sürüm yükseltmeleri gibi düzenli bakım etkinlikleri ilk olarak bekleme sırasında gerçekleşir ve kapalı kalma süresini azaltmak için bekleme, iş yüklerinin devam edebilmesi için birincil sürüme yükseltilir ve bakım görevleri kalan düğüme uygulanır.
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.
Hazır bekleyen ç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. İş yükünüz bu sınırı aşarsa, yük devretme sırasında veya yeni bir bekleme oluşturduktan sonra kurtarmanın tamamlanması için uzun süreyle karşılaşabilirsiniz.
Kullanılabilirlik alanları için yapılandırma, yazma ve işleme işlemleri için biraz gecikmeye neden olurken, okuma sorguları üzerinde herhangi bir etki oluşturmaz. Performans etkisi iş yükünüze göre farklılık gösterir. Genel bir ilke olarak yazma ve işlemenin etkisi, etkinin %20-30'u kadar olabilir.
Birincil veritabanı sunucusunun yeniden başlatılması, hazır bekleyen çoğaltmayı 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 tarafından yapılandırılmış bir Esnek Sunucu ile yapılandırılırsa, hazır bekleyen sunucuya yük devretme olması durumunda, mantıksal çoğaltma yuvaları bekleme sunucusuna 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.
SLA
Bölgesel model %99,95 çalışma süresi SLA'sı sunar.
Alanlar arası yedeklilik modeli %99,99 çalışma süresi SLA'sı sunar.
PostgreSQL için Azure Veritabanı oluşturma - Kullanılabilirlik alanı etkinleştirilmiş Esnek Sunucu
Kullanılabilirlik alanlarıyla yüksek kullanılabilirlik için PostgreSQL için Azure Veritabanı - Esnek Sunucu oluşturmayı öğrenmek için bkz. Hızlı Başlangıç: Azure portalında PostgreSQL için Azure Veritabanı - Esnek Sunucu 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 bileşenleri ve iş akışı
İşlem tamamlama
Uygulama işlemiyle tetiklenen yazma işlemleri ve işlemeler ilk olarak birincil sunucudaki WAL'a kaydedilir. Bunlar daha sonra Postgres akış protokolü kullanılarak hazır bekleyen sunucuya akışla gönderilir. Günlükler hazır bekleyen sunucu depolamada kalıcı hale geldikten sonra, birincil sunucu yazma işleminin tamamlandığı kabul edilir. 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 bildirim işlemi, günlüklerin hazır bekleyen sunucuya uygulanmasını beklemez. Hazır bekleyen sunucu yükseltilene kadar kalıcı olarak kurtarma modundadır.
Durum denetimi
Esnek sunucu sistem durumu izleme, hem birincil hem de bekleme durumunu düzenli aralıklarla denetler. Birden çok ping işleminden sonra sistem durumu izleme birincil sunucuya ulaşılamadığını algılarsa, hizmet bekleme sunucusuna otomatik yük devretme 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 yükseltilmeden önce kurtarmayı çalıştırır ve okuma/yazma için 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 birincile yetişir. |
| Sağlıklı | Çoğaltma sabit durumda ve iyi durumda. |
| Yük Devretme | Veritabanı sunucusu hazır bekleyen sunucuya yük devretme sürecindedir. |
| BeklemeYi Kaldırma | Hazır bekleyen sunucuyu silme işleminde. |
| Etkin Değil | Yüksek kullanılabilirlik etkinleştirilmedi. |
Not
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 bekleme çoğaltmada kalıcı hale geldikten sonra uygulamaya doğrulanır. Bu ek gidiş dönüş nedeniyle, uygulamalar yazma ve işlemeler için yükseltilmiş gecikme süresi bekleyebilir. Portalda yüksek kullanılabilirlik durumunu izleyebilirsiniz.
- İstemciler esnek sunucuya bağlanır ve yazma işlemleri gerçekleştirir.
- Değişiklikler hazır bekleyen siteye çoğaltılır.
- Birincil bir bildirim alır.
- Yazmalar/işlemeler kabul edilir.
Yüksek kullanılabilirlik sunucularının belirli bir noktaya geri yüklenmesi
Yüksek kullanılabilirlik ile yapılandırılmış esnek sunucular için günlük verileri bekleme sunucusuna gerçek zamanlı olarak çoğaltılır. Birincil sunucudaki bir tablonun yanlışlıkla bırakılması veya yanlış veri güncelleştirmeleri gibi tüm kullanıcı hataları bekleme çoğaltmasına çoğaltılır. Bu nedenle, bu tür mantıksal hatalardan kurtarmak için beklemeyi 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:
Geri yüklenen sunucuyu üretim için kullanabilir ve isteğe bağlı olarak aynı bölgede veya aynı bölgedeki başka bir bölgede bekleyen çoğaltma 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.
Esnek bir sunucunun belirli bir noktaya geri yüklemesini yapmayı öğrenmek için bkz . Esnek sunucunun belirli bir noktaya geri yüklenmesi.
Yük Devretme Desteği
Planlı yük devretme
Planlı kapalı kalma süresi olayları Azure zamanlanmış düzenli yazılım güncelleştirmelerini ve ikincil 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üncelleştirildikten sonra birincil sunucu bağlantıları boşaltılır ve bir yük devretme tetiklenir ve bu da aynı veritabanı sunucusu adına sahip birincil çoğaltma olması için yedek çoğaltmayı etkinleştirir. İ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.
Ölçek-işlem veya ölçek depolama gibi kullanıcı tarafından başlatılan diğer işlemler için, değişiklikler önce beklemeye, ardından birincile uygulanır. Şu anda hizmet bekleme konumuna devredilmiyor ve bu nedenle ölçeklendirme işlemi birincil sunucuda gerçekleştirilirken uygulamalar kısa bir kapalı kalma süresiyle karşılaşıyor.
Bu özelliği, bekleme sunucusuna düşük kapalı kalma süresiyle yük devretmek için de kullanabilirsiniz. Örneğin, planlanmamış bir yük devretme işleminden sonra birincil uygulamanız uygulamadan farklı bir kullanılabilirlik alanında 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. Bekleme daha sonra yükseltilir ve birincil bağlantı 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:
| Step | Açıklama | Uygulama kapalı kalma süresi bekleniyor mu? |
|---|---|---|
| 1 | Hazır bekleyen sunucunun birincil sunucuya yetişmiş olmasını bekleyin. | Hayır |
| 2 | İç izleme sistemi yük devretme iş akışını başlatır. | Hayır |
| 3 | Hazır bekleyen sunucu birincil günlük dizisi numarasına (LSN) yakın olduğunda 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 | Yeniden bağlanmak ve yeni birincil ile okuma/yazma işlemine devam etmek için uygulama. | Hayır |
| 7 | Başka bir bölgede yeni bir hazır bekleyen sunucu oluşturulur. | Hayır |
| 8 | Bekleme sunucusu, kuruluşu 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.
İpucu
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 pencere 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 bekleme çoğaltması üzerinde de gerçekleştirilir.
Olası planlı kapalı kalma süresi olaylarının listesi için bkz . Planlı kapalı kalma süresi olayları.
Planlanmamış yük devretme
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üresini azaltma.
Yük devretme testleri (zorunlu yük devretme)
Zorlamalı yük devretme ile üretim iş yükünüzü çalıştırırken planlanmamış bir kesinti senaryosu benzetimi yapabilir ve uygulama kapalı kalma sürenizi gözlemleyebilirsiniz. Birincil sunucunuz yanıt vermemeye başladığında zorlamalı yük devretme de kullanabilirsiniz.
Zorlamalı yük devretme birincil sunucuyu aşağı getirir ve bekleme yükseltme işleminin gerçekleştirildiği yük devretme iş akışını başlatır. Bekleme, 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.
Zorlamalı yük devretme sırasında aşağıdaki adımlar şunlardır:
| Step | 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. | Yes |
| 2 | Birincil sunucu kapalı olduğundan uygulama kapalı kalma süresiyle karşılaşır. | 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 bekleme kurtarma işleminin tamamlanmasını bekler. | Yes |
| 6 | Sunucu açıldığında, DNS kaydı aynı ana bilgisayar adıyla güncelleştirilir ancak beklemenin IP adresi kullanılır. | Yes |
| 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, kuruluşu 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 süresi boyunca zorlamalı yük devretme gerçekleştirmeniz ö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 yük devretme 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ütmeyi etkili bir şekilde iyileştirmeye devam ettiğinden emin olur.
Buna karşılık, pg_stat_* tarama sayısı, okunan tanımlama grupları ve güncelleştirmeler gibi etkinlik istatistiklerini kaydeden 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 eylem, gibi pg_stat_user_tablestabloları yeni etkinlik istatistikleriyle güncelleştirerek pg_stat_* otomatik vakum işlemine yardımcı olur ve veritabanı 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 azaltma 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. PostgreSQL için Azure Veritabanı-Esnek Sunucuda 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 SLA'sı 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:
- Yeni bir işlem Linux VM'si sağlanır.
- Veri dosyaları içeren depolama alanı yeni sanal makineye eşlenir.
- 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 olarak 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ı çoğaltmalar
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 amaçlı çoğaltmalar genel amaçlı ve bellek için iyileştirilmiş işlem katmanlarında desteklenir.
Okuma amaçlı çoğaltma özellikleri ve dikkat edilmesi gerekenler hakkında daha fazla bilgi için bkz . Okuma amaçlı çoğaltmalar.
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 son kullanılabilir verilere yeni bir sunucu sağlanır ve kurtarılır.
Bölgeler arası okuma çoğaltmaları da kullanabilirsiniz. Bölge hatası durumunda, okuma amaçlı çoğaltmanızı tek başına okunabilir yazılabilir sunucu olarak tanıtarak olağanüstü durum kurtarma işlemi gerçekleştirebilirsiniz. RPO'nun, RPO'nun hata anında çoğaltma gecikmesine yakın olması durumunda ciddi bölgesel hata olması dışında RPO'nun 5 dakikaya kadar (veri kaybı olabilir) olması beklenir.
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.