MariaDB için Azure Veritabanı'de yüksek kullanılabilirlik

Ö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?.

MariaDB için Azure Veritabanı hizmeti, yüksek çalışma süresi gerektiren görev açısından kritik veritabanları çalıştırmak için uygundur. Aşağıdakiler sırasında yüksek kullanılabilirlik sağlar:

  • Kullanıcı tarafından başlatılan ölçek işlem işlemleri gibi planlı olaylar.
  • Temel alınan donanım, yazılım veya ağ hataları gibi planlanmamış olaylar.

MariaDB için Azure Veritabanı, çalışma süresi için finansal olarak desteklenmiş bir hizmet düzeyi sözleşmesi sağlar. Hizmet Azure mimarisi üzerine oluşturulduğundan, ek bileşenler yapılandırmadan yüksek kullanılabilirlik, yedeklilik ve dayanıklılık özelliklerinden yararlanabilirsiniz.

MariaDB için Azure Veritabanı bileşenleri

Bileşen Açıklama
MariaDB veritabanı sunucusu MariaDB için Azure Veritabanı veritabanı sunucuları için güvenlik, yalıtım, kaynak korumaları ve hızlı yeniden başlatma özelliği sağlar. Bu özellikler, bir kesintiden sonra ölçeklendirme ve veritabanı sunucusu kurtarma (saniye cinsinden) gibi işlemleri kolaylaştırır.
Veritabanı sunucusundaki veri değişiklikleri genellikle veritabanı işlemi bağlamında gerçekleşir. Tüm veritabanı değişiklikleri, Azure Depolama'da veritabanı sunucusuna eklenmiş olan önceden yazma günlükleri (ib_log dosyaları) biçiminde zaman uyumlu olarak kaydedilir. Veritabanı denetim noktası işlemi sırasında, veritabanı sunucusu belleğindeki veri sayfaları da depolama alanına boşaltılır.
Uzak depolama alanı Tüm MariaDB fiziksel veri dosyaları ve günlük dosyaları, veri yedekliliği, kullanılabilirlik ve güvenilirlik sağlamak için verilerin üç kopyasını bir bölgede depolayan Azure Depolama'de depolanır. Depolama katmanı veritabanı sunucusundan bağımsızdır. Başarısız bir veritabanı sunucusundan ayrılabilir ve birkaç saniye içinde yeni bir veritabanı sunucusuna yeniden bağlanabilir.
Azure Depolama depolama hatalarını sürekli izler. Bir blok bozulması algılarsa, yeni bir depolama kopyası örneği oluşturarak sorunu otomatik olarak düzeltir.
Ağ Geçidi Ağ geçidi, tüm istemci bağlantılarını veritabanı sunucusuna yönlendirerek bir veritabanı ara sunucusu işlevi görür.

Planlanan kapalı kalma süresini azaltma

MariaDB için Azure Veritabanı mimarisi, planlanan kapalı kalma süresi işlemleri sırasında yüksek kullanılabilirlik sağlar.

Diagram of elastic scaling in Azure Database for MariaDB.

Planlı bakım için bazı senaryolar şunlardır:

Senaryo Açıklama
İşlem ölçeğini artırma veya ölçeği azaltma İşlem ölçeğini artırma veya azaltma işlemi gerçekleştirdiğinizde, MariaDB için Azure Veritabanı ölçeklendirilmiş işlem yapılandırmasını kullanarak yeni bir veritabanı sunucusu sağlar. Eski veritabanı sunucusunda, hizmet etkin denetim noktalarının bitmesini sağlar, istemci bağlantılarını boşaltılır ve kaydedilmemiş işlemleri iptal eder. Hizmet daha sonra eski veritabanı sunucusunu kapatır. Depolamayı eski veritabanı sunucusundan ayırır ve yeni veritabanı sunucusuna ekler. İstemci uygulaması bağlantıyı yeniden denediğinde veya yeni bir bağlantı kurmaya çalıştığında, ağ geçidi bağlantı isteğini yeni veritabanı sunucusuna yönlendirir.
Depolamanın ölçeğini artırma Depolamanın ölçeğini artırmak çevrimiçi bir işlemdir ve veritabanı sunucusunu kesintiye uğratmaz.
Yeni yazılım dağıtımı (Azure) Yeni özelliklerin veya hata düzeltmelerinin dağıtımı, hizmetin planlı bakımının bir parçası olarak otomatik olarak gerçekleşir. Daha fazla bilgi için belgelere bakın ve portalınızı denetleyin.
İkincil sürüm yükseltmeleri MariaDB için Azure Veritabanı veritabanı sunucularına otomatik olarak Azure'ın belirleeceği ikincil sürüme yama ekler. Otomatik düzeltme eki uygulama, hizmetin planlı bakımının bir parçası olarak gerçekleşir. Saniyeler içinde kısa bir kapalı kalma süresine neden olur ve veritabanı sunucusu yeni ikincil sürümle otomatik olarak yeniden başlatılır. Daha fazla bilgi için belgelere bakın ve portalınızı denetleyin.

Planlanmamış kapalı kalma süresini azaltma

Planlanmamış kapalı kalma süresi, temel alınan donanım hataları, ağ sorunları ve yazılım hataları gibi öngörülemeyen hatalardan kaynaklanabilir. Veritabanı sunucusu beklenmedik bir şekilde kapanırsa yeni veritabanı sunucusu saniyeler içinde otomatik olarak sağlanır. Uzak depolama otomatik olarak yeni veritabanı sunucusuna bağlanır.

MariaDB altyapısı, önceden yazılan günlük ve veritabanı dosyalarını kullanarak kurtarma işlemini gerçekleştirir ve istemcilerin bağlanmasına izin vermek için veritabanı sunucusunu açar. Kaydedilmemiş işlemler kaybolur ve uygulamanın bunları yeniden denemesi gerekir.

Planlanmamış kapalı kalma süresini önleyemezsiniz ancak MariaDB için Azure Veritabanı, insan müdahalesi gerektirmeden hem veritabanı sunucusunda hem de depolama katmanlarında kurtarma işlemlerini otomatik olarak gerçekleştirerek bunu azaltır.

Diagram of high availability in Azure Database for MariaDB.

Planlanmamış kapalı kalma süresi: Hata senaryoları ve hizmet kurtarma

İki hata senaryosu ve MariaDB için Azure Veritabanı otomatik olarak nasıl kurtarılır:

Senaryo Otomatik kurtarma
Veritabanı sunucusu hatası Veritabanı sunucusu temel alınan donanım hatası nedeniyle çalışmıyorsa MariaDB için Azure Veritabanı etkin bağlantıları bırakır ve tüm uçak içi işlemleri iptal eder. Hizmet otomatik olarak yeni bir veritabanı sunucusu dağıtır ve uzak veri depolama alanını yeni veritabanı sunucusuna ekler. Veritabanı kurtarma işlemi tamamlandıktan sonra istemciler ağ geçidi üzerinden yeni veritabanı sunucusuna bağlanabilir.
MariaDB 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. Uygulama bir bağlantıyı yeniden denendiğinde, ağ geçidi bağlantıyı yeni oluşturulan veritabanı sunucusuna saydam bir şekilde yeniden yönlendirir.
Depolama hatası Disk hatası veya fiziksel blok bozulması gibi Depolama ilgili sorunlar uygulamaları etkilemez. Veriler üç kopya halinde depolandığından, kalan depolama alanı verilerin kopyasına hizmet eder. MariaDB için Azure Veritabanı blok bozulmalarını otomatik olarak düzeltmektedir. Verilerin bir kopyası kaybolursa, hizmet otomatik olarak verilerin yeni bir kopyasını oluşturur.

Kurtarma için kullanıcı eylemi gerektiren hata senaryoları şunlardır:

Senaryo Kurtarma planı
Bölge hatası Bölgenin başarısız olması nadir görülen bir olaydır. Ancak, bir bölge hatasına karşı korumaya ihtiyacınız varsa, olağanüstü durum kurtarma için diğer bölgelerde bir veya daha fazla okuma amaçlı çoğaltma yapılandırabilirsiniz. Ayrıntılar için okuma amaçlı çoğaltmaları oluşturma ve yönetme hakkındaki bu makaleye bakın. Bölge düzeyinde bir hata oluşursa, başka bir bölgede yapılandırılan okuma amaçlı çoğaltmayı üretim veritabanı sunucunuz olacak şekilde el ile yükseltebilirsiniz.
Mantıksal/kullanıcı hatası Yanlışlıkla bırakılan tablolar veya yanlış güncelleştirilmiş veriler gibi kullanıcı hatalarından kurtarma, belirli bir noktaya kurtarma gerçekleştirmeyi içerir. Bu eylem, hata oluşmadan hemen önceki zamana kadar verileri geri yükler ve kurtarır.
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, mysqldump aracılığıyla tabloları dışarı aktarabilir ve ardından bu tabloları veritabanınızda geri yükleyebilirsiniz.

Özet

MariaDB için Azure Veritabanı, veritabanlarınızı yaygın kesintilere karşı korumaya yardımcı olan doğal yüksek kullanılabilirlik özelliklerine sahiptir. Veritabanı sunucularının, yedekli depolamanın ve ağ geçidinden verimli yönlendirmenin hızlı yeniden başlatılmasını sağlar. Ek veri koruması için yedeklemeleri coğrafi olarak çoğaltılacak şekilde yapılandırabilir ve okuma amaçlı çoğaltmaları diğer bölgelere dağıtabilirsiniz.

Sonraki adımlar

  • Azure bölgeleri hakkında bilgi edinin.
  • Geçici bağlantı hatalarını işleme hakkında bilgi edinin.
  • Verilerinizi okuma amaçlı çoğaltmalarla çoğaltmayı öğrenin.