MySQL için Azure Veritabanı ile uygulama oluşturmaya yönelik en iyi yöntemler
Ş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?
MySQL için Azure Veritabanı kullanarak buluta hazır bir uygulama oluşturmanıza yardımcı olacak bazı en iyi yöntemler aşağıdadır. Bu en iyi yöntemler uygulamanızın geliştirme süresini kısaltabilir.
Uygulama ve veritabanı kaynaklarının yapılandırması
Uygulamayı ve veritabanını aynı bölgede tutma
Uygulamanızı Azure'da dağıtırken tüm bağımlılıklarınızın aynı bölgede olduğundan emin olun. Örneklerin bölgelere veya kullanılabilirlik alanlarına yayılması ağ gecikme süresine neden olur ve bu durum uygulamanızın genel performansını etkileyebilir.
MySQL sunucunuzun güvenliğini sağlama
MySQL sunucunuzu güvenli olacak ve genel olarak erişilmeyecek şekilde yapılandırın. Sunucunuzun güvenliğini sağlamak için şu seçeneklerden birini kullanın:
Güvenlik için her zaman SSL üzerinden MySQL sunucunuza bağlanmanız ve MySQL sunucunuzu ve uygulamanızı TLS 1.2 kullanacak şekilde yapılandırmanız gerekir. Bkz. SSL/TLS'yi yapılandırma.
AKS ile gelişmiş ağ kullanma
Vm'de hızlandırılmış ağ etkinleştirildiğinde, VM'de daha düşük gecikme süresi, daha az değişim ve daha az CPU kullanımı olur. Daha fazla bilgi edinmek için bkz. Azure Kubernetes Service ve MySQL için Azure Veritabanı için en iyi yöntemler.
Sunucu parametrelerinizi ayarlama
Okuma ağırlıklı iş yükleri için sunucu parametrelerini tmp_table_size ayarlama ve max_heap_table_size daha iyi performans için iyileştirmeye yardımcı olabilir. Bu değişkenler için gereken değerleri hesaplamak için toplam bağlantı başına ve temel bellek değerlerine bakın. sunucunun toplam belleği için temel bellek hesaplarıyla birleştirilmiş, hariç tmp_table_sizebağlantı başına bellek parametrelerinin toplamı.
ve'nin tmp_table_sizemax_heap_table_sizemümkün olan en büyük boyutunu hesaplamak için aşağıdaki formülü kullanın:
(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections
Dekont
Toplam bellek, sunucunun sağlanan sanal çekirdeklerde sahip olduğu toplam bellek miktarını gösterir. Örneğin, Genel Amaçlı iki sanal çekirdek MySQL için Azure Veritabanı sunucusunda toplam bellek 5 GB * 2 olur. Fiyatlandırma katmanı belgelerinde her katman için bellek hakkında daha fazla ayrıntı bulabilirsiniz.
Temel bellek, ve innodb_buffer_pool_sizegibi query_cache_size MySQL'in sunucu başlangıcında başlatılacağı ve ayrılacağı bellek değişkenlerini gösterir. ve join_buffer_sizegibi sort_buffer_size bağlantı başına bellek, yalnızca bir sorguya ihtiyaç duyduğunda ayrılan bellektir.
Yönetici olmayan kullanıcılar oluşturma
Her veritabanı için yönetici olmayan kullanıcılar oluşturun. Genellikle, kullanıcı adları veritabanı adları olarak tanımlanır.
Parolanızı sıfırlama
Azure portalını kullanarak MySQL sunucunuz için parolanızı sıfırlayabilirsiniz.
Üretim veritabanı için sunucu parolanızı sıfırlamak uygulamanızı düşürebilir. Uygulamanızın kullanıcıları üzerindeki etkiyi en aza indirmek için yoğun olmayan saatlerde tüm üretim iş yüklerinin parolasını sıfırlamak iyi bir uygulamadır.
Performans ve dayanıklılık
Uygulamanızın performans sorunlarını ayıklamaya yardımcı olacak birkaç araç ve uygulama aşağıdadır.
Performans sorunlarını belirlemek için yavaş sorgu günlüklerini etkinleştirme
Sunucunuzda yavaş sorgu günlüklerini ve denetim günlüklerini etkinleştirebilirsiniz. Yavaş sorgu günlüklerini çözümlemek, sorun gidermeye yönelik performans sorunlarını belirlemeye yardımcı olabilir.
Denetim günlükleri Azure İzleyici günlükleri, Azure Event Hubs ve depolama hesaplarındaki Azure Tanılama günlükler aracılığıyla da kullanılabilir. Bkz. Sorgu performansı sorunlarını giderme.
Bağlantı havuzunu kullanma
Veritabanı bağlantılarının yönetilmesi, uygulamanın bir bütün olarak performansı üzerinde önemli bir etkiye sahip olabilir. Performansı iyileştirmek için, bağlantıların kurulma sayısını ve anahtar kod yollarında bağlantı kurma süresini azaltmanız gerekir. Dayanıklılığı ve performansı geliştirmek üzere MySQL için Azure Veritabanı bağlanmak için bağlantı havuzu oluşturmayı kullanın.
Bağlantıları verimli bir şekilde yönetmek için ProxySQL bağlantı havuzu oluşturucuyu kullanabilirsiniz. Bağlantı havuzu oluşturucu kullanmak, boşta bağlantıları azaltabilir ve mevcut bağlantıları yeniden kullanabilir ve bu da sorunların önlenmesine yardımcı olur. Daha fazla bilgi edinmek için bkz . ProxySQL'i ayarlama.
Geçici hataları işlemek için yeniden deneme mantığı
Uygulamanız, veritabanına bağlantıların aralıklı olarak bırakıldığı veya kaybolduğu geçici hatalarla karşılaşabilir. Bu gibi durumlarda sunucu, 5-10 saniye içinde bir-iki yeniden denemeden sonra çalışır durumdadır.
İlk yeniden denemenizden önce 5 saniye beklemek iyi bir yöntemdir. Ardından beklemeyi kademeli olarak 60 saniyeye kadar artırarak her yeniden denemeyi izleyin. Yeniden deneme sayısı üst sınırını sınırlayın; bu noktada uygulamanızın işlemin başarısız olduğunu göz önünde bulundurarak daha fazla araştırma yapabilirsiniz. Daha fazla bilgi edinmek için bkz . Bağlantı hatalarını giderme.
Yük devretmeleri azaltmak için okuma çoğaltmasını etkinleştirme
Yük devretme senaryoları için Veri İçi Çoğaltma'yı kullanabilirsiniz. Okuma amaçlı çoğaltmalar kullanılırken kaynak ve çoğaltma sunucuları arasında otomatik yük devretme gerçekleşmez.
Çoğaltma zaman uyumsuz olduğundan kaynak ile çoğaltma arasında bir gecikme olduğunu fark edeceksiniz. Ağ gecikmesi, kaynak sunucuda çalışan iş yükünün boyutu ve veri merkezleri arasındaki gecikme süresi gibi birçok faktörden etkilenebilir. Çoğu durumda çoğaltma gecikmesi birkaç saniye ile birkaç dakika arasında değişir.
Veritabanı dağıtımı
CI/CD dağıtım işlem hattınızda MySQL için Azure veritabanı görevi yapılandırma
Bazen değişiklikleri veritabanınıza dağıtmanız gerekir. Böyle durumlarda, Azure Pipelines aracılığıyla sürekli tümleştirme (CI) ve sürekli teslim (CD) kullanabilir ve mySQL sunucunuz için bir görev kullanarak veritabanını ona karşı özel bir betik çalıştırarak güncelleştirebilirsiniz.
El ile veritabanı dağıtımı için etkili bir işlem kullanma
El ile veritabanı dağıtımı sırasında kapalı kalma süresini en aza indirmek veya başarısız dağıtım riskini azaltmak için şu adımları izleyin:
- mysqldump veya MySQL Workbench kullanarak yeni bir veritabanında üretim veritabanının kopyasını oluşturun.
- Yeni veritabanını yeni şema değişikliklerinizle veya veritabanınız için gereken güncelleştirmelerle güncelleştirin.
- Üretim veritabanını salt okunur duruma getir. Dağıtım tamamlanana kadar üretim veritabanında yazma işlemleriniz olmasaydı en iyisi olurdu.
- Uygulamanızı 1. adımdaki yeni güncelleştirilmiş veritabanıyla test edin.
- Uygulama değişikliklerinizi dağıtın ve uygulamanın yeni veritabanını en son güncelleştirmelerle birlikte kullandığından emin olun.
- Değişiklikleri geri almak için eski üretim veritabanını koruyun. Daha sonra eski üretim veritabanını silmek veya gerekirse Azure Depolama dışarı aktarmak için değerlendirebilirsiniz.
Dekont
Uygulama bir e-ticaret uygulaması gibiyse ve bunu salt okunur duruma getiremiyorsanız, yedekleme yaptıktan sonra değişiklikleri doğrudan üretim veritabanına dağıtın. Bu değişiklikler, bazı kullanıcılar başarısız isteklerle karşılaşabileceğinden, etkiyi en aza indirmek için uygulamaya yönelik trafiğin düşük olduğu yoğun olmayan saatlerde gerçekleşmelidir.
Uygulama kodunuzun başarısız istekleri de işlediğine emin olun.
İş yükünüzün bellek içi geçici tablo boyutlarını aşıp aşmadiğini görmek için MySQL yerel ölçümlerini kullanın
Yoğun okuma içeren bir iş yüküyle, MySQL sunucunuza yönelik sorgular bellek içi geçici tablo boyutlarını aşabilir. Yoğun okuma içeren bir iş yükü, sunucunuzun diske geçici tablolar yazmaya geçmesine neden olabilir ve uygulamanızın performansını etkileyebilir. Sunucunuzun geçici tablo boyutunu aşmanın bir sonucu olarak diske yazıp yazmadığını belirlemek için aşağıdaki ölçümlere bakın:
show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';
Ölçüm, created_tmp_disk_tables diskte kaç tablo oluşturulduğunu gösterir. İş yükünüz göz önüne alındığında ölçüm, created_tmp_table bellekte kaç geçici tablo oluşturulması gerektiğini belirtir. Belirli bir sorgunun geçici tablolar kullanıp kullanmadığını belirlemek için sorguda EXPLAIN deyimini çalıştırın. Sütundaki extra ayrıntı, sorgunun geçici tablolar kullanılarak çalıştırılıp çalıştırılamadığını gösterir Using temporary .
Disklere taşan sorgularla iş yükünüzün yüzdesini hesaplamak için aşağıdaki formüldeki ölçüm değerlerinizi kullanın:
(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100
İdeal olan bu yüzdenin %25'ten az olmasıdır. Yüzde %25 veya daha büyükse, tmp_table_size ve max_heap_table_size iki sunucu parametresini değiştirmenizi öneririz.
Veritabanı şeması ve sorguları
Veritabanı şemanızı ve sorgularınızı oluştururken hatırlamanız gereken birkaç ipucu aşağıdadır.
Tablo sütunlarınız için doğru veri türünü kullanma
Depolamak istediğiniz veri türüne göre doğru veri türünü kullanmak, yanlış veri türleri nedeniyle depolamayı iyileştirebilir ve hataları azaltabilir.
Dizinleri kullanma
Yavaş sorgulardan kaçınmak için dizinleri kullanabilirsiniz. Dizinler, belirli sütunlara sahip satırları hızla bulmanıza yardımcı olabilir. Bkz. MySQL'de dizinleri kullanma.
SELECT sorgularınız için EXPLAIN kullanma
EXPLAIN Sorgunuzu çalıştırmak için MySQL'in neler yaptığına ilişkin içgörüler elde etmek için deyimini kullanın. Sorgunuzdaki performans sorunlarını veya sorunları algılamanıza yardımcı olabilir. Bkz. Sorgu performansının profilini almak için EXPLAIN'ı kullanma.