en iyi MySQL için Azure Veritabanı performansı için en iyi yöntemler - Esnek Sunucu

Makale
12/19/2023

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

Önemli

MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?

Esnek MySQL için Azure Veritabanı sunucuyla çalışırken en iyi performansı elde etmeyi öğrenin. Platforma yeni özellikler ekledikçe, önerilerimizi bu bölümde iyileştirmeye devam edeceğiz.

Fiziksel yakınlık

Bir uygulamayı ve veritabanını aynı bölgeye dağıttığınıza emin olun. Herhangi bir performans karşılaştırma çalıştırmasına başlamadan önce hızlı bir denetim, basit bir SELECT 1 sorgusu kullanarak istemci ile veritabanı arasındaki ağ gecikmesini belirlemektir.

Web uygulaması ve ilişkili veritabanı gibi kaynaklar farklı bölgelerde çalıştığında, bu kaynaklar arasındaki iletişimde gecikme süresi artabilir. Uygulamanın ve veritabanının ayrı bölgelerde bulunmasının bir diğer olası etkisi de giden veri aktarımı maliyetleriyle ilgilidir.

Maliyet için iyileştirilmiş bir dağıtımda uygulamanın performansını ve güvenilirliğini artırmak için web uygulaması hizmetinin ve MySQL için Azure Veritabanı esnek sunucu kaynağının aynı bölgede ve kullanılabilirlik alanında bulunması kesinlikle önerilir. Bu birlikte bulundurma, gecikme süresine duyarlı uygulamalar için idealdir ve kaynaklar yakından eşleştirilmiş olduğundan en iyi aktarım hızını da sağlar.

Hızlandırılmış ağ

Azure sanal makinesi, Azure Kubernetes veya App Services kullanıyorsanız uygulama sunucusu için hızlandırılmış ağ kullanın. Hızlandırılmış Ağ, bir VM için tek kök G/Ç sanallaştırmasını (SR-IOV) etkinleştirir ve ağ performansını büyük ölçüde artırır. Bu yüksek performanslı yol, desteklenen VM türlerinde en zorlu ağ iş yükleriyle kullanılmak üzere gecikme süresini, titremeyi ve CPU kullanımını azaltarak veri yolundan konağı atlar.

Bağlan ion verimliliği

Yeni bağlantı kurmak her zaman pahalı ve zaman alan bir görevdir. Bir uygulama veritabanı bağlantısı istediğinde, yeni bir tane oluşturmak yerine var olan boşta veritabanı bağlantılarını ayırmaya öncelik sağlar. İyi bağlantı uygulamaları için bazı seçenekler şunlardır:

ProxySQL: Uygulama kodundaki değişikliklerle isteğe bağlı olarak, yerleşik bağlantı havuzu oluşturma ve iş yükünüzü birden çok okuma çoğaltmasına yük dengelemesi sağlayan ProxySQL kullanın.
Heimdall Veri Ara Sunucusu: Alternatif olarak, satıcı tarafından bağımsız bir özel proxy çözümü olan Heimdall Veri Proxy'sini de kullanabilirsiniz. Çoğaltma gecikmesi algılama ile sorgu önbelleğe almayı ve okuma/yazma bölmeyi destekler. Heimdall ara sunucusuyla MySQL Performansını hızlandırmaya da başvurabilirsiniz.
Kalıcı veya Uzun Ömürlü Bağlan: Uygulamanızın genellikle yürütme süresi < 5-10 ms olan kısa işlemleri veya sorguları varsa, kısa bağlantıları kalıcı bağlantılarla değiştirin. Kısa bağlantıları kalıcı bağlantılarla değiştirmek için kodda yalnızca küçük değişiklikler yapılması gerekir, ancak bunun birçok tipik uygulama senaryosunda performansı artırma açısından önemli bir etkisi vardır. İşlem tamamlandığında zaman aşımını ayarladığınızdan veya bağlantıyı kapattığınızdan emin olun.
Çoğaltma: Çoğaltma kullanıyorsanız, birincil sunucu ile okunabilir ikincil çoğaltma sunucusu arasındaki yükü dengelemek için ProxySQL kullanın. ProxySQL'i ayarlamayı öğrenin.

Bağlantı havuzu

Bağlan ion havuzu, veritabanı bağlantılarının oluşturulmasını ve ayrılmasını yöneten ve bir veritabanını bağlantı dalgalanmalarına karşı koruyan bir mekanizmadır. Uygulamanız görece kısa bir süre içinde birçok bağlantı açıyorsa ve bağlantılar kısa süreliyse bağlantı havuzu oluşturmayı göz önünde bulundurun. Bu tür bağlantılar, örneğin saniyede yüzlerce veya binlik bir büyüklük üzerinde gerçekleşebilir ve bunların kurulması ve kapatılması için gereken süre toplam bağlantı ömrüne kıyasla önemlidir.

Uygulamanızın geliştirme çerçevesi bağlantı havuzunu desteklemiyorsa, bunun yerine uygulama ve veritabanı sunucusu arasında ProxySQL veya Heimdall ara sunucusu gibi bir bağlantı ara sunucusu kullanın.

Bağlantı ölçeklendirmeyi işleme

Dalgalı talebi karşılamak için web uygulamalarını ölçeklendirmeye yönelik yaygın bir yaklaşım, uygulama sunucuları eklemek ve kaldırmaktır. Her uygulama sunucusu veritabanıyla bir bağlantı havuzu kullanabilir. Bu yaklaşım, bir veritabanı sunucusundaki toplam bağlantı sayısının uygulama sunucusu sayısına göre artmasına neden olur. Örneğin, bir veritabanı sunucusunda 10 uygulama sunucusu varsa ve her biri 100 veritabanı bağlantısı için yapılandırılmışsa, bu 1.000 veritabanı bağlantısı sağlar. Uygulama iş yükü daha yüksek kullanıcı etkinliği nedeniyle veya yoğun saatlerde ölçeklendirilirse ve ek 50 uygulama sunucusu eklenirse veritabanı bağlantıları toplam 6.000 olur. Genellikle, bu bağlantıların çoğu uygulama sunucuları tarafından oluşturulduktan sonra boşta kalır. Boşta kalan bağlantılar açık kalmak için kaynakları (bellek ve CPU) tükettiği için veritabanı ölçeklenebilirliği etkilenebilir.

Diğer olası zorluklar veritabanı sunucusuna yönelik toplam bağlantı sayısını işlemeyi içerir. Bu, veritabanı sunucusuna bağlı uygulama sunucularının sayısı tarafından dikte edilir ve her biri kendi bağlantı kümesini oluşturur. Bu senaryolarda, uygulama sunucularındaki bağlantı havuzlarını ayarlamayı göz önünde bulundurun. Veritabanı sunucusu tarafındaki bağlantılarda şişkinlik olmadığından emin olmak için her havuzdaki bağlantı sayısını kabul edilebilir bir minimuma düşürmeyi deneyin. Bunu, uygulamanın büyümesine yönelik kalıcı bir çözüm yerine uygulama sunucusu ölçeklendirmesinin etkilerini gidermek için kısa vadeli bir çözüm olarak düşünün.

Uzun vadeli bir çözüm olarak, veritabanı sunucusu ile uygulama sunucusu arasında ProxySQL veya Heimdall proxy gibi bir bağlantı ara sunucusu tanıtın. Bu yardımcı olur çünkü ara sunucu şunları yapacaktır:

Sabit sayıda bağlantıyla veritabanı sunucusuna bir bağlantı oluşturun.
Uygulama bağlantılarını kabul edin ve olası bağlantı fırtınaları için arabellek görevi görür.

Proxy'ler sorgu önbelleğe alma, bağlantı arabelleği oluşturma, sorgu yeniden yazma/yönlendirme ve yük dengeleme gibi diğer özellikleri sağlayabilir. Daha da fazla ölçeklenebilirlik için birden çok proxy örneği kullanmayı göz önünde bulundurun.

Hataya dayanıklılık ve daha hızlı kurtarma için Bağlan işleme

Uygulamalarınızı ve ortamınızı hataya dayanıklılık ve daha hızlı kurtarma için tasarlarken, veritabanı ortamında bağlantı kesintileri veya donanım hataları yaşama olasılığınız olduğunu göz önünde bulundurun. Ayrıca örnek boyutlarını ölçeklendirme, düzeltme eki uygulama ve el ile yük devretme gerçekleştirme gibi operasyonel eylemlere duyulan ihtiyacı da unutmayın.

Örneğin, veritabanı sunucunuzun yük devretme işlemini bir dakika içinde tamamladığı, ancak DNS TTL'nin uygulama tarafında çok uzun olması gibi nedenlerle uygulamanızın birkaç dakika daha çalışmadığı bir senaryo düşünün. Bu gibi durumlarda, TTL değerinin azaltılması daha hızlı kurtarma sağlar veya uygulama ile veritabanı sunucusu arasında bir bağlantı ara sunucusunu tümleştirmek bu tür hataların işlenmesine yardımcı olabilir.

Bölümleme

Üretim iş yükünüz son derece büyük tablolar kullandığında bölümleme, veritabanı performansını geliştirmek ve bakımı kolaylaştırmak için harika bir yöntemdir. Bölümleme, büyük tabloları yönetmeyi kolaylaştırır. Bu yaklaşım, büyük tabloları etkili bir şekilde yönetmek için bölümler eklemenize ve bırakmanıza olanak tanır. Bölümleme, tablo başına veya dizin başına iç kilitler gibi iç yapı çekişmelerini hafifleterek altyapının ölçeklendirilmesine de yardımcı olabilir (örneğin, InnoDB'deki btr_search_latch göz önünde bulundurun).

Örneğin beş bölüm ekleyerek, çok fazla etkinliği olan büyük bir tabloyu beş daha küçük, daha verimli tabloya bölersiniz. Bu, birincil işlemin tablodaki birincil anahtar aramaları olduğu durumlarda öncelikli olarak yardımcı olur, böylece sorgular "bölüm ayıklama" özelliğinden yararlanabilir. Ancak bölümleme, tablo taraması açısından da yardımcı olabilir.

Bölümlemenin avantajları olsa da bölümlenmiş tablolarda yabancı anahtar desteği olmaması, sorgu önbelleğinin olmaması gibi bazı sınırlamaları da olduğunu unutmayın. Bu sınırlamaların tam listesi için MySQL başvuru kılavuzunda Bölümlemeyle İlgili Kısıtlamalar ve Sınırlamalar bölümüne bakın.

Okuma ve yazma işlemlerini ayırma

Çoğu uygulama öncelikli olarak veritabanından okur ve yazma işlemleriyle ilgili etkileşimlerin yalnızca küçük bir yüzdesi vardır. Bağlantı havuzları için hesapladığımız birincil veritabanındaki etkin bağlantı sayısı büyük olasılıkla okuma trafiğini içerir. Çoğaltmaları okumak için mümkün olduğunca çok sorgunun boşaltılması ve birincil yazılabilir örneğe erişimin korunması, birincil veritabanındaki yükü artırmadan uygulama sunucuları tarafından gerçekleştirilen genel veritabanı etkinliğinin miktarını artırır. Okuma amaçlı çoğaltmalara en azından raporlar gibi daha uzun süre çalışan sorgular için erişmiyorsanız, raporlamayı veya analizi okuma amaçlı çoğaltmalara hemen taşımayı göz önünde bulundurmanız gerekir.

Çoğaltmalar, çoğaltmanın zaman uyumsuz yapısı nedeniyle birincil kopyanın biraz gerisinde kaldığı için okuma amaçlı çoğaltmaların daha geniş ölçekli kullanımı daha dikkatli düşünülebilir. Uygulamanın küçük kod değişiklikleriyle çoğaltmalardan okumalarla birlikte sağlanabilecek mümkün olduğunca çok alanı bulun. Bu yöntemi önbelleğe almayla ilgili daha yüksek düzeylerde de uygulamanız gerekir; Redis için Azure Cache gibi ayrılmış bir önbelleğe alma katmanından salt okunur veya yavaş değişen içerikten daha fazlasını sunmanız gerekir.

Yazma ölçeklendirme ve parçalama

Zaman içinde uygulamalar gelişir ve yeni işlevler eklenir. Kolaylık veya genel uygulama nedeniyle tablolar birincil veritabanına eklenir. Veritabanında artan trafik yüklerini işlemek için, uygulamanın ayrı veritabanlarına kolayca taşınabilecek alanlarını belirleyin ve veritabanını yatay olarak parçalama veya dikey olarak bölmeyi göz önünde bulundurun.

Veritabanını yatay olarak parçalama, ayrı veritabanlarında uygulama şemasının birden çok kopyasını oluşturarak ve müşteri kimliğine, coğrafyaya veya başka bir müşteri başına veya kiracı özniteliğine göre müşterileri ve tüm ilişkili verileri ayırarak çalışır. Bu, tek tek müşterilerin küçük olduğu ve uygulama üzerindeki yükün milyonlarca müşterinin toplam kullanımından kaynaklandığı SaaS veya B2C uygulamalarında çok iyi çalışır. Ancak müşterilerin farklı boyutlarda olduğu ve tek tek büyük müşterilerin belirli bir parça için trafik yüküne hakim olabileceği B2B uygulamalarında daha zordur.

Veritabanını işlevsel olarak parçalayarak ve ayrı uygulama etki alanlarını (veya mikro hizmetleri) kendi veritabanlarına taşıyarak yükü dikey olarak bölün. Bu, yükü birincil veritabanından hizmet başına veritabanlarına ayırır. Basit örnekler, yoğun olarak yüklenen siparişler tablosuyla aynı veritabanında olması gerekmeyen bir günlük tablosu veya site yapılandırma bilgileridir. Siparişler veya karşılama etki alanları dışında müşteri ve hesap etki alanlarının bozulması daha karmaşık örneklerdir. Bazı durumlarda, örneğin e-posta veya arka plan işi kuyruklarını kendi içinde olacak şekilde değiştirmek ve müşteri veya sipariş tablosuna yeniden katılmayı gerektirmemek gibi uygulama değişiklikleri gerekebilir. Var olan tabloları ve verileri yeni bir birincil veritabanına taşımak, MySQL için Azure Veritabanı esnek sunucu okuma çoğaltmaları ile gerçekleştirilebilir ve çoğaltmayı ve uygulamanın bölümlerini yeni oluşturulan yazılabilir veritabanına yönlendirir. Yeni oluşturulan veritabanının bağlantı havuzlarıyla erişimi sınırlaması, sorguları ayarlaması ve yükü özgün birincil gibi kendi çoğaltmalarıyla yayması gerekir.

Veri içeri aktarma yapılandırmaları

Bir veri içeri aktarma işlemi başlatmadan önce örneğinizi geçici olarak daha yüksek SKU boyutuna ölçeklendirin ve içeri aktarma başarılı olduğunda ölçeği azaltabilirsiniz.
Çevrimiçi veya çevrimdışı geçişler için Azure Veritabanı Geçiş Hizmeti (DMS) kullanarak verilerinizi en düşük kapalı kalma süresiyle içeri aktarabilirsiniz.

Esnek sunucu belleği önerilerini MySQL için Azure Veritabanı

MySQL için Azure Veritabanı esnek sunucu performansı için en iyi yöntem, çalışma kümenizin neredeyse tamamen bellekte bulunması için yeterli RAM ayırmaktır.

Esnek MySQL için Azure Veritabanı sunucu ölçümlerini kullanarak sınırlara ulaşmak için kullanılan bellek yüzdesinin olup olmadığını denetleyin.
Sunucunun sınırlara ulaştığından emin olmak için bu tür numaralarda uyarılar ayarlayın ve bunu düzeltmek için istem eylemleri gerçekleştirebilirsiniz. Tanımlanan sınırlara bağlı olarak, veritabanı SKU'sunun ölçeğini artırmanın daha yüksek işlem boyutuna mı yoksa daha iyi fiyatlandırma katmanına mı, yani performansta önemli bir artışa neden olup olmadığını denetleyin.
Ölçeklendirme işleminden sonra performans sayılarınızın önemli ölçüde düşmeyinceye kadar ölçeği artırabilirsiniz. Veritabanı örneğinin ölçümlerini izleme hakkında bilgi için bkz. esnek sunucu veritabanı ölçümleri MySQL için Azure Veritabanı.

InnoDB arabellek havuzunu kullanma Isınma

MySQL için Azure Veritabanı esnek sunucu örneği yeniden başlatıldıktan sonra, tablolar sorgulandığından depolamada bulunan veri sayfaları yüklenir ve bu da sorguların ilk yürütülmesi için gecikme süresinin artmasına ve performansın yavaşlamasına neden olur. Gecikme süresine duyarlı iş yükleri için bu kabul edilebilir olmayabilir.

InnoDB arabellek havuzu ısınmasını kullanmak, DML veya SELECT işlemlerinin ilgili satırlara erişmesini beklemek yerine yeniden başlatmadan önce arabellek havuzundaki disk sayfalarını yeniden yükleyerek ısınma süresini kısaltır.

InnoDB arabellek havuzu sunucu parametrelerini yapılandırarak performans avantajını temsil eden MySQL için Azure Veritabanı esnek sunucu örneğinizi yeniden başlattıktan sonra ısınma süresini azaltabilirsiniz. InnoDB, sunucu kapatma sırasında her arabellek havuzu için en son kullanılan sayfaların yüzdesini kaydeder ve bu sayfaları sunucu başlangıcında geri yükler.

İyileştirilmiş performansın sunucu için daha uzun başlatma süresinden kaynaklandığını da unutmayın. Bu parametre etkinleştirildiğinde, sunucuda sağlanan IOPS'ye bağlı olarak sunucu başlatma ve yeniden başlatma süresinin artması beklenir.

Sunucu bu süre boyunca kullanılamadığından başlatma/yeniden başlatma performansının kabul edilebilir olduğundan emin olmak için yeniden başlatma süresini test edip izlemenizi öneririz. Sağlanan 1000'den az IOPS ile (veya sağlanan depolama alanı 335 GB'tan az olduğunda) bu parametrenin kullanılması önerilmez.

Sunucu kapatma sırasında arabellek havuzunun durumunu kaydetmek için sunucu parametresini innodb_buffer_pool_dump_at_shutdown olarak ONayarlayın. Benzer şekilde, sunucu başlatma sırasında arabellek havuzu durumunu geri yüklemek için sunucu parametresini innodb_buffer_pool_load_at_startupON olarak ayarlayın. Sunucu parametresinin innodb_buffer_pool_dump_pctdeğerini düşürerek ve ince ayar yaparak başlatma/yeniden başlatma süresi üzerindeki etkisini denetleyebilirsiniz. Varsayılan olarak, bu parametre olarak 25ayarlanır.

Dekont

InnoDB arabellek havuzu ısınma parametreleri yalnızca 16 TB'a kadar depolama alanı olan genel amaçlı depolama sunucularında desteklenir. Daha fazla bilgi için bkz. esnek sunucu depolama seçeneklerini MySQL için Azure Veritabanı.