MySQL için Azure Veritabanı - Esnek Sunucuda yüksek kullanılabilirlik kavramları

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

MySQL için Azure Veritabanı esnek sunucu, otomatik yük devretme ile yüksek kullanılabilirlik yapılandırmasına olanak tanır. Yüksek kullanılabilirlik çözümü, kaydedilen verilerin hatalardan dolayı hiçbir zaman kaybolmamasını ve veritabanının yazılım mimarinizdeki tek hata noktası olmamasını sağlamak için tasarlanmıştır. Yüksek kullanılabilirlik yapılandırıldığında esnek sunucu otomatik olarak hazır bekleyen çoğaltma sağlar ve yönetir. Hem birincil hem de ikincil çoğaltma için sağlanan işlem ve depolama için faturalandırılırsınız. İki yüksek kullanılabilirlik mimari modeli vardır:

• Alanlar arası yedekli HA. Bu seçenek, birden çok kullanılabilirlik alanında altyapının tam yalıtımı ve yedekliliği için tercih edilir. En yüksek kullanılabilirlik düzeyini sağlar, ancak alanlar arasında uygulama yedekliliğini yapılandırmanızı gerektirir. Alanlar arası yedekli HA, kullanılabilirlik alanındaki herhangi bir altyapı hatasına karşı en yüksek kullanılabilirlik düzeyini elde etmek istediğinizde ve kullanılabilirlik alanı genelinde gecikme kabul edilebilir olduğunda tercih edilir. Yalnızca sunucu oluşturulduğunda etkinleştirilebilir. Alanlar arası yedekli HA, bölgenin birden çok kullanılabilirlik alanını desteklediği ve alanlar arası yedekli Premium dosya paylaşımlarının kullanılabildiği Azure bölgelerinin bir alt kümesinde kullanılabilir.

• Aynı bölgeLI HA. Bu seçenek, birincil ve bekleme sunucuları aynı kullanılabilirlik alanında olacağı için daha düşük ağ gecikme süresine sahip altyapı yedekliliği için tercih edilir. Alanlar arasında uygulama yedekliliğini yapılandırmaya gerek kalmadan yüksek kullanılabilirlik sağlar. 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 aynı bölge HA'sı tercih edilir. Aynı bölgeLI HA, esnek MySQL için Azure Veritabanı sunucu kullanabileceğiniz tüm Azure bölgelerinde kullanılabilir.

Alanlar arası yedekli HA mimarisi

Alanlar arası yedekli HA ile bir sunucu dağıttığınızda iki sunucu oluşturulur:

• Tek bir kullanılabilirlik alanındaki birincil sunucu.
• Aynı Azure bölgesinin başka bir kullanılabilirlik alanındaki birincil sunucuyla (işlem katmanı, işlem boyutu, depolama boyutu ve ağ yapılandırması) aynı yapılandırmaya sahip bekleyen çoğaltma sunucusu.

Birincil ve hazır bekleyen çoğaltma için kullanılabilirlik alanını seçebilirsiniz. Hazır bekleyen veritabanı sunucularının ve hazır bekleyen uygulamaların aynı bölgeye yerleştirilmesi gecikme süresini azaltır. Ayrıca olağanüstü durum kurtarma durumlarına ve "bölge azaltma" senaryolarına daha iyi hazırlanmanızı sağlar.

Veri ve günlük dosyaları alanlar arası yedekli depolamada (ZRS) barındırılır. Hazır bekleyen sunucu, depolama düzeyi çoğaltma ile korunan birincil sunucunun depolama hesabından günlük dosyalarını sürekli olarak okur ve yeniden yürüter.

Yük devretme varsa:

• Bekleme çoğaltması etkinleştirilir.
• Birincil sunucunun ikili günlük dosyaları, birincil sunucudaki son işlenen işleme çevrimiçi duruma getirmek için hazır bekleyen sunucuya 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. Hazır bekleyen çoğaltma etkinleştirildikten ve ikili günlükler uygulandıktan sonra, geçerli bekleyen çoğaltma sunucusu birincil sunucunun rolünü alır. DNS, istemci yeniden bağlandığında istemci bağlantılarının yeni birincil sunucuya yönlendirilmesi için güncelleştirilir. Yük devretme istemci uygulamasından tamamen saydamdır ve sizden herhangi bir eylem 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ğlamak için kullanılır. Bekleme çoğaltması bilgileri doğrudan erişim için kullanıma sunulmaz. İşlemeler ve yazma işlemleri, günlük dosyaları birincil sunucunun ZRS'sinde temizlendikten sonra kabul edilir. ZRS depolamada kullanılan eşitleme çoğaltma teknolojisi nedeniyle uygulama yazma ve işleme işlemleri için yüzde 5-10 oranında artan gecikme süresi bekleyebilirsiniz.

Hem anlık görüntüler hem de günlük yedeklemeleri olan otomatik yedeklemeler, birincil veritabanı sunucusundan alanlar arası yedekli depolamada gerçekleştirilir.

Aynı bölge HA mimarisi

Aynı bölge HA'sı olan bir sunucu dağıttığınızda, aynı bölgede iki sunucu oluşturulur:

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

Hazır bekleyen sunucu, ayrı bir sanal makine (işlem) ile altyapı yedekliliği sunar. 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 depolamada (LRS) barındırılır. Hazır bekleyen sunucu, depolama düzeyi çoğaltma ile korunan birincil sunucunun depolama hesabından günlük dosyalarını sürekli olarak okur ve yeniden yürüter.

Yük devretme varsa:

• Bekleme çoğaltması etkinleştirilir.
• Birincil sunucunun ikili günlük dosyaları, birincil sunucudaki son işlenen işleme çevrimiçi duruma getirmek için hazır bekleyen sunucuya 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. Hazır bekleyen çoğaltma etkinleştirildikten ve ikili günlükler uygulandıktan sonra, geçerli bekleme çoğaltması birincil sunucunun rolünü alır. DNS, istemci yeniden bağlandığında bağlantıları yeni birincil sunucuya yeniden yönlendirecek şekilde güncelleştirilir. Yük devretme istemci uygulamasından tamamen saydamdır ve sizden herhangi bir eylem 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ğlamak için kullanılır. Bekleme çoğaltması bilgileri doğrudan erişim için kullanıma sunulmaz. günlük dosyaları birincil sunucunun LRS'sinde temizlendikten sonra işlemeler 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 aynı bölge kurulumu yüksek kullanılabilirlik sağlamaz. Tüm bağımlı hizmetler söz konusu kullanılabilirlik alanı için yeniden çevrimiçi olana kadar kapalı kalma süresi olacaktır.

Hem anlık görüntüler hem de günlük yedeklemeleri olan otomatik yedeklemeler, birincil veritabanı sunucusundan yerel olarak yedekli depolama alanında gerçekleştirilir.

Not

Hem alanlar arası yedekli hem de aynı bölgeLI HA için:

• Bir hata varsa, bekleyen çoğaltmanın birincil rolü devralması için gereken süre, ikili günlüğün birincil depolama hesabından beklemeye yeniden oynatılma süresine bağlıdır. Bu nedenle, yük devretme süresini azaltmak için tüm tablolarda birincil anahtarları kullanmanızı öneririz. Yük devretme süreleri genellikle 60 ila 120 saniye arasındadır.
• Hazır bekleyen sunucu okuma veya yazma işlemleri için kullanılamaz. Hızlı yük devretmeyi etkinleştirmek için pasif bir beklemedir.
• 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. Yük devretme varsa, birincil ve hazır bekleyen sunucu rolleri değiştirildikten sonra DNS A kaydı değişebilir. Bu değişiklik, bağlantı dizesi bir IP adresi kullanılırsa uygulamanın yeni birincil sunucuya bağlanmasını engeller.

Yük devretme işlemi

Planlanmış: Zorlamalı yük devretme

esnek sunucu zorlamalı yük devretme MySQL için Azure Veritabanı, yük devretmeyi el ile zorlamanızı sağlar. Bu özellik, uygulama senaryolarınızla işlevselliği test etmenizi sağlar ve kesintilere hazır olmanıza yardımcı olur.

Zorlamalı yük devretme, DNS kaydını güncelleştirerek bekleyen çoğaltmayı etkinleştirir ve aynı veritabanı sunucusu adıyla birincil sunucuya dönüşmesini sağlar. Özgün birincil sunucu yeniden başlatılır ve bekleyen çoğaltmaya geçirilir. İstemci bağlantıları kesilir ve işlemlerine devam edebilmeleri için yeniden bağlanmaları gerekir.

Genel yük devretme süresi geçerli iş yüküne ve son denetim noktasına bağlıdır. Genel olarak 60 ile 120 saniye arasında sürmesi beklenir.

Not

Azure Kaynak Durumu olayı, sunucunun kullanılamadığı yük devretme süresini temsil eden planlı yük devretme durumunda oluşturulur. Tetiklenen olaylar, sol bölmedeki "Kaynak Durumu" seçeneğine tıklandığında görülebilir. Kullanıcı tarafından başlatılan/ El ile yük devretme durumu "Kullanılamıyor" olarak gösterilir ve "Planlı" olarak etiketlenmiştir. Örnek - "Yetkili bir kullanıcı tarafından yük devretme işlemi tetiklendi (Planlı)". Kaynağınız uzun süre bu durumda kalırsa lütfen bir destek bileti açın ve size yardımcı olacağız.

Planlanmamış: Otomatik yük devretme

Planlanmamış hizmet kapalı kalma süresi yazılım hatalarından veya işlem, ağ veya depolama hataları gibi altyapı hatalarından ya da veritabanının kullanılabilirliğini etkileyen güç kesintilerinden kaynaklanabilir. Veritabanı kullanılamaz duruma gelirse bekleyen çoğaltmaya yönelik çoğaltma işlemi bölünür ve bekleyen çoğaltma birincil veritabanı olarak etkinleştirilir. DNS güncelleştirilir ve istemciler veritabanı sunucusuna yeniden bağlanır ve işlemlerini sürdürür.

Genel yük devretme süresinin 60 ile 120 saniye arasında olması beklenir. 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

Azure Kaynak Durumu olayı, sunucunun kullanılamadığı yük devretme süresini temsil eden planlanmamış yük devretme durumunda oluşturulur. Tetiklenen olaylar, sol bölmedeki "Kaynak Durumu" seçeneğine tıklandığında görülebilir. Otomatik yük devretme durumuyla "Kullanılamıyor" olarak gösterilir ve "Planlanmamış" olarak etiketlenmiştir. Örnek - "Kullanılamıyor: Yük devretme işlemi otomatik olarak tetiklendi (Planlanmamış)". Kaynağınız uzun süre bu durumda kalırsa lütfen bir destek bileti açın ve size yardımcı olacağız.

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

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

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

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

• İzleyici, Yönetim ağı Uç Noktası düğümlerine ping'ler. Bu denetim iki kez sürekli başarısız olursa otomatik yük devretme işlemini tetikler. İşletim sistemi sorunu nedeniyle düğüm kullanılamıyor/yanıt vermiyor gibi senaryo, yönetim bileşenleri ve düğümler arasındaki ağ sorunu bu sistem durumu denetimiyle giderilecektir.
• İzleyici ayrıca Örnek üzerinde basit bir sorgu çalıştırır. Sorgular çalıştırılamazsa otomatik yük devretme tetiklenir. MySQL iblisi kilitlendi/ durduruldu/kilitlendi, Arka uç depolama sorunu vb. gibi senaryolar bu sistem durumu denetimiyle ele alınacaktır.

Not

Uygulama ile müşteri ağ uç noktası (Özel/Genel erişim) arasında ağ yolu , uç nokta veya istemci tarafındaki DNS sorunları arasında herhangi bir ağ sorunu varsa, sistem durumu denetimi bu senaryoyu izlemez. Özel erişim kullanıyorsanız, sanal ağ için NSG kurallarının 3306 numaralı bağlantı noktası üzerindeki örnek müşteri ağ uç noktasıyla iletişimi engellemediğinden emin olun. Genel erişim için güvenlik duvarı kurallarının ayarlandığından ve 3306 numaralı bağlantı noktasında ağ trafiğine izin verildiğinden emin olun (ağ yolunda başka güvenlik duvarları varsa). İstemci uygulama tarafındaki DNS çözümlemesine de dikkat edilmesi gerekir.

Yüksek kullanılabilirlik için izleme

Portalda sunucunun Yüksek Kullanılabilirlik bölmesinde bulunan Yüksek Kullanılabilirlik Durumu, sunucunun HA yapılandırma durumunu belirlemek için kullanılabilir.

Statü	Açıklama
NotEnabled	HA etkin değil.
ReplicatingData	Hazır bekleyen sunucu, HA sunucusu sağlama sırasında veya HA seçeneği etkinleştirildiğinde birincil sunucuyla eşitleme sürecindedir.
FailingOver	Veritabanı sunucusu birincil sunucudan hazır bekleyen sunucuya yük devretme sürecindedir.
Sağlıklı	HA seçeneği etkindir.
KaldıranStandby	HA seçeneği devre dışı bırakıldığında ve silme işlemi devam ettiğinde.

HA sunucusunun durumunu izlemek için aşağıdaki ölçümleri de kullanabilirsiniz.

Ölçüm görünen adı	Metric	Unit	Açıklama
HA GÇ Durumu	ha_io_running	Durum	HA GÇ 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	Durum	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	replication_lag	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 göz önünde bulundurmanız gereken bazı noktalar şunlardır:

• Alanlar arası yedekli yüksek kullanılabilirlik yalnızca esnek sunucu oluşturulduğunda ayarlanabilir.
• Yüksek kullanılabilirlik, hızla artırılabilir işlem katmanında desteklenmez.
• Statik parametre değişikliklerini almak üzere birincil veritabanı sunucusu yeniden başlatıldığında bekleyen çoğaltma da yeniden başlatılır.
• HA çözümü GTID kullandığından GTID modu açılır. İş yükünüzün GTID'lerle çoğaltmayla ilgili kısıtlamaları veya sınırlamaları olup olmadığını denetleyin.

Not

Sunucu oluşturma işlemi sonrasında aynı bölgeli HA'yı etkinleştiriyorsanız, HA'yı etkinleştirmeden önce sunucu parametrelerinin enforce_gtid_consistency" ve "gtid_mode" değerlerinin ON olarak ayarlandığından emin olmanız gerekir.

Not

Depolama 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.

Sık sorulan sorular (SSS)

• Aynı bölge ve alanlar arası yedekli HA özellikli Esnek sunucu için SLA'lar nelerdir?

  esnek MySQL için Azure Veritabanı sunucu için SLA bilgileri MySQL için Azure Veritabanı için SLA'da bulunabilir.

• Yüksek kullanılabilir (HA) sunucular için nasıl faturalandırılırım? Yüksek kullanılabilirlik ile etkinleştirilen sunucular, birincil ve ikincil çoğaltmalara sahiptir. İkincil çoğaltma aynı bölgede veya bölgesel olarak yedekli olabilir. Hem birincil hem de ikincil çoğaltma için sağlanan işlem ve depolama için faturalandırılırsınız. Örneğin birincil çoğaltmanızda 4 sanal çekirdek ve 512 GB depolama alanı sağlanmışsa ikincil çoğaltmanız için de 4 sanal çekirdek ve 512 GB depolama alanı sağlanır. Bu durumda alanlar arası yedekli yüksek kullanılabilirlik sunucunuz 8 sanal çekirdek ve 1.024 GB depolama alanı üzerinden faturalanır. Yedekleme alanı biriminize bağlı olarak yedekleme alanı için de faturalama yapılabilir.

• Hazır bekleyen çoğaltmayı okuma veya yazma işlemleri için kullanabilir miyim?
  Hazır bekleyen sunucu okuma veya yazma işlemleri için kullanılamaz. Hızlı yük devretmeyi etkinleştirmek için pasif bir beklemedir.

• Yük devretme gerçekleştiğinde veri kaybı olacak mı?
  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. Hazır bekleyen çoğaltma etkinleştirildikten ve ikili günlükler uygulandıktan sonra birincil sunucunun rolünü alır.
  

• Yük devretme işleminden sonra herhangi bir işlem yapmam gerekiyor mu?
  Yük devretme işlemleri istemci uygulamasından tamamen saydamdır. Herhangi bir işlem yapmanız gerekmez. Uygulamalar yalnızca bağlantıları için yeniden deneme mantığını kullanmalıdır.
  

• Hazır bekleyen çoğaltmam için belirli bir bölge seçmediğimde ne olur? Bölgeyi daha sonra değiştirebilir miyim?
  Bir bölge seçmezseniz, rastgele bir bölge seçilir. Birincil sunucu için kullanılan sunucu olacaktır. Bölgeyi daha sonra değiştirmek için, Yüksek Kullanılabilirlik bölmesinde Yüksek Kullanılabilirlik'i Devre Dışı olarak ayarlayabilir ve sonra yeniden Alanlar Arası Yedekli olarak ayarlayabilir ve bir bölge seçebilirsiniz.
  

• Birincil ve hazır bekleyen çoğaltmalar arasındaki çoğaltma zaman uyumlu mu?
  Birincil ile bekleme arasındaki çoğaltma, MySQL'deki yarı zaman uyumsuz moda benzer. Bir işlem işlendiğinde, beklemeye işlemesi gerekmez. Ancak birincil kullanılamaz durumda olduğunda, bekleme, veri kaybı olmadığından emin olmak için birincilden yapılan tüm veri değişikliklerini çoğaltır.
  

• Planlanmamış tüm hatalar için hazır bekleyen çoğaltmaya yük devretme var mı?
  Veritabanı kilitlenmesi veya düğüm hatası varsa Esnek Sunucu VM'si aynı düğümde yeniden başlatılır. Aynı zamanda otomatik yük devretme tetikleniyor. Yük devretme tamamlanmadan Esnek Sunucu VM'sinin yeniden başlatılması başarılı olursa, yük devretme işlemi iptal edilir. Birincil çoğaltma olarak kullanılacak sunucunun belirlenmesi, önce biten işleme bağlıdır.
  

• HA kullandığımda performans etkisi olur mu?
  Alanlar arası yedekli HA için, kullanılabilirlik alanlarında okuma iş yükleri için önemli bir performans etkisi olmasa da, yazma sorgusu gecikme süresinde yüzde 40'a kadar düşüş olabilir. Yazma gecikme süresindeki artış, Kullanılabilirlik alanı genelinde zaman uyumlu çoğaltmadan kaynaklanır. Yazma gecikmesi etkisi genellikle alanlar arası yedekli HA'da aynı bölge HA'sına kıyasla iki kez olur. Aynı bölgeLI HA için, birincil ve bekleme çoğaltması aynı bölgede olduğundan çoğaltma gecikme süresi ve dolayısıyla zaman uyumlu yazma gecikmesi daha düşüktür. Özetle, yazma gecikmesi sizin için kullanılabilirlik ile karşılaştırıldığında daha kritikse, aynı bölgeLI HA'yı seçmek isteyebilirsiniz, ancak yazma gecikmesi bırakma pahasına verilerinizin kullanılabilirliği ve dayanıklılığı sizin için daha kritikse, alanlar arası yedekli HA'yı seçmeniz gerekir. HA kurulumundaki gecikme süresi düşüşünün doğru etkisini ölçmek için, bilinçli bir karar almak üzere iş yükünüz için performans testi gerçekleştirmenizi öneririz.
  

• HA sunucumun bakımı nasıl gerçekleşir?
  İşlem ve ikincil sürüm yükseltmelerinin ölçeklenmesi gibi planlı olaylar önce özgün bekleme örneğinde gerçekleşir ve ardından planlı bir yük devretme işlemi tetiklenir ve ardından özgün birincil örnekte çalışır. Esnek sunucularda olduğu gibi HA sunucuları için zamanlanmış bakım penceresini ayarlayabilirsiniz. Kapalı kalma süresi, HA devre dışı bırakıldığında MySQL için Azure Veritabanı esnek sunucu örneğinin kapalı kalma süresiyle aynı olacaktır.
  

• HA sunucumun belirli bir noktaya geri yüklemesini (PITR) yapabilir miyim?
  HA etkin MySQL için Azure Veritabanı esnek sunucu örneği için, HA'nın devre dışı olduğu yeni bir MySQL için Azure Veritabanı esnek sunucu örneğine PITR yapabilirsiniz. Kaynak sunucu alanlar arası yedekli HA ile oluşturulduysa, daha sonra geri yüklenen sunucuda alanlar arası yedekli HA'yı veya aynı alanlar arası HA'yı etkinleştirebilirsiniz. Kaynak sunucu aynı bölge HA ile oluşturulduysa, geri yüklenen sunucuda yalnızca aynı bölgeLI HA'yı etkinleştirebilirsiniz.
  

• Sunucuyu oluşturduktan sonra sunucuda HA'yı etkinleştirebilir miyim?
  Sunucu oluşturulduğunda alanlar arası yedekli HA'nın etkinleştirilmesi gerekir. Sunucuyu oluşturduktan sonra aynı bölgeLI HA'yı etkinleştirebilirsiniz. Aynı bölge HA'sını etkinleştirmeden önce sunucu parametrelerinin enforce_gtid_consistency" ve "gtid_mode" değerlerinin ON olarak ayarlandığından emin olun
  

• Sunucu oluşturduktan sonra sunucu için HA'yi devre dışı bırakabilir miyim?
  Oluşturduktan sonra sunucuda HA'yi devre dışı bırakabilirsiniz. Faturalama hemen durdurulur.
  

• Kapalı kalma süresini nasıl azaltabilirim?
  HA kullanmasanız bile uygulamanız için kapalı kalma süresini azaltabilmeniz gerekir. Zamanlanmış düzeltme ekleri, ikincil sürüm yükseltmeleri veya işlem ölçeklendirme gibi müşteri tarafından başlatılan işlemler gibi hizmet kapalı kalma süresi zamanlanmış bakım pencereleri sırasında gerçekleştirilebilir. Azure tarafından başlatılan bakım görevlerine yönelik uygulama etkisini azaltmak için, bunları haftanın bir günü ve uygulama üzerindeki etkiyi en aza indiren saatte zamanlayabilirsiniz.
  

• HA özellikli bir sunucu için okuma amaçlı çoğaltma kullanabilir miyim?
  Evet, okuma amaçlı çoğaltmalar HA sunucuları için desteklenir.
  

• HA sunucuları için Veri İçi Çoğaltma kullanabilir miyim?
  Yüksek kullanılabilirlik (HA) özellikli sunucu için veri içi çoğaltma desteği yalnızca GTID tabanlı çoğaltma aracılığıyla kullanılabilir. GTID kullanarak çoğaltma için saklı yordam, adıyla mysql.az_replication_with_gtidtüm HA özellikli sunucularda kullanılabilir.

• Kapalı kalma süresini azaltmak için, sunucu yeniden başlatmaları sırasında veya ölçeği artırıp azaltırken hazır bekleyen sunucuya yük devredebilir miyim?
  Şu anda MySQL için Azure Veritabanı esnek sunucu, kapalı kalma süresini azaltmaya yardımcı olmak için ölçeği artırma/azaltma ve planlı bakım dahil olmak üzere HA işlemlerini en iyi duruma getirmek için Planlı Yük Devretmeyi son derece iyileştirmiştir. Bu tür işlemler başlatıldığında, önce özgün bekleme örneğinde çalışır, ardından planlı bir yük devretme işlemini tetikler ve ardından özgün birincil örnekte çalışır.
  

• Sunucunun
  kullanılabilirlik modunu (Alanlar arası yedekli HA/aynı bölge) değiştirebilir miyiz? Sunucuyu Alanlar arası yedekli HA modu etkin olarak oluşturursanız, Alanlar arası yedekli HA'dan aynı bölgeye veya tam tersi olarak değiştirebilirsiniz. Kullanılabilirlik modunu değiştirmek için, Yüksek Kullanılabilirlik bölmesinde Yüksek Kullanılabilirlik'i Devre Dışı olarak ayarlayabilir ve ardından Yeniden Alanlar Arası Yedekli veya aynı bölge olarak ayarlayabilir ve Yüksek Kullanılabilirlik Modu'nu seçebilirsiniz.
  

Sonraki adımlar

• İş sürekliliği hakkında bilgi edinin.
• Alanlar arası yedekli yüksek kullanılabilirlik hakkında bilgi edinin.
• Yedekleme ve kurtarma hakkında bilgi edinin.