Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
PostgreSQL için Azure Veritabanı'nda iş sürekliliği, özellikle bilgi işlem altyapısında kesintiler karşısında işletmenizin çalışmaya devam edebilmesini sağlayan mekanizmaları, ilkeleri ve yordamları ifade eder. Çoğu durumda PostgreSQL için Azure Veritabanı, bulut ortamında gerçekleşebilecek kesintiye neden olan olayları işler ve uygulamalarınızı ve iş süreçlerinizi çalışır durumda tutar. Ancak, aşağıdakiler gibi otomatik olarak işlenebilen bazı olaylar vardır:
- Kullanıcı tablodaki bir satırı yanlışlıkla siler veya güncelleştirir.
- Deprem, elektrik kesintisine neden olur ve bir kullanılabilirlik bölgesini veya bölgeyi geçici olarak devre dışı bırakır.
- Bir hatayı veya güvenlik sorununu düzeltmek için veritabanı düzeltme eki uygulama gerekir.
PostgreSQL için Azure Veritabanı, 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 PostgreSQL için Azure Veritabanı, başka bir hata koruması sağlayan, kurtarma süresi gereksinimlerini karşılayan ve veri kaybı riskini azaltan iş sürekliliği özelliklerine sahiptir. 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.
Aşağıdaki tabloda PostgreSQL için Azure Veritabanı'nın sunduğu özellikler gösterilmektedir.
| Feature | Açıklama | Dikkat edilmesi gerekenler |
|---|---|---|
| Otomatik yedeklemeler | PostgreSQL için Azure Veritabanı esnek sunucu örneği, veritabanı dosyalarınızın günlük yedeklemelerini otomatik olarak gerçekleştirir ve işlem günlüklerini sürekli olarak yedekler. Yedekleme dosyaları 7 gün ile 35 gün arasında saklanabilir. Veritabanı sunucunuzu yedekleme saklama süreniz içinde herhangi bir noktaya geri yükleyebilirsiniz. RTO, geri yükleneceği verilerin boyutuna ve günlük kurtarma gerçekleştirme süresine bağlıdır. Birkaç dakikadan 12 saate kadar sürebilir. Diğer ayrıntılar için bkz . Kavramlar - Yedekleme ve Geri Yükleme. | Yedekleme verileri bölge içinde kalır. |
| Bölge yedekliliği ile yüksek kullanılabilirlik | PostgreSQL için Azure Veritabanı esnek sunucu örneği, birincil ve bekleme sunucularının bir bölge içindeki iki farklı kullanılabilirlik alanına dağıtıldığı alanlar arası yedekli yüksek kullanılabilirlik (HA) yapılandırmasıyla dağıtılabilir. Bu HA yapılandırması veritabanlarınızı bölge düzeyindeki hatalara karşı 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. Çoğu durumda RTO'ların 120'den az olması beklenir. RPO'nun sıfır (veri kaybı yok) olması beklenir. Daha fazla bilgi için bkz. [Kavramlar - Yüksek kullanılabilirlik]/azure/reliability/reliability-postgresql-flexible-server. | Genel amaçlı ve bellek için iyileştirilmiş işlem katmanlarında desteklenir. Yalnızca birden çok bölgenin kullanılabildiği bölgelerde kullanılabilir. |
| Yüksek kullanılabilirlik aynı bölgede | PostgreSQL için Azure Veritabanı esnek sunucu örneği, birincil ve hazır bekleyen sunucuların bir bölgedeki aynı kullanılabilirlik alanında dağıtıldığı aynı bölge yüksek kullanılabilirlik (HA) yapılandırmasıyla dağıtılabilir. Bu HA yapılandırması, 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. Çoğu durumda RTO'ların 120'den az olması beklenir. RPO'nun sıfır (veri kaybı yok) olması beklenir. Daha fazla bilgi için bkz. [Kavramlar - Yüksek kullanılabilirlik]/azure/reliability/reliability-postgresql-flexible-server. | Genel amaçlı ve bellek için iyileştirilmiş işlem katmanlarında desteklenir. |
| Premium yönetilen diskler | Veritabanı dosyaları son derece dayanıklı ve güvenilir olan premium yönetilen depolamada saklanır. Bu sayede üç çoğaltma kopyasının otomatik veri kurtarma özelliklerine sahip bir kullanılabilirlik alanında depolandığı bir veri yedekliliği sağlanır. Daha fazla bilgi için yönetilen diskler belgelerine bakın. | Kullanılabilirlik alanında depolanan veriler. |
| Alanlar arası yedekli yedekleme | PostgreSQL için Azure Veritabanı esnek sunucu örneği yedeklemeleri, bölge kullanılabilirlik alanlarını destekliyorsa, bölge içindeki alanlar arası yedekli depolamada otomatik ve güvenli bir şekilde depolanır. Sunucunuzun sağlandığı bölge düzeyinde bir hata sırasında ve sunucunuz alanlar arası yedeklilikle yapılandırılmamışsa, farklı bir bölgedeki en son geri yükleme noktasını kullanarak veritabanınızı geri yükleyebilirsiniz. Daha fazla bilgi için bkz . Kavramlar - Yedekleme ve Geri Yükleme. | Yalnızca birden çok bölgenin kullanılabildiği bölgelerde geçerlidir. |
| Coğrafi olarak yedekli yedekleme | PostgreSQL için Azure Veritabanı esnek sunucu örneği yedeklemeleri uzak bir bölgeye kopyalanır. bu, birincil sunucu bölgesinin kapanması durumunda olağanüstü durum kurtarma durumuna yardımcı olur. | Bu özellik şu anda seçili bölgelerde etkindir. Geri yükleneceği verilerin boyutuna ve gerçekleştirilecek kurtarma miktarına bağlı olarak daha uzun bir RTO ve daha yüksek bir RPO gerekir. |
| Okuma Amaçlı Çoğaltma | 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ı geri alabilir. Daha fazla bilgi için Kavramlar - Okuma Amaçlı Çoğaltmalar bölümüne bakın. | Genel amaçlı ve bellek için iyileştirilmiş işlem katmanlarında desteklenir. |
Aşağıdaki tabloda , tipik bir iş yükü senaryosunda RTO ve RPO karşılaştırılıyor:
| Yetenek | Patlama kapasiteli | Üretim SKU'su (Genel Amaçlı/Bellek Optimizasyonlu) |
|---|---|---|
| Yedekten belirli bir noktaya geri yükleme | Saklama süresi içindeki herhangi bir geri yükleme noktası RTO - Değişiklik Gösterir RPO < 5 Dakika |
Saklama süresi içindeki herhangi bir geri yükleme noktası RTO - Değişiklik Gösterir RPO < 5 Dakika |
| Coğrafi olarak çoğaltılan yedeklemelerden coğrafi geri yükleme | RTO - Değişiklik Gösterir RPO < 1 s |
RTO - Değişiklik Gösterir RPO < 1 s |
| Okuma amaçlı replikalar | Geçerli değil | RTO - Dakika* RPO - Genellikle 30 sn ile 5 Dakika arasında değişir* |
| Yüksek Erişilebilirlik | Geçerli değil | RTO < 120 s RPO = 0 |
Planlı kapalı kalma olayları
Bazı planlı bakım senaryoları aşağıdadır. Bu olaylar genellikle birkaç dakika kapalı kalma süresine ve veri kaybı olmadan oluşur.
| Senaryo | İşlem |
|---|---|
| İşlem ölçeklendirme (Kullanıcı tarafından başlatılan) | İşlem ölçeklendirme işlemi sırasında etkin denetim noktalarının tamamlanmasına izin verilir, istemci bağlantıları boşaltılır, kaydedilmemiş işlemler iptal edilir, depolama ayrılır ve ardından kapatılır. Ölçeklendirilmiş işlem yapılandırmasıyla aynı veritabanı sunucusu adına sahip yeni bir PostgreSQL için Azure Veritabanı esnek sunucu örneği sağlanır. Depolama daha sonra yeni sunucuya eklenir ve istemci bağlantılarını kabul etmeden önce gerekirse kurtarma gerçekleştiren veritabanı başlatılır. |
| Depolama ölçeğini artırma (Kullanıcı tarafından başlatılan) | Depolamayı ölçeklendirme işlemi başlatıldığında etkin denetim noktalarının tamamlanmasına izin verilir, istemci bağlantıları boşaltılır ve kaydedilmemiş işlemler iptal edilir. Bundan sonra sunucu kapatılır. Depolama istenen boyuta ölçeklendirilir ve ardından yeni sunucuya eklenir. İstemci bağlantılarını kabul etmeden önce gerekirse bir kurtarma gerçekleştirilir. Depolama boyutunun ölçeğini azaltmanın desteklenmediğini unutmayın. |
| Yeni yazılım dağıtımı (Azure tarafından başlatılan) | Yeni özelliklerin piyasaya sürülmesi veya hata düzeltmeleri, hizmetin planlı bakımının bir parçası olarak otomatik olarak gerçekleşir ve bu etkinliklerin ne zaman gerçekleşebileceğini zamanlayabilirsiniz. Daha fazla bilgi için portalınıza bakın. |
| İkincil sürüm yükseltmeleri (Azure tarafından başlatılan) | PostgreSQL için Azure Veritabanı, veritabanı sunucularına otomatik olarak Azure tarafından belirlenen ikincil sürüme düzeltme eki ekler. Hizmetin planlı bakımının bir parçası olarak gerçekleşir. Veritabanı sunucusu yeni ikincil sürümle otomatik olarak yeniden başlatılır. Daha fazla bilgi için belgelere bakın. Portalınızı da kontrol edebilirsiniz. |
PostgreSQL için Azure Veritabanı esnek sunucu örneği yüksek kullanılabilirlikle yapılandırıldığında, hizmet önce bekleme sunucusunda ölçeklendirme ve bakım işlemlerini gerçekleştirir. Daha fazla bilgi için bkz. [Kavramlar - Yüksek kullanılabilirlik]/azure/reliability/reliability-postgresql-flexible-server.
Planlanmamış kapalı kalma süresini azaltma
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 PostgreSQL için Azure Veritabanı, insan müdahalesi gerektirmeden kurtarma işlemlerini otomatik olarak gerçekleştirerek kapalı kalma süresinin azaltılmasına yardımcı olur.
Yüksek kullanılabilirlik sağlamak için sürekli çaba göstersek de, PostgreSQL için Azure Veritabanı'nın veritabanlarının kullanılamamasına ve bu nedenle uygulamanızı etkilemesine neden olan kesintiler yaşanabilir. Hizmet izlememiz yaygın bağlantı hatalarına, hatalara veya performans sorunlarına neden olan sorunları algıladığında, hizmet sizi bilgilendirmek için otomatik olarak bir kesinti bildirir.
Hizmet Kesintisi
PostgreSQL için Azure Veritabanı esnek sunucu örneği kesintisi durumunda kesintiyle ilgili diğer ayrıntıları aşağıdaki yerlerde görebilirsiniz:
- Azure portalı başlığı: Aboneliğinizin etkilendiği belirlenirse Azure portalı bildirimlerinizde hizmet sorunuyla ilgili bir kesinti uyarısı olur.
- Yardım + destek veya Destek + sorun giderme: Yardım + destek veya Destek + sorun giderme'den destek bileti oluşturduğunuzda, kaynaklarınızı etkileyen sorunlar hakkında bilgi olacaktır. Daha fazla bilgi ve etkinin özeti için Kesinti ayrıntılarını görüntüle'yi seçin. Yeni destek isteği sayfasında da bir uyarı olacaktır.
- Hizmet Yardımı: Azure portalındaki Hizmet Durumu sayfası, genel olarak Azure veri merkezi durumu hakkında bilgi içerir. Azure portalındaki arama çubuğunda "hizmet durumu" araması yapın, ardından Etkin olaylar kategorisindeki Hizmet sorunlarını görüntüleyin. Ayrıca, Yardım menüsünün altındaki herhangi bir kaynağın Kaynak durumu sayfasında tek tek kaynakların durumunu da görüntüleyebilirsiniz. Aşağıda, Güneydoğu Asya'daki etkin bir hizmet sorunu hakkında bilgi içeren Hizmet Durumu sayfasının örnek ekran görüntüsü verilmiştir.
- E-posta bildirimi: Uyarılar ayarladıysanız, bir hizmet kesintisi aboneliğinizi ve kaynağınızı etkilediğinde bir e-posta bildirimi gönderilir. E-postalar "azure-noreply@microsoft.com" ile gelir. E-postanın gövdesi "Etkinlik günlüğü uyarısı ... Azure aboneliği için bir hizmet sorunu tarafından tetiklendi...". Hizmet durumu uyarıları hakkında daha fazla bilgi için bkz. Azure portalını kullanarak Azure hizmet bildirimlerinde etkinlik günlüğü uyarıları alma.
Önemli
Adından da anlaşılacağı gibi, PostgreSQL'deki geçici tablo alanları, geçici nesnelerin yanı sıra sıralama gibi diğer iç veritabanı işlemleri için kullanılır. Bu nedenle, Sunucu yeniden başlatıldıktan, HA yük devretmelerinden vb. sonra bu tür nesnelerin dayanıklılığını garanti etmediğimiz için geçici tablo alanında kullanıcı şeması nesneleri oluşturmanızı önermiyoruz.
Planlanmamış kapalı kalma süresi: hata senaryoları ve hizmet kurtarma
Bazı planlanmamış hata senaryoları ve kurtarma işlemi aşağıdadır.
| Senaryo |
Kurtarma işlemi [Alanlar arası yedekli HA olmadan yapılandırılan sunucular] |
Kurtarma işlemi [Alanlar arası yedekli HA ile yapılandırılan sunucular] |
|---|---|---|
| Veritabanı sunucusu hatası | Veritabanı sunucusu çalışmıyorsa, Azure veritabanı sunucusunu yeniden başlatmayı dener. Bu başarısız olursa, veritabanı sunucusu başka bir fiziksel düğümde yeniden başlatılır. Kurtarma süresi (RTO), büyük işlem gibi hata sırasındaki etkinlik ve veritabanı sunucusu başlatma işlemi sırasında gerçekleştirilecek kurtarma hacmi gibi çeşitli faktörlere bağlıdır. PostgreSQL veritabanlarını kullanan uygulamaların bırakılan bağlantıları ve başarısız işlemleri algılayıp yeniden deneyecek şekilde derlenmiş olması gerekir. |
Veritabanı sunucusu hatası algılanırsa, sunucu hazır bekleyen sunucuya yük devredilir ve böylece kapalı kalma süresi azalır. Daha fazla bilgi için bkz. [HA kavramları sayfası]/azure/reliability/reliability-postgresql-flexible-server. RTO'ların sıfır veri kaybıyla 60-120 arasında olması beklenir. |
| Depolama hatası | Uygulamalar, disk hatası veya fiziksel blok bozulması gibi depolamayla ilgili sorunlar için herhangi bir etki görmez. Veriler üç kopyada depolandığından, verilerin kopyası kalan depolama alanı tarafından sunulur. Bozuk veri bloğu otomatik olarak onarılır ve verilerin yeni bir kopyası otomatik olarak oluşturulur. | Depolama alanının tamamına erişilememesi gibi nadir ve kurtarılamayan hatalar için PostgreSQL için Azure Veritabanı esnek sunucu örneği, kapalı kalma süresini azaltmak için bekleme çoğaltmasına devredilir. Daha fazla bilgi için bkz. [HA kavramları sayfası]/azure/reliability/reliability-postgresql-flexible-server. |
| Mantıksal/kullanıcı hataları | Kullanıcı hatalarından, örneğin yanlışlıkla bırakılan veritabanı tabloları veya yanlış güncelleştirilmiş verilerden kurtulmak için bir belirli bir zamana geri yükleme (PITR) gerçekleştirmeniz gerekir. Geri yükleme işlemini gerçekleştirirken, hatanın oluşmadan hemen önce olduğu özel geri yükleme noktasını belirtirsiniz. Veritabanı sunucusundaki tüm veritabanları yerine veritabanlarının veya belirli tabloların yalnızca bir alt kümesini geri yüklemek istiyorsanız, veritabanı sunucusunu yeni bir örnekte geri yükleyebilir, tabloları pg_dump aracılığıyla dışarı aktarabilir ve ardından pg_restore kullanarak bu tabloları veritabanınıza geri yükleyebilirsiniz. |
Tüm değişiklikler bekleme çoğaltmasına zaman uyumlu olarak çoğaltıldığından, bu kullanıcı hataları yüksek kullanılabilirlikle korunmaz. Bu tür hatalardan kurtulmak için belirli bir noktaya geri yükleme yapmanız gerekir. |
| Kullanılabilirlik alanı hatası | Bölge düzeyinde bir hatadan kurtarmak için, yedeklemeyi kullanarak belirli bir noktaya geri yükleme gerçekleştirebilir ve en son verileri geri yüklemek için en son zamanı içeren özel bir geri yükleme noktası seçebilirsiniz. Yeni PostgreSQL için Azure Veritabanı esnek sunucu örneği, 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. | PostgreSQL için Azure Veritabanı esnek sunucu örneği, 60-120 saniye içinde otomatik olarak sıfır veri kaybıyla bekleme sunucusuna aktarılarak devredilir. Daha fazla bilgi için bkz. [HA kavramları sayfası]/azure/reliability/reliability-postgresql-flexible-server. |
| Bölge hatası | 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ıp kurtarılır. 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. |
Aynı işlem. |
Bölgesel hatadan kurtarma sonrasında veritabanınızı yapılandırma
- Bir kesintiden kurtarmak için coğrafi geri yükleme veya coğrafi çoğaltma kullanıyorsanız, normal uygulama işlevinin sürdürülebilmesi için yeni sunucuya bağlantının düzgün yapılandırıldığından emin olmanız gerekir. Geri yükleme sonrası görevlerini izleyebilirsiniz.
- Daha önce özgün sunucuda bir tanılama ayarı ayarladıysanız, PostgreSQL için Azure Veritabanı'nda Günlükleri Yapılandırma ve Erişim bölümünde açıklandığı gibi gerekirse hedef sunucuda da aynı işlemi yaptığınızdan emin olun.
- Telemetri uyarılarını ayarlama, mevcut uyarı kuralı ayarlarınızın yeni sunucuyla eşlenecek şekilde güncelleştirildiğinden emin olmanız gerekir. Uyarı kuralları hakkında daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı ölçümleriyle ilgili uyarılar ayarlamak için Azure portalını kullanma.
Önemli
Silinen sunucular geri yüklenebilir. Sunucuyu silerseniz, kurtarmak için bırakılan bir Azure veritabanını geri yükleme yönergelerimizi izleyebilirsiniz. Sunucunuzun yanlışlıkla silinmesini önlemeye yardımcı olmak için Azure kaynak kilidini kullanın.