PostgreSQL için Azure Veritabanı - Tek Sunucu ile iş sürekliliğine genel bakış

  • Makale

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

Önemli

PostgreSQL için Azure Veritabanı - Tek Sunucu kullanımdan kaldırma yolundadır. PostgreSQL için Azure Veritabanı - Esnek Sunucu'ya yükseltmenizi kesinlikle öneririz. PostgreSQL için Azure Veritabanı - Esnek Sunucu'ya geçiş hakkında daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı Tek Sunucuya ne oluyor?.

Bu genel bakış, PostgreSQL için Azure Veritabanı iş sürekliliği ve olağanüstü durum kurtarma için sağladığı özellikleri açıklar. Veri kaybına veya veritabanınızın ve uygulamanızın kullanılamaz duruma gelmesine neden olabilecek kesintiye neden olan olaylardan kurtarma seçenekleri hakkında bilgi edinin. Kullanıcı veya uygulama hatası veri bütünlüğünü etkilediyse, Azure bölgesinde kesinti olduğunda veya uygulamanız bakım gerektirdiğinde ne yapmanız gerektiğini öğrenin.

İş sürekliliği sağlamak için kullanabileceğiniz özellikler

İş sürekliliği planınızı geliştirirken, uygulama kesintiye neden olan olaydan sonra tam olarak kurtarılmadan önce kabul edilebilir en uzun süreyi anlamanız gerekir. Bu, Kurtarma Süresi Hedefinizdir (RTO). Ayrıca, kesintiye neden olan olaydan sonra kurtarılırken uygulamanın kaybetmeye dayanabileceği en fazla son veri güncelleştirmelerinin (zaman aralığı) miktarını da anlamanız gerekir. Bu, Kurtarma Noktası Hedefinizdir (RPO).

PostgreSQL için Azure Veritabanı coğrafi geri yükleme başlatma olanağıyla coğrafi olarak yedekli yedeklemeleri ve farklı bir bölgeye okuma amaçlı çoğaltmalar dağıtmayı içeren iş sürekliliği özellikleri sağlar. Her birinin hem kurtarma süresi hem de olası veri kaybını azaltma konusunda farklı seçenekleri vardır. Coğrafi geri yükleme özelliğiyle, başka bir bölgeden çoğaltılan yedekleme verileri kullanılarak yeni bir sunucu oluşturulur. Geri yükleme ve kurtarma işlemlerinin toplam süresi veritabanının boyutuna ve kurtarılacak günlük miktarına bağlıdır. Sunucuyu kurma işleminin toplam süresi birkaç dakikadan birkaç saate kadar değişiklik gösterir. Okuma amaçlı çoğaltmalarda, birincilden gelen işlem günlükleri zaman uyumsuz olarak çoğaltmaya akışla aktarılır. Bölge düzeyinde veya bölge düzeyinde hata nedeniyle birincil veritabanı kesintisi olması durumunda çoğaltmaya yük devretme daha kısa bir RTO ve azaltılmış veri kaybı sağlar.

Not

Birincil ile çoğaltma arasındaki gecikme, siteler arasındaki gecikme süresine, iletilecek veri miktarına ve en önemlisi birincil sunucunun yazma iş yüküne bağlıdır. Yoğun yazma iş yükleri önemli bir gecikmeye neden olabilir.

Okuma amaçlı çoğaltmalar için kullanılan çoğaltmanın zaman uyumsuz yapısı nedeniyle, yüksek gecikmeler daha yüksek RTO ve RPO anlamına olabileceğinden, bunlar Yüksek Kullanılabilirlik (HA) çözümü olarak değerlendirilmemelidir . Yalnızca iş yükünün en yoğun ve yoğun olmayan zamanlarında gecikmenin daha küçük kaldığı iş yükleri için okuma amaçlı çoğaltmalar BIR HA alternatifi olarak görev yapabilir. Aksi takdirde okuma amaçlı çoğaltmalar, hazır ağır iş yükleri ve (Olağanüstü Durum Kurtarma) DR senaryoları için gerçek okuma ölçeğine yöneliktir.

Aşağıdaki tabloda, tipik bir iş yükü senaryosunda RTO ve RPO karşılaştırılıyor:

Yeteneği Temel Genel Amaçlı Bellek için iyileştirilmiş
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 < 15 dk		 Saklama süresi içindeki herhangi bir geri yükleme noktası
RTO - Değişiklik Gösterir
RPO < 15 dk		 Saklama süresi içindeki herhangi bir geri yükleme noktası
RTO - Değişiklik Gösterir
RPO < 15 dk
Coğrafi olarak çoğaltılan yedeklemelerden coğrafi geri yükleme Desteklenmez RTO - Değişiklik Gösterir
RPO < 1 s		 RTO - Değişiklik Gösterir
RPO < 1 s
Okuma amaçlı çoğaltmalar RTO - Dakika*
RPO < 5 dk*		 RTO - Dakika*
RPO < 5 dk*		 RTO - Dakika*
RPO < 5 dk*

* RTO ve RPO , siteler arasındaki gecikme süresi, iletilecek veri miktarı ve önemli ölçüde birincil veritabanı yazma iş yükü gibi çeşitli faktörlere bağlı olarak bazı durumlarda çok daha yüksek olabilir.

Kullanıcı veya uygulama hatasından sonra sunucuyu kurtarma

Çeşitli kesintiye neden olan olaylardan bir sunucuyu kurtarmak için hizmetin yedeklerini kullanabilirsiniz. Kullanıcı yanlışlıkla bazı verileri silebilir, istemeden önemli bir tabloyu bırakabilir, hatta veritabanının tamamını bırakabilir. Uygulama, bir uygulama hatası nedeniyle hatalı verilerle yanlışlıkla iyi verilerin üzerine yazabilir ve bu şekilde devam edebilir.

Sunucunuzun bir kopyasını bilinen iyi bir noktaya oluşturmak için belirli bir noktaya geri yükleme gerçekleştirebilirsiniz. Bu belirli nokta, sunucunuz için yapılandırdığınız yedekleme saklama süresi içinde yer almalıdır. Veriler yeni sunucuya geri yüklendikten sonra, özgün sunucuyu yeni geri yüklenen sunucuyla değiştirebilir veya geri yüklenen sunucudan gerekli verileri özgün sunucuya kopyalayabilirsiniz.

Sunucunuzun yanlışlıkla silinmesini önlemeye yardımcı olması için Azure kaynak kilidini kullanmanızı öneririz. Sunucunuzu yanlışlıkla sildiyseniz, silme işlemi son 5 gün içinde olduysa sunucuyu geri yükleyebilirsiniz. Daha fazla bilgi için bkz. Bırakılan PostgreSQL için Azure Veritabanı sunucusunu geri yükleme.

Azure veri merkezi kesintisinden kurtarma

Çok sık olmasa da Azure veri merkezlerinde kesintiler yaşanabilir. Bir kesinti oluştuğunda, yalnızca birkaç dakika sürebilen ancak saatlerce sürebilen bir iş kesintisine neden olur.

Bir seçenek, veri merkezi kesintisi sona erdiğinde sunucunuzun yeniden çevrimiçi olmasını beklemektir. Bu, sunucunun belirli bir süre için çevrimdışı olmasını göze alabilen uygulamalar için (örneğin bir geliştirme ortamı) çalışır. Bir veri merkezinde kesinti olduğunda, kesintinin ne kadar sürebileceğini bilemezsiniz, bu nedenle bu seçenek yalnızca sunucunuza bir süre ihtiyacınız yoksa çalışır.

Coğrafi geri yükleme

Coğrafi geri yükleme özelliği, coğrafi olarak yedekli yedeklemeler kullanarak sunucuyu geri yükler. Yedeklemeler sunucunuzun eşleştirilmiş bölgesinde barındırılır. Bu yedeklemelerden başka bir bölgeye geri yükleyebilirsiniz. Coğrafi geri yükleme, yedeklerden alınan verileri içeren yeni bir sunucu oluşturur. Yedekleme ve geri yükleme kavramları makalesinden coğrafi geri yükleme hakkında daha fazla bilgi edinin.

Önemli

Coğrafi geri yükleme yalnızca sunucuyu coğrafi olarak yedekli yedekleme depolama alanıyla sağladıysanız mümkündür. Mevcut bir sunucu için yerel olarak yedekli yedeklemelerden coğrafi olarak yedekli yedeklemelere geçmek istiyorsanız, mevcut sunucunuzun pg_dump kullanarak dökümü almanız ve coğrafi olarak yedekli yedeklemelerle yapılandırılmış yeni oluşturulan bir sunucuya geri yüklemeniz gerekir.

Bölgeler arası okuma çoğaltmaları

İş sürekliliğinizi ve olağanüstü durum kurtarma planlamanızı geliştirmek için bölgeler arası okuma amaçlı çoğaltmaları kullanabilirsiniz. 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. Okuma amaçlı çoğaltmalar, kullanılabilir bölgeler ve okuma amaçlı çoğaltma kavramları makalesinden yük devretme hakkında daha fazla bilgi edinin.

SSS

PostgreSQL için Azure Veritabanı müşteri verilerini nerede depolar?

Varsayılan olarak, PostgreSQL için Azure Veritabanı müşteri verilerini dağıtılan bölgenin dışına taşımaz veya depolamaz. Ancak müşteriler isteğe bağlı olarak coğrafi olarak yedekli yedeklemeleri etkinleştirmeyi veya verileri başka bir bölgede depolamak için bölgeler arası okuma amaçlı çoğaltma oluşturmayı seçebilir.

Sonraki adımlar