MySQL için Azure Veritabanı'deki güvenilirlik

MySQL için Azure Veritabanı, veritabanı yönetimi işlevleri ve yapılandırma ayarları üzerinde ayrıntılı denetim ve esneklik sağlayan tam olarak yönetilen bir veritabanı hizmetidir. Hizmet, gereksinimlerinize göre yüksek kullanılabilirlik (HA) ve olağanüstü durum kurtarma (DR) özellikleri sağlar.

Azure kullandığınızda, güvenilirlik paylaşılan bir sorumluluktur. Microsoft dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sağlar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede geçici hatalar, kullanılabilirlik alanı kesintileri, bölge kesintileri ve hizmet bakımı gibi çeşitli olası kesintilere ve sorunlara karşı MySQL için Azure Veritabanı nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca, diğer sorun türlerinden kurtarmak için yedeklemeleri nasıl kullanabileceğinizi açıklar ve MySQL için Azure Veritabanı hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Üretim dağıtımı önerileri

Azure Well-Architected Framework güvenilirlik, güvenlik, maliyet, operasyonlar ve performansla ilgili öneriler sağlar. Bu alanların birbirini nasıl etkilediğini anlamak ve güvenilir bir MySQL için Azure Veritabanı çözümüne katkıda bulunmak için bkz. MySQL için Azure Veritabanı için en iyi mimari yöntemleri.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

MySQL için Azure Veritabanı ile çalışırken, veritabanı sunucunuzu desteklemek için gereken işlem ve depolama kaynaklarını temsil eden bir server dağıtırsınız. Sunucuya bir veya daha fazla veritabanı dağıtırsınız.

Sunucuları Burstable, Genel Amaçlı ve Bellek için İyileştirilmiş işlem katmanlarında dağıtabilirsiniz. Her işlem katmanı , farklı iş yükleri için iyileştirilmiştir.

Genel hizmet mimarisi ve dağıtım modelleri hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı genel bakış.

Fiziksel mimari

• İşlem ve depolama ayrımı: MySQL için Azure Veritabanı, HA'yı desteklemek için bir işlem ve depolama ayırma mimarisi kullanır. Veritabanı altyapısı bir sanal makinede (VM) çalışır. Veri dosyaları, Azure Depolama'ta depolanır; bu ortam, depolama donanımı hatalarına karşı koruma sağlamak amacıyla verilerin üç kopyasını eş zamanlı olarak tutar. Sunucunun HA yapılandırmasına bağlı olarak, veri dosyaları alanlar arası yedekli depolamada (ZRS) veya yerel olarak yedekli depolamada (LRS) depolanabilir.

• HA: İsteğe bağlı olarak sunucunuzda bir HA yapılandırmasını etkinleştirebilirsiniz. HA yapılandırmasını etkinleştirdiğinizde hizmet, sıcak yedek olarak bekleyen bir replika sunucuyu sağlar ve sürdürür. Birincil sunucudaki veri değişiklikleri, birincil sunucu hatası sırasında sıfır veri kaybı sağlamak için bekleme çoğaltma sunucusuna zaman uyumlu olarak çoğaltılır.

  Mimari, işlem katmanını depolama katmanından ayırarak hizmetin farklı hata türlerini uygun şekilde işlemesini sağlar. Daha yüksek dayanıklılık için sunucuları kullanılabilirlik alanlarına yayabilirsiniz.

  Bekleme durumundaki çoğaltma sunucusu, sanal çekirdekler, depolama ve ağ ayarları dahil olmak üzere birincil sunucuyla aynı VM yapılandırmasında dağıtılır.

  Yük devretme gerçekleştirerek sunucular arasında geçiş yapabilirsiniz. Birincil sunucu başarısız olduğunda plansız yük devretmeleri kullanın ve yük devretme sırasında uygulama kapalı kalma süresini en aza indirmeniz gerektiğinde planlı yük devretmeleri kullanın.

  Daha fazla bilgi için bkz. MySQL için Azure Veritabanı'de HA.

• Backups: MySQL için Azure Veritabanı otomatik olarak sunucu yedeklemeleri oluşturur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Uygulamalarınız bakım, ölçeklendirme işlemleri veya ağ kesintileri sırasında oluşabilecek geçici bağlantı hatalarını işlemelidir. Şu önerileri izleyin:

Kullanılabilirlik alanı hatalarına dayanıklılık

Availability bölgeleri Azure bölgesindeki fiziksel olarak ayrı veri merkezleri gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

HA yapılandırması aracılığıyla kullanılabilirlik alanı desteği türünüzü seçin. HA'yı etkinleştirdiğinizde, MySQL için Azure Veritabanı birincil sunucunuzla birlikte hazır bekleyen bir çoğaltma sunucusu dağıtır. Bu HA modeli, işlenen verilerin hatalar sırasında hiçbir zaman kaybolmamasını sağlamaya yardımcı olur. Hangi HA dağıtım modelini seçerseniz seçin, hizmet verileri hem birincil hem de beklemedeki replika sunuculara eşzamanlı olarak yazar. Birincil sunucu kesintiye uğrarsa, sistem otomatik olarak beklemedeki replika sunucuya geçer.

Hizmet, verileri Azure Dosyalar premium depolamada depolar. Sunucunuzun HA yapılandırmasına bağlı olarak, üç veri kopyasını kullanılabilirlik alanları içinde veya arasında depolayan ya ZRS ya da LRS kullanır.

MySQL için Azure Veritabanı, HA kullandığınızda iki kullanılabilirlik alanı yapılandırma türünü destekler:

• Alanlar arası yedekli HA: Bölge yedekliliği, birincil sunucuyu tek bir kullanılabilirlik alanına ve bekleme çoğaltma sunucusunu farklı bir kullanılabilirlik alanına dağıtarak en yüksek düzeyde bölge dayanıklılığı sağlar. Beklemedeki çoğaltma sunucusu, birincil sunucuya benzer işlem, depolama ve ağ yapılandırmasına sahiptir. Alanlar arası yedekli yapılandırma, birincil ve hazır bekleyen sunucular arasında yığının tamamının fiziksel yalıtımını sağlar.

  Birincil ve hazır bekleyen sunucular için kullanılabilirlik alanlarını seçersiniz.

  Üretim sunucuları için alanlar arası yedekli dağıtımlar kullanın.

  

  Diyagram üç bölümden oluşur. İlk bölümde Azure VM'ler, Azure Kubernetes Service (AKS) ve Azure App Service gibi istemci uygulamaları listelenir. Sonraki bölüm kullanılabilirlik alanı 1 olarak etiketlenmiştir. Birincil sunucuyu ve işlem ve depolama olmak üzere noktalı bir çizgiyle ayrılmış iki alt bölümü içerir. Üçüncü bölüm kullanılabilirlik alanı 2 olarak etiketlenmiştir. Kullanılabilirlik alanı 1'i yansıtır, ancak bekleme sunucusunu içerir. Oklar, istemci uygulamalarından standart bir yük dengeleyiciye doğru yönelir. Yük dengeleyiciden kullanılabilirlik alanı 1'deki birincil sunucudaki bir VM'ye bir ok işaret eder. Çift yönlü oklar, VM ile premium dosya paylaşımını ve katı hal sürücüsünü (SSD) birbirine bağlar. Başka bir ok, Premium dosya paylaşımından yedek blob depolamaya uzanıyor. “depolama tabanlı eşzamansız çoğaltma” etiketli bir ok, kullanılabilirlik bölgesi 1'den kullanılabilirlik bölgesi 2'ye uzanır.

  Hizmet, verileri bekleme sunucusuna zaman uyumlu olarak çoğalttığı için yazma işlemlerinde işlem tamamlama gecikmesinde küçük bir artış yaşanabilir. Ortalama olarak, uygulama yazma ve işleme işlemleri için 5% ile 10% daha fazla gecikme süresi bekleyebilirsiniz. Etki iş yüküne, seçili SKU'ya ve bölgeye göre değişir.

• Yerel olarak yedekli HA: Birincil ve hazır bekleyen sunucular aynı kullanılabilirlik bölgesini kullanır. Birincil sunucuda bir kesinti oluşursa ancak bölge hala iyi durumdaysa, sunucu otomatik olarak hazır bekleyen sunucuya yük devredilir.

  Yerel yedekli dağıtım, tek bir erişilebilirlik alanı içinde HA sunar. Sizi düğüm düzeyindeki arızalara karşı korur ve ayrıca planlı ve plansız kesinti durumlarında uygulamanın kesinti süresini azaltmaya yardımcı olur. Ancak, bu bölgedeki bir kesintiye karşı korunmaz. Kullanılabilirlik alanları olan bölgelerde bu tür yapılandırmalar bazen bölgesel veya tek bölgeli olarak da adlandırılır.

  

  Diyagram üç bölümden oluşur. İlk bölümde Azure VM'ler, AKS ve App Service gibi istemci uygulamaları listelenmiştir. Sonraki bölüm kullanılabilirlik alanı 1 olarak etiketlenmiştir. Birincil sunucu ve hazır bekleyen sunucu için iki ayrı bölüm içerir. Noktalı çizgi, her sunucunun bölümünü işlem ve depolama olmak üzere iki alt bölüme böler. Oklar, istemci uygulamalarından standart bir yük dengeleyiciye doğru işaret eder. Yük dengeleyiciden kullanılabilirlik alanı 1'deki birincil sunucudaki bir VM'ye bir ok işaret eder. Çift yönlü oklar, VM'yi premium dosya paylaşımı ile katı hal sürücüsüne (SSD) bağlar. Başka bir ok, Premium dosya paylaşımından yedek blob depolamasına işaret eder. Depolama tabanlı eşzamansız çoğaltma etiketli bir ok, birincil sunucudan yedek sunucuya doğru uzanır. Kullanılabilirlik alanı 2 etiketli üçüncü bölüm boş.

  Yerel olarak yedekli HA'yi yalnızca aşağıdaki senaryolarda kullanın:

  • Olağan dışı gecikme süresine duyarlı uygulamalarınız olduğunda, birincil ve ikincil çoğaltmanız arasındaki gecikme süresini en aza indirme gereksinimini doğrular ve diğer mimari yaklaşımları kullanarak bölge dayanıklılığını planlarsınız.

  • Kullanılabilirlik alanlarını desteklemeyen bir bölgeye dağıtım yaptığınızda. Bu senaryoda bölge, tek bir zon olarak çalışır; bu da yerel yedekli HA’yı kullanılabilen tek HA seçeneği hâline getirir.

  Sunucular aynı bölgededir ve bu da bu bölgede dağıttığınız uygulamalara yazma gecikmesini azaltabilir.

Sunucunuzu HA olmadan yapılandırırsanız, tek bir sunucuda çalışır. Bu sunucu veya bölgesi başarısız olursa, sunucunuz kullanılamaz.

Gereksinimler

• Bölge desteği: MySQL için Azure Veritabanı, Azure bölgenize bağlı olarak farklı kullanılabilirlik alanı yapılandırmalarını destekler. Kullanılabilirlik alanı desteği türleri ve her bölge için dikkat edilmesi gerekenler de dahil olmak üzere bölgelerin tam listesi için bkz. Azure bölgeler.

• Hizmet katmanı: HA, Genel Amaçlı veya Bellek için İyileştirilmiş katmanlar gerektirir. Burstable katmanı, yüksek kullanılabilirliği (HA) desteklemez (bölge yedekli veya yerel yedekli).

Maliyet

HA'yı etkinleştirdiğinizde, bekleyen sunucuyu birincil sunucuyla aynı hızda oluşturur ve ödersiniz. Kullanılabilirlik alanı yapılandırması maliyeti etkilemez. Veri çoğaltma, erişilebilirlik alanları içinde veya arasında ücrete tabi değildir. Yedekleme depolama biriminize bağlı olarak, yedekleme depolama alanı için de faturalandırılabilirsiniz. Ayrıntılı fiyatlandırma bilgileri için bkz. MySQL için Azure Veritabanı pricing.

Değerlendirmeler

• Birincil anahtarlar: Bu yaklaşım çoğaltma ve yük devretme süresini azalttığı için tüm tablolarda birincil anahtarları kullanın.

• Sınırlamalar ve bilinen sorunlar:Sınırlamalar ve bilinen sorunlar listesini gözden geçirin.

Kullanılabilirlik alanı desteğini yapılandırma

Bir sunucu için kullanılabilirlik alanı desteğini yapılandırmak için HA ayarlarını yapılandırın.

• Alanlar arası yedekli bir sunucu oluşturun. HA ve bölge yedekliliği etkin bir sunucu oluşturmayı öğrenmek için aşağıdaki makalelere bakın:

  • Azure portalı: Azure portalını kullanarak MySQL için Azure Veritabanı'de alanlar arası yedekli HA'ları yönetin.

  • Azure CLI: Azure CLI kullanarak MySQL için Azure Veritabanı'de alanlar arası yedekli HA'ları yönetin.

• Yerel olarak yedekli bir sunucu oluşturun. Tek bir kullanılabilirlik alanında yerel olarak yedekli HA'ya sahip bir sunucu oluşturmak için Azure CLI veya başka bir programlı dağıtım yöntemini kullanmanız gerekir. Azure CLI yönergeleri için bkz. Sunucu oluşturma sırasında HA'yı etkinleştirme.

• Mevcut sunucular için kullanılabilirlik alanı yapılandırmasını değiştirin. Mevcut bir sunucunuz varsa, kullanılabilirlik alanı desteğini etkinleştirmek için izlediğiniz yaklaşım sunucunun ilk yapılandırmasına bağlıdır.

  • Var olan bir sunucuyu alanlar arası yedekli HA olarak değiştirmek için yeni bir sunucuya geçmeniz gerekir. Daha fazla bilgi için bkz. Var olan bir sunucudan alanlar arası yedekli sunucuya geçiş.

  • Var olan bir sunucuyu yerel olarak yedekli HA olarak değiştirmek için:

    1. Etkinse HA'yı devre dışı bırakın.

    2. Yerel olarak yedekli HA'yı etkinleştirin. Azure CLI veya başka bir programlı dağıtım yöntemini kullanmanız gerekir. Azure CLI yönergeler için bkz. Azure CLI kullanarak MySQL için Azure Veritabanı'da alanlar arası yedekli HA'yı yönetme.

• HA'yi devre dışı bırakın. HA'nın devre dışı bırakılması yedek çoğaltma sunucusunu kaldırır, bu nedenle sunucunuz bölge düzeyindeki kesintilere karşı dayanıklı değildir. Ancak coğrafi olarak yedekli yedeklemeler etkinleştirilirse, bu yedeklemeleri kullanarak sunucuyu farklı bir bölgede kurtarmaya devam edebilirsiniz. Daha fazla bilgi için bkz. HA'yı devre dışı bırakma.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, sunucuları HA ve kullanılabilirlik alanı desteğiyle yapılandırdığınızda ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arası işlem: MySQL istemci uygulamaları, veritabanı sunucusunun tam etki alanı adını (FQDN) kullanarak birincil sunucuya bağlanır. Yük devretmeler de dahil olmak üzere IP adresi değişebileceğinden birincil sunucunun IP adresini kullanmaktan kaçının.

  MySQL için Azure Veritabanı, birincil sunucunun birincil kullanılabilirlik alanındaki tüm veritabanı bağlantılarını ve sorgularını işlediği etkin-pasif bir yapılandırma kullanır. Hazır bekleme durumundaki çoğaltma sunucusu, normal işlemler sırasında istemci trafiğine hizmet vermez.

• Bölgeler arası veri çoğaltma: Yazma işlemleri birincil sunucuda kesinleştirilir ve ZRS kullanılarak bekleme sunucusunun günlüklerine eşzamanlı olarak yazılır. Birincil sunucu, bekleme sunucusunun günlükleri uygulamasını beklemez, ancak günlükler ZRS'de olduğu için bir çoğaltma veya bölge hatası oluşsa bile kullanılabilir durumdadır.

  Çoğaltmanın etkileri, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak farklıdır:

  • Alanlar arası yedekli: Sunucular ayrı bölgelerde olduğundan, bu yaklaşım bölge hatası sırasında sıfır veri kaybı sağlar. Bu durum, bölge hataları için sıfır kurtarma noktası hedefine (RPO) ulaşmak olarak da bilinir.

    Ancak bölgeler arası çoğaltma, az miktarda ek gecikme süresine neden olabilir. Ortalama olarak, uygulama yazma ve işleme işlemleri için 5% ile 10% daha fazla gecikme süresi bekleyebilirsiniz, ancak etki iş yüküne, seçilen SKU'ya ve bölgeye göre değişir.

  • Yerel yedekli: Bölgeler arasında trafik çoğaltılmaz.

  Uyarı

  Sistem, bir tablonun yanlışlıkla silinmesi veya verilerin hatalı güncellenmesi gibi kullanıcı kaynaklı istenmeyen hatalar da dahil olmak üzere tüm değişiklikleri gerçek zamanlı olarak yedek replika sunucusuna çoğaltır. Anlık çoğaltma nedeniyle, kurtarma için yedekleme çoğaltmasını kullanamazsınız. Kullanıcı hatalarından kurtarmak için bir yedeklemeden belirli bir noktaya geri yükleme yapmanız gerekir. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölge hatası sırasındaki davranış

Bu bölümde, sunucuları HA ve kullanılabilirlik alanı desteğiyle yapılandırdığınızda ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve Yanıt: Azure hem birincil hem de bekleme sunucularının durumunu düzenli aralıklarla denetler. Birden çok ping işleminden sonra, eğer sağlık izleme birincil sunucuya ulaşılamadığını tespit ederse, hizmet bekleme sunucusuna otomatik yük devretme başlatır. Sistem durumu izleme algoritması, hatalı pozitif durumları önlemek için birden çok veri noktası kullanır.

  Bir bölge hatası oluşursa davranış, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlı olarak farklılık gösterir:

  • Zone-redundant: MySQL için Azure Veritabanı birden çok sunucu uç noktasını sürekli izleyerek kullanılabilirlik alanı hatalarını otomatik olarak algılar. Daha fazla bilgi için bkz. HA özellikli sunucularda otomatik yük devretme algılama nasıl çalışır?

    Olası HA durum türlerini görmek için bkz. HA'yı izleme. Bir bölge başarısız olduğunda, Azure, işlem yapmanıza gerek kalmadan yedek sunucuya plansız yük devretme başlatır.

  • Yerel olarak yedekli: Yerel olarak yedekli bir sunucuyu barındıran kullanılabilirlik alanı kullanılamaz duruma gelirse hem birincil hem de hazır bekleyen sunucular kullanılamaz. Bu senaryoda, hizmet otomatik yük devretme sağlamaz. Bölge kesintisini algılamaktan ve alanlar arası yedekli yedeklemeleri başka bir kullanılabilirlik alanındaki veya bölgedeki ayrı bir sunucuya geri yükleme gibi kurtarma eylemleri gerçekleştirmek sizin sorumluluğundadır.

• Notification: Microsoft bir bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Ancak, tek bir kaynağın durumunu izlemek için Azure Kaynak Durumu kullanabilir ve sorunları size bildirmek için Kaynak Durumu uyarıları ayarlayabilirsiniz. Ayrıca Azure Hizmet Durumu kullanarak tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlayabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

  MySQL için Azure Veritabanı, planlanmamış bir yük devretme gerçekleştiğinde Azure Kaynak Sağlığı'nda bir olay oluşturur.

• Etkin istekler: Kullanılabilirlik alanı kullanılamaz duruma geldiğinde, etkilenen bölgedeki sunuculara yönelik devam eden istekler sonlandırabilir. Uygulamaların bu istekleri yeniden denemesi gerekir. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

• Beklenen veri kaybı: Veri kaybı miktarı, sunucunuzun kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Bölge yedekli: Farklı bölgelerdeki birincil ve bekleme sunucuları arasında eşzamanlı çoğaltma nedeniyle bölge yük devretmesi sırasında sıfır veri kaybı beklenir.

  • Yerel olarak yedekli: Etkilenen bölgedeki sunuculardaki veriler, bölge kurtarana kadar kullanılamaz.

• Beklenen kapalı kalma süresi: Kapalı kalma süresi, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Bölge yedekli: Yük devretme genellikle 60 ila 120 saniye içinde tamamlanır. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

  • Yerel olarak yedekli: Etkilenen bir bölgedeki sunucular, kullanılabilirlik alanı kurtarana kadar kullanılamaz.

• Dağıt -ılması: Trafiği yeniden yönlendirme davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

  • Bölge yedekli: Yük devrinden sonra, bekleme sunucusu yeni birincil sunucu haline gelir ve yeni bağlantıları kabul etmeye başlar. Azure, kurtarıldıktan sonra özgün birincil bölgede otomatik olarak bir hazır bekleyen sunucu oluşturur. Daha fazla bilgi için bkz. Planlanmamış yük devri.

  • Yerel olarak yedekli: Bir bölge kullanılamıyorsa, sunucunuz kullanılamaz. Başka bir kullanılabilirlik alanında veya bölgede önceden oluşturduğunuz ayrı bir sunucunuz varsa, trafiği bu sunucuya yönlendirmek sizin sorumluluğundadır.

Bölge kurtarma

Bölge kurtarma davranışı, sunucunuzun kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

• Alanlar arası yedekli: Kullanılabilirlik alanı kurtarıldığında, MySQL için Azure Veritabanı kurtarılan bölgedeki bekleme sunucusunu otomatik olarak yeniden oluşturur ve geçerli birincil sunucuyla eşitler. Kurtarılan bölge, bekleme konumu olarak görev görür. Hizmet, gereksiz kesintileri önlemek için birincil rolü otomatik olarak özgün bölgeye geri taşımaz. Birincil bölgeyi orijinal bölgeye döndürmek istiyorsanız, planlı yük devretmeyi el ile başlatabilirsiniz.

• Yerel olarak yedekli: Bölge iyi durumda olduktan sonra, bölgedeki sunucular yeniden kullanılabilir duruma gelir. İş yüklerinizin gerektirdiği bölge kurtarma yordamları ve veri eşitlemesi sizin sorumluluğunuzdadır.

Bölge hataları için test

Bölge hataları için test seçenekleri, örneğinizin kullandığı kullanılabilirlik alanı yapılandırmasına bağlıdır.

• Bölge yedekli: Planlı yük devretme başlatarak uygulamanızın hata toleransını test edebilirsiniz. İş yükünüz çalışırken planlanmamış bir kesintiyi simüle etmek ve uygulamanızın kesinti süresini gözlemlemek için planlı yük devri kullanın. Simülasyonları üretim dışı ortamlarda veya sessiz bir zamanda çalıştırın. Daha fazla bilgi için Planlı yük devretme bölümüne bakın.

• Yerel olarak yedekli: Tam bölge kesintisi simülasyonu yapamazsınız, ancak bölge kesintisi sırasında oluşan durumlara benzer şekilde sunucunuzun kullanılamadığının benzetimini yapabilirsiniz. Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

  • Azure portalı: MySQL için Azure Veritabanı esnek sunucu örneğini durdurun ve başlatın.

  • Azure CLI: MySQL için Azure Veritabanı esnek bir sunucu örneğini yeniden başlatın, durdurun ve başlatın.

Bölge genelindeki hatalara dayanıklılık

MySQL için Azure Veritabanı, daha hızlı kurtarma için veritabanınızın eşitlenmiş bir kopyasını farklı bir bölgede tutmak için kullanabileceğiniz bölgeler arası okuma çoğaltmalarını destekler.

Bölgeler arası kurtarma sağlamak için desteklenen bölgelerde coğrafi olarak yedekli yedeklemeler de kullanabilirsiniz. Ancak yedeklemeler genellikle replikasyona göre daha fazla kapalı kalma süresine ve veri kaybına neden olur. Daha fazla bilgi için bkz . Yedekleme ve geri yükleme.

Bölgeler arası okuma replikaları

Veritabanlarınızı bölge düzeyindeki hatalardan korumak için okuma amaçlı çoğaltmalar dağıtın. Her okuma replikası ayrı bir MySQL için Azure Veritabanı sunucusudur. İkinci bir Azure bölgesine okuma replikası yerleştirdiğinizde, veritabanı sunucunuz bölge genelindeki bir soruna karşı dayanıklılık sağlayabilir. İsteğe bağlı olarak farklı Azure bölgelerinde olabilecek en fazla 10 okuma amaçlı çoğaltma dağıtabilirsiniz.

MySQL fiziksel çoğaltma teknolojisi, okuma amaçlı çoğaltmaları birincil bölgedeki kaynak sunucudan zaman uyumsuz olarak güncelleştirir. Bu, çoğaltmaların kaynağın gerisinde kalabileceği anlamına gelir. Bölgeler arası okuma amaçlı çoğaltmalar, genel olarak dağıtılmış uygulamaların gecikme süresini azaltmak veya kaynak sunucudan okuma trafiğini boşaltmak için isteğe bağlı olarak salt okunur iş yüklerine hizmet verebilir. Okuma kopyalarının özellikleri ve dikkat edilmesi gereken noktalar hakkında daha fazla bilgi için bkz. Okuma kopyaları.

Birincil bölgeniz devre dışı kalırsa, ikincil replikanızı birincil sunucu yapmak için yük devretme işlemini el ile gerçekleştirebilirsiniz. El ile yük devri gerçekleştirmek için çoğaltma işlemini durdurursunuz; bu işlem, okuma replikasını okuma-yazma sunucusuna yükseltir. Asenkron replikasyon nedeniyle failover veri kaybına neden olabilir. Uygulamanızın yeni birincil sunucuya bağlanması gerekir ve uygulamanın yeniden yapılandırılması sizin sorumluluğunuzdadır.

Gereksinimler

• Region support: MySQL için Azure Veritabanı destekleyen herhangi bir bölgede bölgeler arası okuma çoğaltmaları oluşturabilirsiniz. Azure’un eşleştirilmiş bölgeleriyle sınırlı değilsiniz.

• İşlem katmanları: Genel Amaçlı ve Bellek için İyileştirilmiş işlem katmanları okuma amaçlı çoğaltmaları destekler. Esnek katman, okuma replikalarını desteklemez.

Değerlendirmeler

• Yapılandırma farklılıkları: Bir çoğaltma oluşturduğunuzda, işlem oluşturma, sanal çekirdekler ve depolama gibi çeşitli ayarları kaynak sunucudan devralır. Bu değerleri oluşturduktan sonra okuma amaçlı çoğaltmada özelleştirebilirsiniz, ancak çoğaltmanın kaynaktaki değişikliklere ayak uydura çalıştığından emin olmak için eşit veya daha büyük değerler kullanmak en iyisidir.

• Çoğaltma gecikmesini izleme: Zaman uyumsuz çoğaltma işlemi, çeşitli faktörlere bağlı olarak değişebilen bir çoğaltma gecikmesi gerektirir. Çoğaltma gecikmesi çok yüksek olduğunda sunucunuzda sorunlarla karşılaşabilirsiniz. Sorunları yükseltmeden önce azaltabilmeniz için çoğaltma gecikmesini izlemek önemlidir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

• HA: Okuma amaçlı çoğaltmalarda HA etkinleştirilemez ve bunlara birincil sunucu olacak şekilde yük devri yapıldığında da HA özellikleri olmaz. Bir replikaya yük devri yapıldıktan sonra HA’yı yapılandırmak sizin sorumluluğunuzdadır.

Maliyet

Okuma amaçlı çoğaltmalar işlem ve depolama maliyetlerinin yanı sıra çoğaltma için bölgeler arası veri aktarımı ücretlerine neden olur. Ayrıntılı fiyatlandırma bilgileri için bkz. MySQL için Azure Veritabanı pricing ve Bandwidth pricing.

Çok bölgeli desteği yapılandırma

• Okuma amaçlı çoğaltma oluşturma: Okuma amaçlı çoğaltma oluşturmayı öğrenmek için aşağıdaki makalelere bakın:

  • Azure portalı: Azure portalını kullanarak MySQL için Azure Veritabanı Esnek Sunucusu'nda okuma çoğaltmaları nasıl oluşturulur ve yönetilir

  • Azure CLI: Azure CLI kullanarak MySQL için Azure Veritabanı Esnek Sunucu'da okuma çoğaltmaları nasıl oluşturulur ve yönetilir

  Kaynak sunucuyu oluşturduktan sonra çoğaltmaları yalnızca kaynak sunucu çalışıyorsa ve erişilebilir durumdaysa yapılandırabilirsiniz.

• Çoğaltmayı durdur: Çoğaltmayı durdurmayı öğrenmek için bkz. Çoğaltma sunucusuna çoğaltmayı durdurma.

• Okuma amaçlı çoğaltmayı silme: Okuma amaçlı çoğaltmayı silmeyi öğrenmek için bkz. Çoğaltma sunucusunu silme.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, sunucunuzu başka bir bölgede okuma amaçlı çoğaltmayla yapılandırdığınızda ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır:

• Bölgeler arasında trafik yönlendirme: Normal işlemler sırasında uygulamanızın okuma-yazma trafiğini birincil bölgedeki kaynak sunucuya yönlendirmesi gerekir. İsteğe bağlı olarak okuma isteklerini okuma çoğaltmasına yönlendirebilirsiniz.

• Bölgeler arasında veri çoğaltma: Bölgeler arası okuma çoğaltmaları, kaynak sunucu performansı üzerindeki etkiyi en aza indirmek için zaman uyumsuz çoğaltma kullanır. Çoğaltma gecikmesi miktarı, yazma yükü ve kaynak sunucu ile çoğaltmalar arasındaki gecikme süresi gibi çeşitli faktörlere bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak çok daha uzun olabilir. Daha fazla bilgi için bkz. Monitor çoğaltma ve ayrıntılı yönergeler için bkz. Azure portalında Monitor çoğaltma.

Bölge hatası sırasındaki davranış

Bu bölümde, bir sunucuyu bölgeler arası okuma-çoğaltma desteği için yapılandırdığınızda ve birincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve müdahale: Birincil bölgedeki bir hizmet kesintisini tespit etmekten ve manuel olarak yük devretmeyi tetiklemekten sorumlusunuz. Bu işlem, çoğaltılmamış verilerin kaybına neden olabilir.

  Önemli

  Yük devretmeyi tetikleme sorumluluğunuz vardır. Azure, bölge hatası oluşsa bile çoğaltmaları otomatik olarak okumak için yük devretme yapmaz.

  Yedek sisteme geçiş için aşağıdaki adımları uygulamanız gerekir:

  1. Çoğaltmayı durdurun. Bu işlem geri döndürülemez ve sunucu yeniden replika haline getirilemez. İşlem veri kaybına neden olur. Bu eylemin etkileri hakkında daha fazla bilgi için bkz. Çoğaltmayı durdurma.

  2. Uygulamanızı yeni birincil sunucuyu kullanacak şekilde yeniden yapılandırın.

  Daha fazla bilgi için bkz. Yük Devretme.

• Notification: Microsoft bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Ancak, Azure Hizmet Durumu kullanarak tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlayabilir ve sorunları size bildirmek için Service Health uyarıları ayarlayabilirsiniz.

• Etkin istekler: Kaynak sunucu kullanılamıyorsa, kaynak bölgeye yönelik tüm etkin bağlantılar bırakılır. Yük devretme işlemi tamamlandıktan sonra uygulamaların yeni birincil sunucuyla bağlantı oluşturmayı yeniden denemesi gerekir.

• Beklenen veri kaybı: Bölge kesintisi sırasında çoğaltmayı durduran bir yük devretme gerçekleştirmeniz gerekir. Bu işlem, kurtarılmamış verilerin kalıcı olarak kaybolmasına neden olur.

  Veri kaybı miktarı, kesinti sırasındaki çoğaltma gecikmesine bağlıdır. Çoğaltma gecikmesi genellikle en az birkaç dakikadır, ancak çok daha uzun olabilir. Daha fazla bilgi için bkz. Çoğaltmayı izleme.

• Beklenen kesinti süresi: Çoğaltmanın durdurulması, işlemi tetikledikten sonra genellikle iki dakika içinde tamamlanır. Uygulamalarınızı yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmak sizin sorumluluğunuzdadır. Yeniden yapılandırmayı gerçekleştirmeniz için geçen süre, genel kapalı kalma sürenize de katkıda bulunur.

• Trafik yeniden yönlendirme: Uygulamalarınızı yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmak sizin sorumluluğunuzdadır.

  Uyarı

  Birincil sunucu olmak için okuma amaçlı bir çoğaltmaya yük devreddikten sonra sunucuda HA etkinleştirilmez. HA'yı el ile etkinleştirmeniz veya otomasyonunuza eklemeniz gerekir.

Bölge geri kazanımı

Bölge kurtarıldığında, birincil bölgede operasyonları yeniden başlatmak için failback işlemlerinden siz sorumlusunuz. Microsoft birincil sunucuyu otomatik olarak taşımaz. Birincil bölgede yeni bir okuma amaçlı çoğaltma oluşturabilir, ardından bir yük devretme işlemi daha gerçekleştirerek birincil bölgedeki işlemleri geri yükleyebilirsiniz. Uygulamanızın kapalı kalma süresini veya veri kaybını tolere edip edemeyeceğine bağlı olarak aşağıdaki yaklaşımlardan birini göz önünde bulundurun:

• Uygulamanızı çevrimdışına alın ve çoğaltmanın tüm değişiklikleri yakalamasını bekleyin. Bu yaklaşım, çoğaltma gecikmesiyle yaklaşık aynı olan bir uygulama kesinti süresi gerektirir.

• Yük devretmeyi gerçekleştirin ve replike edilmemiş verilerin kaybını kabul edin.

Uygulamalarınızı gerektiğinde yeni birincil sunucuya bağlanacak şekilde yeniden yapılandırmaktan da sorumlu olduğunuzu unutmayın.

Bölge hataları testi

Süreçlerinizin geçerli olduğundan ve sunduğu olanakların kurtarma süresi hedefi (RTO) ile kurtarma noktası hedefi (RPO) gereksinimlerinizi karşıladığından emin olmak için okuma çoğaltması yük devretme süreçlerini düzenli olarak test edin.

Tüm bölgeler iyi durumda olsa bile, bir okuma replikasını birincil sunucuya geçiş (failover) yaparak istediğiniz zaman birincil sunucu haline getirebilirsiniz. Veri kaybına neden olabileceği ve el ile yeniden çalışma gerektirdiği için bu testleri üretim dışı bir ortamda gerçekleştirmenizi öneririz.

DR stratejinizin bir parçası olarak, düzenli olarak tam kurtarma tatbikatları çalıştırın. Bu tatbikatlar veri doğrulamayı, uygulama işlevi testlerini ve belgelenmiş geri alma prosedürlerini içerir.

Yedekleme ve geri yükleme

MySQL için Azure Veritabanı verilerinizi otomatik olarak yedekler, böylece yedekleme saklama süresi içinde belirli bir noktaya geri yükleyebilirsiniz. Bu koruma, verilerin yanlışlıkla bozulmasını ve silinmesini önlemenize yardımcı olur. Microsoft, sunucunun kullanılabilirliğini kesintiye uğratmadan yedeklemeleri tam olarak yönetir. Yedeklemeler hem tam yedeklemeleri hem de işlem günlüğü yedeklemelerini içerir.

• Yedekleme depolama alanı: Sunucuyu alanlar arası yedekli HA ile yapılandırırsanız, sistem yedeklemeleri ZRS'de depolar. SISTEM, HA olmadan veya yerel olarak yedekli HA ile yapılandırılan sunucular için yedekleri LRS'de depolar.

  Eşleştirilmiş Azure bölgelerinde, sunucuyu oluştururken yedeklemeler için coğrafi olarak yedekli depolamayı (GRS) yapılandırabilirsiniz. Bu yaklaşım, bölge hatalarına karşı ek koruma için yedekleri Azure eşleştirilmiş bölgeye çoğaltır. Sistem yedeklemeleri eşzamansız olarak çoğaltır.

  Varsayılan yedekleme saklama süresi 7 gündür, ancak saklama süresini 35 güne kadar uzatabilirsiniz. Tüm yedeklemeler şifrelenir.

• Geri yükleme: Belirli bir noktaya geri yükleme (PITR), yedekleme saklama süresi içinde veritabanınızı istediğiniz an geri yüklemenize olanak tanır. Geri yükleme işlemi, kullanıcı tarafından sağlanan yeni bir sunucu adıyla yeni bir veritabanı sunucusu oluşturur. Yeni sunucuyu kullanarak as-is veya ondan veri kopyalayabilirsiniz.

  Coğrafi olarak yedekli bir yedeklemeyi geri yüklerken, eşleştirilmiş bölgede yeni bir sunucu oluşturursunuz. Bazı bölgelerde, coğrafi yedekli bir yedeği, birincil bölgenizin eşlenik bölgesi olmayan bir bölgeye geri yüklemek için Evrensel Geo-Restore'u kullanabilirsiniz.

  Yanlışlıkla yapılan veri değişikliklerinden, uygulama hatalarından veya test senaryolarından kurtarmak için bu özelliği kullanın.

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

Daha fazla bilgi için MySQL için Azure Veritabanı'de Yedekleme ve geri yükleme bölümüne bkz.

Hizmet bakımına dayanıklılık

MySQL için Azure Veritabanı, altyapıdaki donanım, işletim sistemi ve veritabanı motoruna yama uygulanması da dahil olmak üzere kritik bakım görevlerini otomatik olarak gerçekleştirir. Hizmet, planlı bakımın bir parçası olarak güvenlik güncelleştirmelerini, yazılım güncelleştirmelerini ve ikincil sürüm yükseltmelerini içerir. Daha fazla bilgi için bkz. MySQL için Azure Veritabanı'de Planlı bakım.

Sunucunuzun bakım pencereleri sırasında kullanılabilir durumda kaldığından emin olmak için şu önerileri izleyin:

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için, bkz. Çevrimiçi hizmetler için SLAs.

MySQL için Azure Veritabanı, sunucunun yapılandırmasına göre farklı kullanılabilirlik SLA'ları sağlar:

• Alanlar arası yedekli HA ile yapılandırılmış sunucular.
• Yerel olarak yedekli HA ile yapılandırılan sunucular.
• HA olmadan yapılandırılan sunucular.

İlgili içerik

• Azure güvenilirlik
• MySQL için Azure Veritabanı için Mimari En İyi Uygulamaları
• İş sürekliliğini MySQL için Azure Veritabanı