MariaDB için Azure Veritabanı ile iş sürekliliğine genel bakış

  • Makale

Önemli

MariaDB için Azure Veritabanı kullanımdan kaldırılıyor. MySQL için Azure Veritabanı geçiş yapmanızı kesinlikle öneririz. MySQL için Azure Veritabanı geçiş hakkında daha fazla bilgi için bkz. MariaDB için Azure Veritabanı ne oluyor?.

Bu makalede, MariaDB 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. Bir kullanıcı hatası veya uygulama hatası veri bütünlüğünü etkilediyse, Azure bölgesinde kesinti olduğunda veya uygulamanızın bakıma ihtiyacı olduğunda ne yapmanız gerektiğini öğrenin.

İş sürekliliğine yönelik özellikler

İş sürekliliği planınızı geliştirirken şunları anlamanız gerekir:

  • Kurtarma süresi hedefi (RTO): Kesintiye neden olan bir olaydan sonra uygulama tamamen kurtarılmadan önce kabul edilebilir en uzun süre.
  • Kurtarma noktası hedefi (RPO):Uygulamanın kesintiye neden olan bir olaydan sonra kurtarılırken kaybetmeye dayanabileceği en fazla son veri güncelleştirmeleri (zaman aralığı) miktarıdır.

MariaDB için Azure Veritabanı coğrafi geri yükleme başlatma ve okuma amaçlı çoğaltmaları başka 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 ile MariaDB için Azure Veritabanı, başka bir bölgeden çoğaltılan yedekleme verilerini kullanarak yeni bir sunucu oluşturur. Geri yükleme ve kurtarmanın genel süresi, veritabanının boyutuna ve kurtarılması gereken günlük verilerinin 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, birincil veritabanındaki işlem günlükleri zaman uyumsuz olarak bir çoğaltmaya akışla aktarılır. Bölge düzeyinde veya bölge düzeyinde hata nedeniyle birincil veritabanı kesintisi varsa çoğaltmaya yük devretme daha kısa bir RTO ve azaltılmış veri kaybı sağlar.

Dekont

Birincil veritabanı 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 gecikme oluşturabilir.

Okuma amaçlı çoğaltmalar için kullanılan çoğaltmanın zaman uyumsuz yapısı nedeniyle, okuma amaçlı çoğaltmaları yüksek kullanılabilirlik çözümü olarak değerlendirmeyin. Daha yüksek gecikmeler daha yüksek RTO ve RPO anlamına gelebilir. Okuma amaçlı çoğaltmalar, yalnızca gecikmenin yoğun ve yoğun olmayan zamanlarda daha küçük kaldığı iş yükleri için yüksek kullanılabilirlik alternatifi olarak görev yapabilir. Aksi takdirde, okuma amaçlı çoğaltmalar yoğun okuma içeren iş yükleri ve olağanüstü durum kurtarma 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:

Özellik Temel Genel amaçlı Bellek için iyileştirilmiş
Yedeklemeden belirli bir noktaya geri yükleme Saklama süresi içindeki herhangi bir geri yükleme noktası
RTO değişir
RPO 15 dakikadan kısa		 Saklama süresi içindeki herhangi bir geri yükleme noktası
RTO değişir
RPO 15 dakikadan kısa		 Saklama süresi içindeki herhangi bir geri yükleme noktası
RTO değişir
RPO 15 dakikadan kısa
Coğrafi olarak çoğaltılan yedeklemelerden coğrafi geri yükleme Desteklenmez RTO değişir
RPO 24 saatten uzun		 RTO değişir
RPO 24 saatten uzun
Okuma amaçlı çoğaltmalar RTO dakika cinsindendir
RPO 5 dakikadan kısa		 RTO dakika cinsindendir
RPO 5 dakikadan kısa		 RTO dakika cinsindendir
RPO 5 dakikadan kısa

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

Kullanıcı veya uygulama hatasından sonra sunucunun kurtarılması

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

Sunucunuzun kopyasını oluşturmak için iyi olduğu bilinen belirli bir noktaya geri yükleme gerçekleştirebilirsiniz. Bu zaman noktası, sunucunuz için yapılandırdığınız yedekleme saklama süresi içinde olmalı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ı yalnızca silindikten sonra beş gün içinde geri yükleyebilirsiniz. Beş gün sonra yedeklemeler silinir. Veritabanı yedeklemesine yalnızca sunucuyu barındıran Azure aboneliğinden erişebilir ve geri yükleyebilirsiniz. Bırakılan bir sunucuyu geri yüklemek için belgelenen adımlara bakın. Sunucu kaynaklarının yanlışlıkla silinmesine veya dağıtımdan sonra beklenmeyen değişikliklere karşı korunmasına yardımcı olmak için yöneticiler yönetim kilitlerini kullanabilir.

Azure bölgesel veri merkezi kesintisinden kurtarma

Nadir olsa da Azure veri merkezinde kesinti olabilir. 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. Veri merkezinde kesinti olduğunda, kesintinin ne kadar sürebileceğini bilemezsiniz. Bu nedenle bu seçenek yalnızca sunucunun bir süre çevrimdışı olmasını göze alabilen uygulamalarda (örneğin, bir geliştirme ortamı) ç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, sunucunuzun barındırıldığı bölge çevrimdışı olduğunda bile erişilebilir. Bu yedeklemelerden başka bir bölgeye geri yükleyip sunucunuzu yeniden çevrimiçi yapabilirsiniz. Yedekleme ve geri yükleme kavramları hakkında makalede 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, mysqldump kullanarak mevcut sunucunuzun yedeğini oluşturmanız gerekir. Ardından, coğrafi olarak yedekli yedeklemelerle yapılandırılmış yeni oluşturulan bir sunucuya geri yükleyin.

Bölgeler arası okuma çoğaltmaları

İş sürekliliği 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, ikili günlükler için MySQL'in çoğaltma teknolojisi aracılığıyla zaman uyumsuz olarak güncelleştirilir. Okuma amaçlı çoğaltmalar, kullanılabilir bölgeler ve yük devretme hakkında daha fazla bilgiyi okuma amaçlı çoğaltma kavramları makalesinde bulabilirsiniz.

SSS

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

varsayılan olarak, MariaDB için Azure Veritabanı müşteri verilerini dağıtıldığı bölgenin dışına taşımaz veya depolamaz. Ancak, 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 çoğaltmaları oluşturmayı seçebilirsiniz.

Sonraki adımlar