MySQL'i şirket içi MySQL için Azure Veritabanı geçirme: Değerlendirme

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

Önkoşullar

Temsili Kullanım Örneği

Genel bakış

Bir MySQL iş yükünü doğrudan geçirmeden önce, gerçekleştirilmesi gereken makul miktarda durum tespiti vardır. Bu, Azure Giriş bölgesinin doğru yapılandırıldığını ve yakında geçirilecek iş yüklerini barındırmak için hazırlandığını doğrulamak için verileri, barındırma ortamını ve uygulama iş yüklerini çözümlemeyi içerir.

Sınırlamalar

MySQL için Azure Veritabanı, hizmet olarak platform olarak çalışan MySQL topluluk sürümünün tam olarak desteklenen bir sürümüdür. Ancak, bir ilk değerlendirme yaparken alışılması gereken bazı sınırlamalar vardır.

Bunlardan en önemlisi şunlardır:

• Yalnızca ve Memory için InnoDB depolama altyapısı desteği

• Sınırlı Privilege destek (DBA, SUPER, DEFINER)

• Devre dışı bırakılan veri işleme deyimleri (SELECT ... INTO OUTFILE, LOAD DATA INFILE)

• Otomatik önemli veritabanı geçişi (5,6 - 5,7, 5,7 - 8,0)

• MySQL Sunucusu Kullanıcı Tanımlı İşlevleri (UDF) kullanırken tek uygun barındırma seçeneği Azure Barındırılan VM'leridir çünkü veya dll bileşenini MySQL için Azure Veritabanı'a yükleme so özelliği yoktur.

Diğer öğelerin çoğu, yöneticilerin işletimsel veri iş yükü yaşam döngüsü yönetiminin bir parçası olarak tanımaları gereken operasyonel yönlerdir. Bu kılavuz, Geçiş Sonrası Yönetimi bölümünde bu işletimsel yönlerin çoğunu inceler.

MySQL sürümleri

MySQL, 1995'te başlayan zengin bir geçmişe sahiptir. O zamandan beri yaygın olarak kullanılan bir veritabanı yönetim sistemine dönüşmüştür. MySQL için Azure Veritabanı MySQL sürüm 5.6 desteğiyle başladı ve 5.7 ve yakın zamanda 8.0 sürümüne devam etti. en son MySQL için Azure Veritabanı sürüm desteği için Desteklenen MySQL için Azure Veritabanı sunucu sürümleri'ne bakın. Geçiş Sonrası Yönetimi bölümünde, Azure'daki MySQL örneklerine yükseltmelerin (5.7.20-5.7.21 gibi) nasıl uygulandığını gözden geçiriyoruz.

Not

5.x'ten 8.0'a atlama büyük ölçüde Oracle'ın MySQL'i satın almasından kaynaklandı. MySQL geçmişi hakkında daha fazla bilgi edinmek için MySQL wiki sayfasına gidin.

Kaynak MySQL sürümünü bilmek önemlidir. Sistemi kullanan uygulamalar, bu sürüme özgü veritabanı nesnelerini ve özelliklerini kullanıyor olabilir. Veritabanının daha düşük bir sürüme geçirilmesi uyumluluk sorunlarına ve işlevsellik kaybına neden olabilir. Ayrıca, sunulan özellikler uygulamanızı bozabileceğinden daha yeni bir sürüme geçmeden önce verilerin ve uygulama örneğinin kapsamlı bir şekilde test edilmiş olması önerilir.

Geçiş yolunu ve sürümünü etkileyebilecek örnekler:

• 5.6: Milisaniyelik doğru depolama ve tam metin araması için TIMESTAMP sütunu

• 5.7: Yerel JSON veri türü desteği

• 8.0: NoSQL Belge Deposu, atomik ve kilitlenmeye karşı güvenli DDL ve JSON tablo işlevleri desteği

  Not

  MySQL 5.6, Şubat 2021'de genel desteği kaybetti. MySQL iş yüklerinin 5.7 veya üzeri MySQL sürümüne geçirilmesi gerekir.

MySQL sunucu sürümünü denetlemek için:

SHOW VARIABLES LIKE "%version%";

Veritabanı depolama altyapıları

MySQL için Azure Veritabanı yalnızca destekler InnoDB ve Bellek veritabanı depolama altyapıları. MyISAM gibi diğer depolama altyapılarının desteklenen bir depolama altyapısına geçirilmesi gerekir. MyISAM ile InnoDB arasındaki farklar işletimsel özellikler ve performans çıkışıdır. Üst düzey tablolar ve şema yapısı genellikle altyapılar arasında değişmez, ancak dizin ve tablo sütun türleri depolama ve performans nedeniyle değişebilir. InnoDB'nin büyük veri dosyası boyutlarına sahip olduğu bilinse de, bu depolama ayrıntıları MySQL için Azure Veritabanı hizmeti tarafından yönetilir.

MyISAM'dan InnoDB'ye geçiş

MyISAM veritabanı ve tablolarının InnoDB tablolarına dönüştürülmesi gerekir. Dönüştürme işleminden sonra uygulamaların uyumluluk ve performans açısından test edilmesi gerekir. Çoğu durumda test, Tablonun yeniden yapılandırılmasını ve DDL deyimleri aracılığıyla hedef depolama altyapısının değiştirilmesini gerektirir. Bu değişikliğin, Azure hedefinde şema oluşturma sırasında gerçekleştiğinden geçiş sırasında gerçekleştirilmesi pek olası değil. Daha fazla ayrıntı için MySQL web sitesindeki tablo geliştiricileri dönüştürme belgelerini gözden geçirin.

Yararlı tablo bilgilerini bulmak için şu sorguyu kullanın:

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

Not

Birden çok veritabanında INFORMATION_SCHEMA karşı sorgu çalıştırmak performansı etkileyebilir. Düşük kullanım dönemlerinde çalıştırın.

Bir tabloyu MyISAM'dan InnoDB'ye dönüştürmek için aşağıdakileri çalıştırın:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Not

Bu dönüştürme yaklaşımı tablonun kilitlenmesine neden olur ve tüm uygulamalar işlem tamamlanana kadar bekleyebilir. Tablo kilitleme, veritabanının kısa bir süre çevrimdışı görünmesini sağlar.

Bunun yerine, tablo aynı yapıda ancak farklı bir depolama altyapısıyla oluşturulabilir. Oluşturulduktan sonra satırları yeni tabloya kopyalayın:

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Not

Bu yaklaşımın başarılı olması için özgün tablonun silinmesi ve ardından yeni tablonun yeniden adlandırılması gerekir. Bu görev kısa bir kapalı kalma süresine neden olur.

Veritabanı verileri ve nesneleri

Veriler, veritabanı geçişinin bileşenlerinden biridir. Uygulamaların güvenilir bir şekilde çalışmaya devam ettiğinden emin olmak için veritabanı destekleyen nesnelerin geçirilmesi ve doğrulanması gerekir.

Geçiş öncesinde ve sonrasında envantere eklemeniz gereken öğelerin listesi aşağıdadır:

• Tablolar (şema)

• Birincil anahtarlar, yabancı anahtarlar

• Dizinler

• İşlevler

• Yordamlar

• Tetikleyiciler

• Görünümler

Kullanıcı Tanımlı işlevler

MySQL, dış kodu çağıran işlevlerin kullanımına olanak tanır. Ne yazık ki dış kodlu Kullanıcı Tanımlı İşlevler (UDF) kullanan veri iş yükleri MySQL için Azure Veritabanı geçirilemez. Bunun nedeni, gerekli MySQL işlevinin bu nedenle veya dll kodunun Azure sunucusuna yüklenememesidir.

Yüklü olabilecek UDF'leri bulmak için aşağıdaki sorguyu çalıştırın:

SELECT * FROM mysql.func;

Kaynak sistemler

Geçiş hazırlığı miktarı, kaynak sisteme ve konumuna bağlı olarak değişebilir. Veritabanı nesnelerine ek olarak, verileri kaynak sistemden hedef sisteme nasıl alabileceğinizi de göz önünde bulundurun. Güvenlik duvarları ve diğer ağ bileşenleri kaynak ve hedef arasında olduğunda verilerin geçirilmesi zor olabilir.

Ayrıca verileri İnternet üzerinden taşımak, Azure'a ayrılmış devreleri kullanmaktan daha yavaş olabilir. Bu nedenle, çok sayıda gigabayt, terabayt ve petabayt veri taşırken, kaynak ağ ile Azure ağı arasında bir ExpressRoute bağlantısı ayarlamayı göz önünde bulundurun.

ExpressRoute zaten mevcutsa, bağlantı büyük olasılıkla diğer uygulamalar tarafından kullanılıyordur. Mevcut bir yol üzerinde geçiş gerçekleştirmek, ağ aktarım hızının zorlanmasına neden olabilir ve hem geçiş hem de ağı kullanan diğer uygulamalar için önemli bir performans isabeti oluşturabilir.

Son olarak, disk alanının değerlendirilmesi gerekir. Büyük bir veritabanını dışarı aktarırken verilerin boyutunu göz önünde bulundurun. Aracın çalıştığı sistemin ve sonuçta dışarı aktarma konumunun dışarı aktarma işlemini gerçekleştirmek için yeterli disk alanına sahip olduğundan emin olun.

Bulut sağlayıcıları

Amazon Web Services (AWS) gibi bulut hizmetleri sağlayıcılarından veritabanlarının geçirilmesi, bulutta barındırılan MySQL örneklerine erişmek için ek bir ağ yapılandırma adımı gerektirebilir. Data Migration Services gibi geçiş araçları, dış IP aralıklarından erişim gerektirir ve aksi takdirde engellenebilir.

Şirket içinde

Bulut sağlayıcıları gibi MySQL veri iş yükü de güvenlik duvarlarının veya diğer ağ güvenlik katmanlarının arkasındaysa, şirket içi örnek ile MySQL için Azure Veritabanı arasında bir yol oluşturulması gerekir.

Araçlar

MySQL veri iş yüklerini ve ortamlarını değerlendirmek için birçok araç ve yöntem kullanılabilir. Her araç farklı bir değerlendirme ve geçiş özellikleri ve işlevleri kümesi sağlar. Bu kılavuzun bir parçası olarak, MySQL veri iş yüklerini değerlendirmek için en yaygın kullanılan araçları gözden geçireceğiz.

Azure geçişi

Azure Geçişi, MySQL veritabanı iş yüklerinin doğrudan geçirilmesini desteklemese de, yöneticiler ister sanal ister donanım tabanlı bir makinede barındırılsın, verileri hangi kullanıcıların ve uygulamaların kullandığından emin olmadığında kullanılabilir. Bağımlılık analizi , MySQL iş yükünü barındıran makinede izleme aracısını yükleyip çalıştırarak gerçekleştirilebilir. Aracı, bilgileri bir ay gibi belirli bir süre içinde toplar. Veritabanına yapılan bilinmeyen bağlantıları bulmak için bağımlılık verileri analiz edilebilir. Bağlantı verileri, bekleyen geçiş hakkında bildirim alınması gereken uygulama sahiplerini belirlemeye yardımcı olabilir.

Azure Geçişi, uygulamaların ve kullanıcı bağlantı verilerinin bağımlılık analizine ek olarak, uygun hedef ortamı önermeye yardımcı olmak üzere veritabanı iş yüklerinin kullanım desenlerini sağlamak üzere Hyper-V, VMware veya fiziksel sunucuları analiz etmek için de kullanılabilir.

Linux için Telgraf

Linux iş yükleri, sanal ve fiziksel makinelerinizde veri toplamak için Microsoft Monitoring Agent'ı (MMA) kullanabilir. Ayrıca, performans ölçümlerinizi toplamak için Telegraf aracısını ve çok çeşitli eklentilerini kullanmayı göz önünde bulundurun.

Hizmet katmanları

Değerlendirme bilgileri (CPU, bellek, depolama vb.) ile donatılmış olan geçiş kullanıcısının bir sonraki tercihi, hangi MySQL için Azure Veritabanı fiyatlandırma katmanını kullanmaya başlayacağına karar vermektir.

Şu anda üç katman vardır:

• Temel: Hafif işlem ve G/Ç performansı gerektiren iş yükleri.

• Genel Amaçlı: Ölçeklenebilir G/Ç aktarım hızıyla dengeli işlem ve bellek gerektiren iş yüklerinin çoğu.

• Bellek için İyileştirilmiş: Daha hızlı işlem ve daha yüksek eşzamanlılık için bellek içi performans gerektiren yüksek performanslı veritabanı iş yükleri.

Katman kararı, veri iş yükünün RTO ve RPO gereksinimlerinden etkilenebilir. Veri iş yükü 4 TB'ın üzerinde depolama gerektirdiğinde ek bir adım gerekir. 16 TB'a kadar depolamayı destekleyen bir bölgeyi gözden geçirin ve seçin.

Karar alma süreci genellikle depolama ve IOPS veya Saniye Başına Giriş/Çıkış İşlemleri ihtiyaçlarına odaklanır. Bu nedenle, hedef sistemin her zaman en az kaynak sistemdeki kadar depolama alanına ihtiyacı vardır. Ayrıca, IOPS 3/GB ayrıldığından, IOP'lerin gereksinimlerini son depolama boyutuyla eşleştirmek önemlidir.

Faktörler	Katman
Temel	Geliştirme makinesi, 1 TB'tan az depolama alanıyla yüksek performansa gerek yoktur.
Genel Amaçlı	IOPS için temel katmanın sağlayabileceklerinden daha fazla ama 16 TB'tan küçük depolama alanı ve 4 GB'tan az bellek gerekir.
Bellek için İyileştirilmiş	Yüksek bellek veya yüksek önbellek kullanan veri iş yükleri ve yüksek eşzamanlılık innodb_buffer_pool_instances, büyük BLOB boyutları, çok sayıda çoğaltma kopyasına sahip sistemler gibi arabellekle ilgili sunucu yapılandırması.

Maliyetler

WWI MySQL veri iş yüklerinin tamamını değerlendirdikten sonra WWI, en az 4 sanal çekirdek ve 20 GB belleğe ve 450 IOPS IOP kapasitesine sahip en az 100 GB depolama alanına ihtiyaç duyacağını belirledi. 450 IOPS gereksinimi nedeniyle, MySQL için Azure Veritabanı IOP ayırma yöntemi nedeniyle en az 150 GB depolama alanı ayırmaları gerekir. Ayrıca, sağlanan sunucu depolama alanınızın en az %100'ünün yedek depolama alanı ve bir okuma amaçlı çoğaltma olması gerekir. 5 GB'tan fazla bir giden çıkış öngöremezler.

WWI, MySQL için Azure Veritabanı fiyatlandırma hesaplayıcısını kullanarak MySQL için Azure Veritabanı örneğinin maliyetlerini saptayabildi. 9/2020 itibarıyla, toplam sahip olma maliyetleri (TCO) WWI Konferans Veritabanı için aşağıdaki tabloda görüntülenir.

Kaynak	Açıklama	Miktar	Maliyet
İşlem (Genel Amaçlı)	4 sanal çekirdek, 20 GB	1 @ $0,351/saat	$3074,76 / yr
Depolama	5 GB	12 x 150 @ $0,115	$207 / yr
Backup	Sağlanan depolama alanının %100'e kadarı	Sağlanan sunucu depolama alanının %100'ünün ekstra maliyeti yoktur	$0,00 / yr
Okuma Amaçlı Çoğaltma	1 saniyelik bölge çoğaltması	işlem + depolama	$3281.76 / yr
Ağ	< 5 GB/ay çıkış	Ücretsiz
Toplam			$6563,52 / yr

İlk maliyetleri gözden geçirdikten sonra WWI'nin CIO'sunun Azure'da 3 yıldan çok daha uzun bir süre için olduğunu doğruladı. Fazladan ~$4K/yr tasarruf etmek için 3 yıllık yedek örnekleri kullanmaya karar verdiler.

Kaynak	Açıklama	Miktar	Maliyet
İşlem (Genel Amaçlı)	4 Sanal Çekirdek	1 @ $0,1375/sa	$1204,5 / yr
Depolama	5 GB	12 x 150 @ $0,115	$207 / yr
Backup	Sağlanan depolama alanının %100'e kadarı	Sağlanan sunucu depolama alanının %100'ünün ekstra maliyeti yoktur	$0,00 / yr
Ağ	< 5 GB/ay çıkış	Ücretsiz
Okuma Amaçlı Çoğaltma	1 saniyelik bölge çoğaltması	işlem + depolama	$1411,5 / yr
Toplam			$2823 / yr

Yukarıdaki tabloda gösterildiği gibi yedeklemeler, ağ çıkışı ve tüm okuma amaçlı çoğaltmalar toplam sahip olma maliyetinde (TCO) dikkate alınmalıdır. Daha fazla veritabanı eklendikçe, oluşturulan depolama ve ağ trafiği dikkate alınması gereken tek ek maliyet tabanlı faktör olacaktır.

Not

Yukarıdaki tahminler, uygulama katmanları için ExpressRoute, Azure Uygulaması Gateway, Azure Load Balancer veya App Service maliyetlerini içermez.

Yukarıdaki fiyatlandırma istediğiniz zaman değişebilir ve bölgeye göre değişir.

Uygulama etkileri

MySQL için Azure Veritabanı geçiş yaparken, güvenli yuva katmanı (SSL) tabanlı iletişime dönüştürme, uygulamalarınız için en önemli değişikliklerden biri olabilir. SSL, MySQL için Azure Veritabanı varsayılan olarak etkindir ve büyük olasılıkla şirket içi uygulama ve veri iş yükü SSL kullanarak MySQL'e bağlanacak şekilde ayarlanmamaktadır. Etkinleştirildiğinde SSL kullanımı ek işlem yükü ekler ve izlenmesi gerekir.

Not

SSL varsayılan olarak etkin olsa da, devre dışı bırakma seçeneğiniz vardır.

Uygulamayı bu güçlü kimlik doğrulama yolunu destekleyecek şekilde yeniden yapılandırmak üzere MySQL için Azure Veritabanı güvenli bir şekilde bağlanmak için uygulamanızda SSL bağlantısını yapılandırma bölümünde yer alan etkinlikleri izleyin.

Son olarak, uygulama bağlantı dizesi sunucu adını değiştirin veya DNS'yi yeni MySQL için Azure Veritabanı sunucusuna işaret etmek üzere değiştirin.

WWI senaryosu

WWI, aşağıdaki tabloda gösterildiği gibi MySQL veri varlığı hakkında bilgi toplayarak değerlendirmeye başladı.

Name	Source	Veritabanı Altyapısı	Size	IOPS	Sürüm	Sahip	Kesinti süresi
WwwDB	AWS (PaaS)	InnoDB	1 GB	150	5.7	Pazarlama Bölümü	1 sa
BlogDB	AWS (PaaS)	InnoDB	1 GB	100	5.7	Pazarlama Bölümü	4 saat
ConferenceDB	Şirket içinde	InnoDB	5 GB	50	5.5	Satış Bölümü	4 saat
CustomerDB	Şirket içinde	InnoDB	10 GB	75	5.5	Satış Bölümü	2 sa
SalesDB	Şirket içinde	InnoDB	20 GB	75	5.5	Satış Bölümü	1 sa

Kabul edilebilir kapalı kalma süresini belirlemek için her veritabanı sahibiyle iletişime geçildi. Seçilen planlama ve geçiş yöntemi kabul edilebilir veritabanı kapalı kalma süresini temel alır.

birinci aşama için WWI yalnızca ConferenceDB veritabanına odaklanmıştır. Ekip, devam eden veri iş yükü geçişlerine yardımcı olmak için geçiş deneyimine ihtiyaç duyduğundan. Basit veritabanı yapısı ve kabul edilebilir kapalı kalma süresinin büyük olması nedeniyle ConferenceDB veritabanı seçildi. Veritabanı geçirildikten sonra ekip, uygulamayı güvenli Azure giriş bölgesine geçirmeye odaklandı.

Değerlendirme denetim listesi

• İş yükünün hedef sistemde başarıyla çalıştığını test edin.

• Geçiş için doğru ağ bileşenlerinin sağlandığından emin olun.

• Veri iş yükü kaynak gereksinimlerini anlama.

• Toplam maliyetleri tahmin edin.

• Kapalı kalma süresi gereksinimlerini anlayın.

• Uygulama değişiklikleri yapmaya hazır olun.

Sonraki adım

Planlama