Azure Database for MySQL için yüksek kullanılabilirlik

Azure Database for MySQL Esnek Sunucu kullanarak, otomatik hata aktarma ile yüksek kullanılabilirlik yapılandırabilirsiniz. Bu çözüm, hataların hiçbir zaman işlenen veri kaybına neden olmamasını ve veritabanının yazılım mimarinizde tek bir hata noktası olmamasını sağlar. Yüksek kullanılabilirlik yapılandırdığınızda, Flexible Server (Esnek Sunucu) otomatik olarak bir yedek Hyper-V kopyası sağlar ve yönetir. Ayrılan hesaplama ve depolama için, hem birincil hem de ikincil çoğaltmalar için ödeme yaparsınız. İki yüksek kullanılabilirlik mimari modeli mevcuttur:

  • Alanlar arası yedekli yüksek kullanılabilirlik. Bu seçenek, birden çok kullanılabilirlik bölgesi arasında altyapının tam yalıtımını ve yedekliliğini sağlar. En yüksek kullanılabilirlik düzeyini sunar, ancak alanlar arasında uygulama yedekliliğini yapılandırmanızı gerektirir. Kullanılabilirlik alanındaki altyapı hatalarına karşı koruma sağlamak istediğinizde ve kullanılabilirlik alanı genelinde gecikme süresi kabul edilebilir olduğunda alanlar arası yedekli yüksek kullanılabilirlik seçin. Alanlar arası yedekli yüksek kullanılabilirliği yalnızca sunucuyu oluşturduğunuzda etkinleştirebilirsiniz. Alanlar arası yedekli yüksek kullanılabilirlik, bölgenin birden çok kullanılabilirlik alanını ve Alan-yedekli Premium dosya paylaşımlarını desteklediği Azure bölgelerinin bir alt kümesinde kullanılabilir.

  • Yerel olarak yedekli yüksek kullanılabilirlik. Bu seçenek, birincil ve bekleme sunucuları aynı kullanılabilirlik alanında olduğundan daha düşük ağ gecikme süresiyle altyapı yedekliliği sağlar. Alanlar arasında uygulama yedekliliğini yapılandırmaya gerek kalmadan yüksek kullanılabilirlik sunar. En düşük ağ gecikme süresine sahip tek bir kullanılabilirlik alanında en yüksek kullanılabilirlik düzeyini elde etmek istediğinizde yerel olarak yedekli yüksek kullanılabilirlik seçeneğini belirleyin. Azure Database for MySQL Esnek Sunucu'yu kullanabileceğiniz tüm Azure bölgelerinde yerel olarak yedekli yüksek kullanılabilirlik sağlanmaktadır.

Alanlar arası yedekli yüksek kullanılabilirlik (HA) mimarisi

Alanlar arası yedekli yüksek kullanılabilirliğe sahip bir sunucu dağıttığınızda Azure iki sunucu oluşturur:

  • Tek bir kullanılabilirlik alanındaki birincil sunucu.
  • Aynı Azure bölgesinin başka bir kullanılabilirlik alanında bekleyen çoğaltma sunucusu. Yedek kopya sunucusu, işlem katmanı, işlem boyutu, depolama boyutu ve ağ yapılandırması dahil olmak üzere birincil sunucuyla aynı yapılandırmaya sahiptir.

Alanlar arası yedekli yüksek kullanılabilirlik mimarisini gösteren diyagram.

Birincil sunucu ve yedek çoğaltma için kullanılabilirlik alanını seçebilirsiniz. Birincil sunucuyu ve bekleme sunucusunu aynı bölgeye yerleştirmek gecikme süresini azaltırken, bunları farklı bölgelere yerleştirmek olağanüstü durum kurtarma durumlarına ve bölge azaltma senaryolarına hazırlanmanıza yardımcı olur.

Veri ve günlük dosyaları zone-redundant storage (ZRS) içinde barındırılır. Hazır bekleyen sunucu, birincil sunucunun depolama hesabından günlük dosyalarını sürekli okur, yeniden yürütür ve bu dosyaların depolama düzeyinde çoğaltma ile korunmasını sağlar.

Yük devretme gerçekleşirse:

  • Hazır bekleyen çoğaltma etkinleştirilir.
  • Birincil sunucunun ikili günlük dosyaları, bekleme sunucusunu çevrimiçi hale getirmek için birincil sunucudaki son işlenen işleme kadar uygulanmaya devam eder.

Birincil sunucu kullanılamadığında bile ZRS'deki günlüklere erişilebilir. Bu kullanılabilirlik, veri kaybı olmamasını sağlamaya yardımcı olur. Yedek çoğaltma durumu aktif hale geldikten ve ikili günlükler uygulandıktan sonra, mevcut yedek çoğaltma sunucusu birincil sunucunun rolünü alır. DNS, istemci yeniden bağlandığında istemci bağlantılarının yeni birincil sunucuya doğrudan yönlendirilmesi için güncelleştirir. Yük devretme, istemci uygulaması açısından tamamen görünmezdir ve sizden herhangi bir işlem yapmanızı gerektirmez. Ha çözümü daha sonra mümkün olduğunda eski birincil sunucuyu geri getirir ve hazır bekleyen sunucu olarak yerleştirir.

Uygulamaları birincil sunucuya bağlamak için veritabanı sunucusu adını kullanırsınız. Çözüm, doğrudan erişim için yedek çoğaltma bilgilerini kullanıma sunmaz. İşlemeler ve yazma işlemleri, günlük dosyaları birincil sunucunun ZRS'sine aktarıldıktan sonra onaylanır. ZRS depolamasında kullanılan senkron çoğaltma teknolojisi nedeniyle, uygulama yazma ve onaylama işlemleri için yüzde 5-10 arasında artan gecikme süresi bekleyebilirsiniz.

Birincil veritabanı sunucusu, anlık görüntüleri ve günlük yedeklemelerini bölge yedekli depolama üzerinde otomatik olarak yedekler.

Yerel olarak yedekli yüksek kullanılabilirlik (HA) mimarisi

Yerel olarak yedekli HA ile bir sunucu dağıttığınızda, aynı bölgede iki sunucu oluşturursunuz:

  • Birincil sunucu
  • Birincil sunucuyla aynı yapılandırmaya sahip bekleyen çoğaltma sunucusu (işlem katmanı, işlem boyutu, storage boyutu ve ağ yapılandırması)

Kullanılabilirlik alanı diyagramı.

Hazır bekleyen sunucu, ayrı bir sanal makine (işlem) kullanarak altyapı yedekliliği sağlar. Bu yedeklilik, birlikte bulundurma nedeniyle uygulama ile veritabanı sunucusu arasındaki yük devretme süresini ve ağ gecikme süresini azaltır.

Veri ve günlük dosyaları yerel olarak yedekli depolama (LRS) içinde barındırılır. Hazır bekleyen sunucu, birincil sunucunun depolama seviyesi çoğaltma ile korunan depolama hesabından günlük dosyalarını sürekli okur ve yeniden yürütür.

Yük devretme gerçekleşirse:

  • Hazır bekleyen çoğaltma etkinleştirilir.
  • Birincil sunucunun ikili günlük dosyaları, bekleme sunucusunu çevrimiçi hale getirmek için birincil sunucudaki son işlenen işleme kadar uygulanmaya devam eder.

Birincil sunucu kullanılamadığında bile LRS'deki günlüklere erişilebilir. Bu kullanılabilirlik, veri kaybı olmamasını sağlamaya yardımcı olur. Yedek kopya etkinleştirildikten ve ikili günlükler uygulandıktan sonra, mevcut yedek kopya birincil sunucu rolünü üstlenir. DNS, istemci yeniden bağlandığında bağlantıları yeni birincil sunucuya yeniden yönlendirecek şekilde güncelleştirilir. Yük devretme, istemci uygulaması açısından tamamen görünmezdir ve sizden herhangi bir işlem yapmanızı gerektirmez. Ha çözümü daha sonra mümkün olduğunda eski birincil sunucuyu geri getirir ve hazır bekleyen sunucu olarak yerleştirir.

Veritabanı sunucusu adı, uygulamaları birincil sunucuya bağlar. Yedek kopya bilgileri doğrudan erişim amacıyla gösterilmez. Kayıt dosyaları birincil sunucunun LRS'sinde boşaltıldıktan sonra işleme ve yazma işlemleri kabul edilir. Birincil ve bekleme çoğaltması aynı bölgede olduğundan, uygulama sunucusu ile veritabanı sunucusu arasında daha az çoğaltma gecikmesi ve daha düşük gecikme süresi vardır. Bağımlı altyapılar belirli bir kullanılabilirlik alanı için kullanım dışı olduğunda yerel olarak yedekli kurulum yüksek kullanılabilirlik sağlamaz. Tüm bağımlı hizmetler bu kullanılabilirlik alanı için yeniden çevrimiçi olana kadar kesinti yaşanır.

Birincil veritabanı sunucusu, hem anlık görüntüleri hem de günlük yedeklerini yerel olarak yedekli depolama alanına otomatik olarak kaydeder.

Not

Hem alanlar arası yedekli hem de yerel olarak yedekli HA için:

  • Bir hata oluşursa, yedek çoğaltmanın birincil rolü devralması için gereken süre, ikili günlüğün birincil depolama hesabından yedekteki hesaba yeniden oynatılma süresine bağlıdır. Yük devretme süresini azaltmak için tüm tablolarda birincil anahtarları kullanın. Yük devretme süreleri genellikle 60 ile 120 saniye arasında sürer.
  • Hazır bekleyen sunucu okuma veya yazma işlemleri için kullanılamaz. Hızlı yük devretmeyi etkinleştirmek için pasif bir bekleme modudur.
  • Birincil sunucunuza bağlanmak için her zaman tam etki alanı adı (FQDN) kullanın. Bağlanmak için IP adresi kullanmaktan kaçının. Bir yük devretmesi gerçekleşirse, birincil ve bekleyen sunucu arasındaki rol değişiminin ardından DNS A kaydı değişebilir. Bu değişiklik, bağlantı dizesinde bir IP adresi kullanılırsa uygulamanın yeni birincil sunucuya bağlanmasını engeller.

Var olan bir sunucudan alanlar arası yedekli sunucuya geçiş

İlk olarak Azure Database for MySQL sunucunuzu HA olmayan bir sunucu olarak sağladıysanız, yerel olarak yedekli HA mimarisi için etkinleştirebilirsiniz. Ancak, alanlar arası yedekli HA mimarisi için etkinleştirmek istiyorsanız, aşağıdaki adımları izleyerek istediğiniz yapılandırmaya sahip yeni bir sunucu oluşturmanız ve bu sunucuya geçiş yapmanız gerekir:

  1. Tercih ettiğiniz dağıtım aracına yönelik yönergeleri izleyerek alanlar arası yedekli yüksek kullanılabilirlik etkinleştirilmiş yeni bir sunucu oluşturun:

  2. Bu yaklaşımlardan birini izleyerek iş yükünüzü yeni sunucuya geçirin. Geçiş yaklaşımına bağlı olarak kesinti süresi gerekebilir.

    • Çevrimdışı geçiş yaklaşımları: Uygulamanız kapalı kalma süresini karşılayabiliyorsa, çevrimdışı geçişler her zaman tercih edilen seçenektir çünkü bunlar basit ve yürütülmesi kolaydır. Çevrimdışı geçişle, kaynak sunucu çevrimdışına alınır ve veritabanlarının dökümü ve geri yüklemesi hedef sunucuda gerçekleştirilir. Bu seçenek en fazla kapalı kalma süresini gerektirir. Kapalı kalma süresi, hedef sunucuda geri yüklemeyi gerçekleştirmek için geçen süreye göre belirlenir.

      • Veri Geçiş Hizmeti (DMS): DMS'yi nasıl kullanacağınızı öğrenmek için bkz. Azure portal üzerinden DMS kullanarak MySQL'den Azure MySQL Veritabanı'na çevrimdışı geçiş.

        Öğretici, şirket içi MySQL sunucusundan Azure Database for MySQL'a geçiş adımlarını özetlerken, aynı yöntemi kullanılabilirlik alanlarını desteklemeyen bir Azure Database for MySQL sunucusundan, bu alanları destekleyen bir sunucuya veri aktarmak için de kullanabilirsiniz.

      • Açık kaynak araçları: Veritabanını yedeklemek ve geri yüklemek için MySQL Workbench, mydumper/myloader veya mysqldump gibi açık kaynak araçları kullanarak çevrimdışı geçirebilirsiniz. Bu araçların nasıl kullanılacağı hakkında bilgi için bkz. Azure Database for MySQL - Tek Sunucu'dan Esnek Sunucu'ya Geçiş Seçenekleri. Azure MySQL Tek Sunucusundan Esnek Sunucuya geçiş adımlarını özetlese de, aynı kılavuz, kullanılabilirlik alanlarını desteklemeyen bir Azure Database for MySQL Esnek Sunucudan, kullanılabilirlik alanlarını destekleyen başka bir sunucuya veri geçirmek için kullanılabilir.

    • Çevrimiçi geçiş yaklaşımları: Çevrimiçi geçişler uygulama kapalı kalma süresini en aza indirir. Kaynak sunucu güncelleştirmelere izin verir, geçiş çözümü başlangıç dökümü ve geri yükleme ile birlikte kaynak ve hedef sunucu arasında devam eden değişiklikleri çoğaltır. Ancak, bu yaklaşımların uygulanması çevrimdışı geçişten daha karmaşıktır.

Yük devretme işlemi

MySQL için Azure Veritabanı'ndaki yük devretme işlemi sırasında, sistem otomatik olarak birincil sunucudan yedek çoğaltmaya geçer. Bu düğme sürekliliği sağlar ve kesinti süresini en aza indirir. Sistem bir arıza algıladığında, yedek çoğaltmayı yeni birincil sunucu olacak şekilde terfi ettirir. Sistem, ikili günlük dosyalarını orijinal birincil sunucudan yedek çoğaltmaya uygular. Bu işlem, yedek çoğaltmayı son onaylanmış işlemle eşitler ve veri kaybı olmamasını sağlar. Bu sorunsuz geçiş, veritabanı hizmetinin yüksek kullanılabilirliğini ve güvenilirliğini korumaya yardımcı olur.

Not

DNS önbellekleme nedeniyle yük devretme süresi bağımlılığını azaltmak için, Ekim 2025'ten itibaren genel erişim veya özel bağlantı ile oluşturulan tüm yeni yüksek kullanılabilirlik sunucuları, her bir yüksek kullanılabilirlik sunucusu için özel bir SLB içeren yeni mimariyi benimseyen yapıyı kullanacaktır. SLB, MySQL veri trafiği yolunu yöneterek yük devretme sırasında DNS değişiklikleri gereksinimini ortadan kaldırır ve yük devretme performansını önemli ölçüde artırır. Yük devretme sırasında, yük dengeleme kurallarını kullanarak trafiği mevcut birincil örneğe yönlendirir. Mevcut sunucular, genel erişim veya özel bağlantı ile etkiyi en aza indirmek için aşamalı olarak taşınıyor. Erken geçişi tercih eden müşteriler yüksek kullanılabilirliği devre dışı bırakabilir ve yeniden etkinleştirebilir. Bu özellik, VNet entegrasyonu ile özel erişim kullanan sunucular için desteklenmez.

Planlanmış: Zorunlu yük devretme

Azure Database for MySQL Esnek Sunucu'da zorlamalı yük devretme, yük devretmeyi manuel olarak zorlamanızı sağlar. Bu özellik, uygulama senaryolarınızla işlevselliği test etmenizi sağlar ve kesintilere hazırlanmanıza yardımcı olur.

Zorlamalı yük devretme, aynı veritabanı sunucusu adını kullanarak ve DNS kaydını güncelleştirerek bekleyen çoğaltmayı birincil sunucu olacak şekilde etkinleştiren bir yük devretme tetikler. Orijinal birincil sunucu yeniden başlatılır ve yedek kopyaya geçer. İstemci bağlantılarının bağlantısı kesilir ve işlemlerini sürdürmek için yeniden bağlanması gerekir.

Genel yük devretme süresi mevcut çalışma yüküne ve son kontrol noktasına bağlıdır. Genel olarak 60 ile 120 saniye arasında sürer.

Not

Planlı yük devretme sırasında bir Azure Resource Health etkinliği oluşturulur. Olay, sunucunun kullanılamadığı yük devretme süresini temsil eder. Sol bölmede Resource Health seçildiğinde tetiklenen olayları görebilirsiniz. Durum, kullanıcı tarafından başlatılan veya elle devretme işlemi "Kullanılamaz" ve "Planlı" olarak etiketlendiğinde temsil eder. Örneğin, yetkili bir kullanıcı (Planlı) tarafından bir yük devretme operasyonu tetiklendi. Kaynağınız uzun süre bu durumda kalırsa, bir destek talebi oluşturun, biz de size yardımcı olalım.

Planlanmamış: Otomatik yük devretme

Yazılım hataları veya işlem, ağ veya storage hataları gibi altyapı hatalarından dolayı planlanmamış hizmet kapalı kalma süresi oluşabilir. Güç kesintileri veritabanının kullanılabilirliğini de etkileyebilir. Veritabanı kullanılamaz duruma gelirse, yedek çoğaltmaya olan çoğaltma durdurulur ve yedek çoğaltma birincil veritabanı haline gelir. DNS güncelleştirmeleri gerçekleşir ve istemciler veritabanı sunucusuna yeniden bağlanarak işlemlerine devam eder.

Genel yük devretme süresi genellikle 60 ile 120 saniye arasındadır. Ancak, yük devretme sırasında birincil veritabanı sunucusundaki etkinliğe bağlı olarak (büyük işlemler ve kurtarma süresi gibi), yük devretme daha uzun sürebilir.

Not

Planlanmamış bir yük devretme, Kaynak Sağlığı olayı oluşturur. Olay, sunucunun kullanılamadığı yük devretme süresini temsil eder. Tetiklenen olayları sol bölmede Resource Health seçtiğinizde görebilirsiniz. Otomatik yük devretme Kullanılamıyor durumunu gösterir ve Planlanmamış olarak etiketlenmiştir.

Örneğin, Kullanılamıyor: Yük devretme işlemi otomatik olarak tetiklendi (Planlanmamış). Kaynağınız uzun süre bu durumda kalırsa bir destek talebi açın, size yardımcı olalım.

HA özellikli sunucularda otomatik yük devretme algılama nasıl çalışır?

Birincil sunucu ve ikincil sunucunun her birinin iki ağ uç noktası vardır:

  • Müşteri Uç Noktası: Müşteriler bu uç noktayı kullanarak örneğe bağlanır ve sorgu çalıştırır.
  • Yönetim Uç Noktası: Yönetim bileşenlerine servis iletişimi ve arka uç depolamaya bağlanma için dahili olarak kullanılır.

Sistem durumu izleyicisi bileşeni sürekli olarak aşağıdaki denetimleri yapar:

  • İzleme aracı, düğümün yönetim ağ uç noktasına ping gönderir. Bu denetim ardışık iki kez başarısız olursa otomatik yük devretme işlemini tetikler. Bu sistem durumu denetimi, işletim sistemi sorunları nedeniyle düğüm kullanılamaması veya yanıt vermeme, yönetim bileşenleri ile düğümler arasındaki ağ sorunları ve benzer sorunlar gibi senaryoları ele alır.
  • İzleyici, örnekte basit bir sorgu çalıştırır. Sorgular çalıştırılamazsa otomatik yük devretme işlemi devreye girer. Bu sağlık kontrolü, MySQL daemon çökmeleri, durmaları veya takılmaları ile arka uç depolama sorunları ve benzer sorunlar gibi senaryoları kapsar.

Not

Sistem durumu denetimi, uygulama ile müşteri ağ uç noktası (Özel/Genel access) arasındaki ağ sorunlarını izlemez. Bu sorunlar ağ yolunda, uç noktada veya istemci tarafındaki DNS sorunlarında oluşabilir. Özel erişim kullanıyorsanız, sanal ağ için NSG kurallarının 3306 numaralı bağlantı noktası üzerinden örnek müşteri ağ uç noktasına iletişimi engellemediğinden emin olun. Herkese açık erişim için, güvenlik duvarı kurallarının ayarlandığından ve ağ yolunda başka güvenlik duvarları varsa, 3306 numaralı bağlantı noktasında ağ trafiğine izin verildiğinden emin olun. ayrıca istemci uygulaması tarafından DNS çözümlemesini de yapmanız gerekir.

Yüksek kullanılabilirliği izleme

Sunucunun yüksek kullanılabilirlik yapılandırma durumunu denetlemek için, portaldaki sunucunun yüksek kullanılabilirlik bölmesindeki yüksek kullanılabilirlikDurumunu kullanın.

Statü Tanım
Etkin Değil Yüksek kullanılabilirlik etkinleştirilmedi.
Verileri Çoğaltma Bekleme sunucusu, yüksek kullanılabilirlik sunucusu sağlama sırasında veya yüksek kullanılabilirlik seçeneğini etkinleştirdiğinizde birincil sunucuyla eşitlenir.
FailingOver (Yük Devretme) Veritabanı sunucusu birincil sunucudan yedek sunucuya geçiş yapıyor.
Sağlıklı Yüksek kullanılabilirlik seçeneği etkindir.
Standby'yi Kaldırma Yüksek kullanılabilirlik seçeneğini devre dışı bırakdığınızda silme işlemi devam ediyor.

Yüksek kullanılabilirlik sunucusunun durumunu izlemek için aşağıdaki ölçümleri kullanın.

Metrik görüntüleme adı Ölçü birimi Birim Açıklama
HA IO Durumu ha_io_running Devlet HA IO Durumu, HA çoğaltmasının durumunu gösterir. G/Ç iş parçacığı çalışıyorsa ölçüm değeri 1, çalışmıyorsa 0 olur.
HA SQL Durumu ha_sql_running Devlet HA SQL Durumu, HA çoğaltmasının durumunu gösterir. SQL iş parçacığı çalışıyorsa ölçüm değeri 1, çalışmıyorsa 0 olur.
HA Çoğaltma Gecikmesi çoğaltma gecikmesi Saniye Çoğaltma gecikmesi, birincil sunucuda alınan işlemlerin yeniden oynatılmasında beklemenin geride kaldığı saniye sayısıdır.

Sınırlamalar

Yüksek kullanılabilirlik kullanırken aşağıdaki noktaları göz önünde bulundurun:

  • Alanlar arası yedekli yüksek kullanılabilirliği yalnızca sunucu oluşturma sırasında yapılandırabilirsiniz.

  • Hızla artırılabilir işlem katmanı yüksek kullanılabilirliği desteklemez.

  • Statik parametre değişiklikleri uygulamak için birincil veritabanı sunucusunun yeniden başlatılması, bekleme çoğaltmasını da yeniden başlatır.

  • GtID kullandığından çözüm GTID modunu açar. İş yükünüzün GTID'lerle çoğaltmayla ilgili kısıtlamaları veya sınırlamaları olup olmadığını denetleyin.

Not

Storage otomatik büyütme, yüksek kullanılabilirlik yapılandırılmış bir sunucu için varsayılan olarak etkindir ve devre dışı bırakılamaz.

Bilinen sorunlar

Azure Database for MySQL Flexible Server arka planda yerel MySQL çoğaltması kullanır. MySQL Community Edition 8.0 ve sonraki sürümlerinde, ON DELETE CASCADE ile yabancı anahtar kısıtlamalarına dayalı çok tablolu bir DELETE işlemi gerçekleştirirken çoğaltmayı bozabilen bilinen bir sorun vardır. Bu sorun MySQL Hata 102586 olarak izlenir. Sonuç olarak, Azure Database for MySQL Esnek Sunucuda yüksek kullanılabilirliği etkinleştirdiğinizde, bu desen çoğaltma hatalarına yol açabileceğinden ve sunucunun kullanılabilirliğini etkileyebileceğinden, yabancı anahtarlarla basamaklı silmeleri kullanmaktan kaçının.

Sistem Durumu Denetimi

Azure Database for MySQL için yüksek kullanılabilirlik (HA) yapılandırdığınızda, Sistem Durumu Denetimi veritabanınızın güvenilirliğini ve performansını korumada önemli bir rol oynar. Bu denetimler, hem birincil hem de bekleme kopyalarının durumunu ve sağlık durumunu sürekli izleyerek sorunların hemen tespit edilmesini sağlar. Sistem Durumu Denetimi, sunucu yanıt hızı, çoğaltma gecikmesi ve kaynak kullanımı gibi çeşitli ölçümleri izleyerek yük devretme işlemlerinin sorunsuz bir şekilde yürütülebilmesini sağlayarak kapalı kalma süresini en aza indirir ve veri kaybını önler. Düzgün yapılandırılmış Sistem Durumu Denetimi, veritabanı kurulumunuzda istenen kullanılabilirlik ve dayanıklılık düzeyine ulaşmak için gereklidir.

Sağlığı izleme

AZURE portalı üzerinden HA kurulumunuzun durumunu izleyebilirsiniz. Dikkate almak için önemli ölçümler şunlardır:

  • Sunucu yanıt hızı: Birincil sunucunun erişilebilir olup olmadığını gösterir.
  • Çoğaltma gecikmesi: Birincil ve bekleyen çoğaltmalar arasındaki gecikmeyi ölçer ve veri tutarlılığını sağlar.
  • Kaynak kullanımı: Performans sorunlarını önlemek için CPU, bellek ve storage kullanımını izler.

Güvenilirlik ve dayanıklılık

MySQL için Azure Veritabanı'nda geçici hata işleme, kullanılabilirlik alanı dayanıklılığı, okuma amaçlı çoğaltmalarla bölgeler arası olağanüstü durum kurtarma, yedekleme ve geri yükleme ve hizmet bakımı gibi güvenilirlikle ilgili kapsamlı bir genel bakış için bkz. MySQL için Azure Veritabanı'nda güvenilirlik.

İlgili içerik

  • Last updated on