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

  • Makale

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

Önemli

MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?

Bu makalede, MySQL için Azure Veritabanı iş sürekliliği ve olağanüstü durum kurtarma için sağladığı özellikler açıklanmaktadır. 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).

MySQL için Azure Veritabanı tek sunucu, coğrafi geri yükleme başlatma ve okuma amaçlı çoğaltmaları farklı bir bölgeye dağıtma özelliğiyle coğrafi olarak yedekli yedeklemeler içeren iş sürekliliği ve olağanüstü durum kurtarma ö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:

Yetenek 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 kopyasını oluşturmak için iyi olduğu bilinen 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.

Önemli

Silinen sunucular, silindikten sonra yalnızca beş gün içinde geri yüklenebilir ve yedeklemeler silinir. Veritabanı yedeklemesine yalnızca sunucuyu barındıran Azure aboneliğinden erişilebilir ve geri yüklenebilir. Bırakılan bir sunucuyu geri yüklemek için belgelenen adımlara bakın. Sunucu kaynaklarını, dağıtım sonrası, yanlışlıkla silinmeye veya beklenmeyen değişikliklere karşı korumak için yöneticiler yönetim kilitlerinden yararlanabilir.

Azure bölgesel 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. Veri merkezinde bir 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 yedeklemelere, sunucunuzda barındırılan bölge çevrimdışı olduğunda bile erişilebilir. Bu yedeklemelerden başka bir bölgeye geri yükleyebilir ve sunucunuzu yeniden çevrimiçi yapabilirsiniz. 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 mysqldump komutunu 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, MySQL'in ikili günlük çoğaltma teknolojisi kullanılarak zaman uyumsuz olarak güncelleştirilir. 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

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

Varsayılan olarak, MySQL 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