Aracılığıyla paylaş


MySQL için Azure Veritabanı - Esnek Sunucuda zamanlanmış bakım

MySQL için Azure Veritabanı Esnek Sunucu, yönetilen veritabanınızı güvenli, kararlı ve güncel tutmak için düzenli bakım gerçekleştirir. Bakım sırasında sunucu yeni özellikler, güncelleştirmeler ve düzeltme ekleri alır.

Önemli

MySQL için Azure Veritabanı Esnek Sunucu bakımı sırasında tüm sunucu işlemlerinden (değişiklikler, yapılandırma değişiklikleri, sunucuyu başlatma/durdurma) kaçının. Bu etkinliklerle ilgilenmek, öngörülemeyen sonuçlara yol açabilir ve bu da sunucu performansını ve kararlılığını etkileyebilir. Sunucu işlemlerini gerçekleştirmeden önce bakım bitene kadar bekleyin.

Bakım Döngüsü

Rutin Bakım

Standart bakım döngümüz her 30 günde bir daha az sıklıkta zamanlanır. Bu süre, hizmetlerinizde kesintiyi en aza indirirken sistem kararlılığını ve performansını sağlamamıza olanak tanır.

Kritik Bakım

Kullanılabilirlik ve veri bütünlüğünü korumak için kritik öneme sahip acil güvenlik düzeltmeleri veya güncelleştirmeleri dağıtma gereksinimi gibi bazı senaryolarda bakım daha sık gerçekleştirilebilir. Bu özel durumlar verilerinizi korumak ve hizmetlerinizin sürekli çalışmasını sağlamak için yapılır.

Sanal Kanarya Bakımı (Genel Önizleme)

Sanal Kanarya, güncelleştirmelere erken erişim sunan ve müşterilerin yeni Azure MySQL sürümleriyle iş yükü uyumluluğunu test etmesini sağlayan deneysel bir bakım programıdır. Sanal Kanarya, rutin bakımdan farklı olarak 30 günlük minimum boşluğu veya 7 günlük bildirim süresini izlemez. Bu program müşterilerin yeni özellikleri proaktif olarak doğrulamasına ve ürün geliştirmeleri için erken geri bildirimde bulunmaya yardımcı olur. Üretim dışı ortamlar için yaygın olarak kullanılan serileştirilebilir SKU sunucuları, Sanal Kanarya programına otomatik olarak kaydedilir.

Sanal Kanarya Kaydını Yönetme

MySQL için Azure Veritabanı, müşterilerin Sanal Kanarya programına katılımlarını yönetme esnekliği sağlar. Sanal Kanarya, bakım güncelleştirmelerine erken erişim sağlayarak proaktif uyumluluk testi ve yeni özelliklerle ilgili geri bildirim sağlar.

  • Sanal Kanarya Kaydını Denetleme

Sunucunuzun Sanal Kanarya programına kayıtlı olup olmadığını doğrulamak için aşağıdaki komutu kullanın:

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Sonuç öğesini içeriyorsa "patchStrategy": "VirtualCanary", sunucu Sanal Kanarya programına kaydedilir.

  • Sanal Kanarya'ya kaydolma

Bir sunucuyu Sanal Kanarya programına kaydetmek için aşağıdaki komutu çalıştırın:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
  • Sanal Kanaryadan Çıkma

Sanal Kanarya programından çıkmak ve standart bakım ilkesine dönmek için şu komutu kullanın:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular

Bu basit işlem, müşterilerin gerektiğinde Sanal Kanarya'ya katılmasını veya katılmamasını sağlayarak operasyonel gereksinimleriyle uyumlu olmasını sağlar.

Bakım Ayrıntılarını Bul

Her bakım güncelleştirmesinin ne gerektirdiği hakkında ayrıntılı bilgi için lütfen sürüm notlarımıza bakın. Bu notlar, bakım sırasında uygulanan güncelleştirmeler hakkında kapsamlı bilgiler sağlayarak ortamınızı etkileyen değişiklikleri anlamanıza ve bunlara hazırlanmanıza olanak tanır.

Not

Rutin veya Kritik olsun, zamanlanmış güncelleştirmeler sırasında tüm sunucular mutlaka bakımdan geçirilmeyecektir. Azure MySQL ekibi, hangi sunucuların bakım gerektirdiğini belirlemek için belirli ölçütleri devreye alır. Bu seçmeli yaklaşım, bakımın her sunucu ortamının benzersiz ihtiyaçlarına göre uyarlanmış ve üretiminizin kapalı kalma süresini en aza indiren hem verimli hem de gerekli olmasını sağlar.

Bakım penceresi seçme

Bakımı haftanın belirli bir günü ve o gün içindeki bir zaman penceresi için zamanlayabilirsiniz. Ya da sistemin sizin için otomatik olarak bir gün ve zaman aralığı seçmesine izin vekleyebilirsiniz. Her iki durumda da sistem herhangi bir bakım çalıştırmadan yedi gün önce sizi uyarır. Sistem ayrıca bakımın ne zaman başlatılacağını ve başarıyla tamamlandığını size bildirir.

Yaklaşan zamanlanmış bakımla ilgili bildirimler şu şekilde olabilir:

  • Belirli bir adrese e-postayla gönderildi
  • Azure Resource Manager Rolüne e-postayla gönderildi
  • Mobil cihazlara kısa mesajla (SMS) gönderilir
  • Azure uygulamasına bildirim olarak gönderilerek
  • Sesli mesaj olarak teslim edilerek

Bakım zamanlamasıyla ilgili tercihleri belirtirken haftanın gününü ve zaman aralığını belirleyebilirsiniz. Herhangi bir değer belirtmezseniz sistem, sunucunuzun bulunduğu bölgenin saatine göre akşam 11 ile sabah 7 arasında bir zaman seçer. Azure aboneliğinizdeki her Esnek Sunucu için farklı zamanlamalar tanımlayabilirsiniz.

Zamanlama ayarlarını istediğiniz zaman güncelleştirebilirsiniz. Esnek sunucunuz için zamanlanmış bir bakım varsa ve zamanlama tercihlerini güncelleştirirseniz, geçerli dağıtım zamanlandığı gibi devam eder ve zamanlama ayarları değişikliği, bir sonraki zamanlanmış bakım için başarıyla tamamlandığında geçerli olur.

Azure aboneliğinizdeki her Esnek Sunucu için sistem tarafından yönetilen zamanlama veya özel zamanlama tanımlayabilirsiniz.

  • Özel zamanlama ile, haftanın gününü ve bir saatlik zaman penceresini seçerek sunucu için bakım pencerenizi belirtebilirsiniz.
  • Sistem tarafından yönetilen zamanlama ile sistem, sunucunuzun bölge saatinde saat 23:00 ile 07:00 arasında bir saatlik bir zaman aralığı seçer.

Önemli

31 Ağustos 2024'ten itibaren MySQL için Azure Veritabanı artık serileştirilebilir SKU örnekleri için özel bakım pencerelerini desteklemeyecektir. Bu değişiklik, bakım süreçlerini basitleştirme, en iyi performansı sağlama gereksiniminden kaynaklanır ve serileştirilebilir SKU'larda özel bakım pencerelerini kullanan kullanıcı sayısının çok az olduğunu gösteren analizimizdir. Özel bakım penceresi yapılandırmalarına sahip mevcut serileştirilebilir SKU örnekleri etkilenmez; ancak, kullanıcılar bu özel bakım penceresi ayarlarını ileriye doğru değiştiremez.

Özel bakım pencereleri gerektiren müşteriler için, bu özelliği kullanmaya devam etmek için Genel Amaçlı veya İş Açısından Kritik SKU'lara yükseltmenizi öneririz.

Nadir durumlarda bakım olayı sistem tarafından iptal edilebilir veya başarıyla tamamlanamadı. Güncelleştirme başarısız olursa güncelleştirme geri alınır ve ikili dosyaların önceki sürümü geri yüklenir. Bu tür başarısız güncelleştirme senaryolarında, bakım penceresi sırasında sunucunun yeniden başlatılmasıyla karşılaşmaya devam edebilirsiniz. Güncelleştirme iptal edilirse veya başarısız olursa sistem, sırasıyla sizi bilgilendiren iptal edilmiş veya başarısız bakım olayı hakkında bir bildirim oluşturur. Bir sonraki bakım denemesi geçerli zamanlama ayarlarınıza göre zamanlanır ve 5 gün önceden bu konuda bildirim alırsınız.

Neredeyse sıfır kapalı kalma süresi bakımı (Genel önizleme)

MySQL için Azure Veritabanı Esnek Sunucunun "Sıfıra Yakın Kapalı Kalma Süresi Bakımı" özelliği,HA (Yüksek Kullanılabilirlik) özellikli sunucular. Bu özellik bakım kapalı kalma süresini önemli ölçüde azaltacak şekilde tasarlanmıştır ve çoğu durumda bakım kapalı kalma süresinin 40 ila 60 saniye arasında olması beklenir. Bu özellik, veritabanı işlemlerinde yüksek kullanılabilirlik ve en az kesinti gerektiren işletmeler için çok önemlidir.

Kesin Kapalı Kalma Süresi Beklentileri

  • Kapalı Kalma Süresi: Çoğu durumda, bakım sırasında kapalı kalma süresi 10 ila 30 saniye arasında değişir.
  • Ek Dikkat Edilmesi Gerekenler: Yük devretme olayından sonra, yaklaşık 30 saniyelik doğal bir DNS Yaşam Süresi (TTL) süresi vardır. Bu süre doğrudan bakım işlemi tarafından denetlenmiyor ancak DNS davranışının standart bir parçasıdır. Bu nedenle müşterinin bakış açısından bakım sırasında karşılaşılan toplam kapalı kalma süresi 40 ila 60 saniye arasında olabilir.

Sınırlamalar ve Önkoşullar

Bu özelliğin söz verdiği en iyi performansı elde etmek için belirli koşullar ve sınırlamalara dikkat edilmelidir:

  • Tüm Tablolarda Birincil Anahtarlar: Her tablonun birincil anahtarı olduğundan emin olmak kritik önem taşır. Birincil anahtarların olmaması çoğaltma gecikmesini önemli ölçüde artırarak kapalı kalma süresini etkileyebilir.
  • Bakım Sürelerinde Düşük İş Yükü: Kapalı kalma süresinin en düşük düzeyde kalmasını sağlamak için bakım süreleri, sunucudaki iş yükünün düşük olduğu sürelerle aynı olmalıdır. Yoğun olmayan saatlerde bakım zamanlamak için özel bakım penceresi özelliğini kullanmanızı öneririz.
  • Kapalı Kalma Süresi Garantileri: Bakım kapalı kalma süresini mümkün olduğunca düşük tutmaya çalışsak da, her koşulda her zaman 60 saniyeden kısa olacağını garanti etmeyiz. Yüksek iş yükü veya belirli sunucu yapılandırmaları gibi çeşitli faktörler daha uzun kapalı kalma süresine yol açabilir. En kötü durumda kapalı kalma süresi, tek başına sunucununkine benzer olabilir.

Bakım yeniden zamanlanmış

Bakım yeniden zamanlaması özelliği, MySQL için Azure Veritabanı Esnek Sunucu örneğinizdeki bakım etkinliklerinin zamanlaması üzerinde daha fazla denetim sağlar. Bir bakım bildirimi aldıktan sonra, sistem veya özel yönetilen olup olmadığına bakılmaksızın daha uygun bir zamana yeniden zamanlayabilirsiniz.

Parametreleri ve bildirimleri yeniden zamanlama

Yeniden zamanlama sabit zaman aralıklarıyla sınırlı değildir; genellikle bölgenin bakım penceresinin ilk gününden son gününe yayılan geçerli bakım döngüsündeki en erken ve izin verilen en son zamanlara bağlıdır. Yeniden zamanlandıktan sonra, standart bildirim ilkelerine uyarak değişiklikleri onaylamak için bir bildirim gönderilir.

Dikkat edilecekler ve sınırlamalar

Bu özelliği kullanırken aşağıdakilere dikkat edin:

  • Talep Kısıtlamaları: Aynı bölgede aynı anda gerçekleşen çok sayıda bakım etkinliği nedeniyle yeniden zamanlanmış bakımınız iptal edilebilir.
  • Kilitleme Süresi: Yeniden zamanlama, hizmetin güvenilirliğini korumak için başlangıçta zamanlanan bakım süresinden 15 dakika önce kullanılamaz.
  • Kısıtlamayı Yeniden Zamanla Aynı bölgede aynı anda çok fazla sunucu bakım için zamanlanmışsa, yeniden zamanlama istekleri başarısız olabilir. Bu durumda kullanıcılar bir hata bildirimi alır ve alternatif bir zaman aralığı seçmeleri tavsiye edilir. Başarıyla yeniden zamanlanan bakımın iptal edilme olasılığı düşüktür.

Bir bakımın kaç kez yeniden zamanlanmasıyla ilgili bir sınırlama yoktur; bakım "Hazırlıkta" durumuna girmediği sürece, bakımınızı istediğiniz zaman başka bir zamana yeniden zamanlayabilirsiniz.

Not

Olası ayarlamaları karşılamak için önizleme aşamasında bildirimleri yakından izlemenizi öneririz.

Kritik veritabanı işlemleri sırasında kesinti yaşanmasını önlemek için bu özelliği kullanın. Bu işlevselliği geliştirmeye devam ettikçe geri bildiriminizi öneririz.

SSS

S: Bazı sunucularım neden bakım bildirimleri alırken diğerleri almadı?

Y: Bakım başlangıç süreleri bölgeler arasında farklılık gösterdiğinden, farklı bölgelerdeki sunucular farklı zamanlarda bakım bildirimleri alabilir.

S: Aynı bölgedeki bazı sunucular neden bakım bildirimleri alırken diğerleri almadı?

Y: Bunun nedeni bildirim almayan sunucuların daha yakın zamanda oluşturulması ve sistemin henüz bakım gerektirmediğini belirlemesi olabilir.

S: Zamanlanmış bakımı geri çevirebilir miyim?

Y: Hayır, zamanlanmış bakımı geri çevirmeye izin verilmez. Ancak, zamanlamayı ayarlamak için bakım yeniden zamanlama özelliğini kullanabilir veya kapalı kalma süresini en aza indirmek için Yüksek Kullanılabilirlik (HA) özelliğini etkinleştirebilirsiniz. PaaS veritabanı ürünü olarak, veritabanınızın güvenliğini ve güvenilirliğini sağlamak için zamanında bakım yapmanız önemlidir.