Tänker du komma igång med världens mest populära databas med öppen källkod och undrar hur du ska ställa in ditt MySQL-värd? Så många använder Amazon RDS som standard när MySQL presterar exceptionellt bra på Azure Cloud. Även om Microsoft Azure erbjuder en hanterad lösning, Azure Database, har lösningen några stora begränsningar som du bör känna till innan du migrerar dina MySQL-distributioner. I det här inlägget beskriver vi det bästa sättet att vara värd för MySQL på Azure, inklusive hanterade lösningar, instanstyper, replikering med hög tillgänglighet, säkerhetskopiering och disktyper att använda för att optimera din molndatabas prestanda.
MySQL DBaaS vs. Self-Managed MySQL
Det första du bör tänka på när du väger mellan självförvaltning och en MySQL Database-as-a-Service (DBaaS)-lösning är vilka interna resurser du har tillgängliga. Om du läser detta vet du förmodligen redan omfattningen av operativa uppgifter som är förknippade med att underhålla en produktionsinstallation, men för en snabb sammanfattning finns det provisionering, avprovisionering, master-slave-konfigurationer, säkerhetskopiering, skalning, uppgraderingar, loggrotationer, OS-patchning , och övervakning för att nämna några.
En intern MySQL-expert, eller ett team av DBA:s beroende på din applikationsstorlek, kan säkert hantera dessa med din organisation åt dig, men frågan blir var du vill att ditt teams ansträngningar ska fokuseras . Många bestämmer sig för att flytta till en MySQL DBaaS för att automatisera dessa tidskrävande uppgifter så att de kan fokusera mer på utveckling och optimering av sina applikationsdatabaser. Ett bra exempel skulle vara långsam frågeanalys. Medan nästan alla DBaaS erbjuder ett MySQL Slow Query Analyzer-verktyg för att identifiera problemfrågor, kräver denna uppgift fortfarande mänsklig skicklighet och intuition för att avgöra hur man optimerar dessa frågor som påverkar deras applikationsprestanda.
Oavsett om du är ett nystartat företag eller ett Fortune 500-företag, kommer du att upptäcka att många organisationer väljer att utnyttja en DBaaS för att optimera sin DBA-tid, samtidigt som samma företagstyper och -storlekar väljer också att hålla fast vid intern självförvaltning. För många företag handlar beslutet till stor del om anpassning och kontroll. Det är därför vi varnar för att använda Azure Database som standard, eller dess AWS-konkurrent, Amazon RDS, eftersom de inte tillåter dig att behålla MySQL-superanvändaråtkomst eller ens SSH-åtkomst till dina maskiner. Dessutom är möjligheten att anpassa din installationskonfiguration mycket begränsad, såsom instanstyper, RAM, diskstorlek eller IOPS du kan använda. Du kommer att lära dig mer om de bästa instanstyperna och diskarna att använda nedan, och du kan kolla in den här MySQL-leverantörsjämförelsen för att se fördelarna och begränsningarna med de fyra främsta hanterade MySQL-lösningarna, ScaleGrid, Compose, Azure Database och Amazon RDS.
Hög tillgänglighetsimplementering
Om du distribuerar i produktion bör du alltid ställa in MySQL som en master-slave-distribution. Fristående distributioner är en enda nod utan någon replikering och bör egentligen bara användas för utvecklings- eller testmiljöer. Med master-slave-distributioner kan du konfigurera hög tillgänglighet så om en av dina noder går ner kan du failover till en slav med noll driftstopp. Detta är vanligtvis konfigurerat antingen som en 3-nods master-slave-slave, eller ett 2+1-nod master-slave-quorum. Fördelen med att använda ett kvorum är att det är ett lägre kostnadsalternativ, men nackdelen är att du bara har 2 databärande noder eftersom den andra fungerar som en kvorumnod för att bestämma den bästa failover-kursen. Om din applikation kan läsa från slaven måste du göra lässkalning så att de returnerar samma data från klustervolymen med minimal fördröjning.
Det bästa sättet att vara värd för MySQL på Azure CloudClick To Tweet
När du använder en MySQL master-slave-konfiguration rekommenderar vi att du ställer in semisynkron replikering för att förbättra din dataintegritet med dataredundans. Detta säkerställer att när en commit returneras framgångsrikt, finns data både i mastern och slaven, så i händelse av att ett datacenter går sönder kan din MySQL master failover till en slav utan någon dataförlust. Du kan göra detta med antingen asynkron eller semisynkron replikering, och läs mer om det i vårt MySQL High Availability Explained – Del II-blogginlägg.
Så, hur konfigurerar vi hög tillgänglighet för MySQL på Azure? Vi måste distribuera våra slavinstanser över olika Azure-tillgänglighetszoner (AZ). Så vi vill se till att vi väljer en Azure-region som har minst 3 A-Ö, och placerar varje instans i en annan A-Ö. Vi gör detta eftersom tillgänglighetsgarantierna gäller för A-Ö, så om 1 zon går ner kan din applikationsdatabas fortfarande vara online genom de andra 2 A-Ö. Tillgänglighetszoner är ganska nya för Azure, så om du arbetar i en region som inte erbjuder A-Ö har du möjlighet att använda tillgänglighetsuppsättningar. Dessa är något svagare än AZ, men se till att du distribueras över olika domäner och rack för att skydda dig mot ett potentiellt avbrott. Det finns också möjlighet att distribuera över regioner, men det här är en mer komplicerad installation så vi rekommenderar att du tar kontakt för att diskutera innan du implementerar.
Azure Virtual Networks
Det bästa sättet att skydda din databas från internet är att distribuera den i ett privat undernät för att säkerställa att den inte exponeras. Azure gör detta enkelt att installera genom att använda ett virtuellt nätverk (VNET) som kan konfigureras för dina MySQL-servrar. Med ett Azure VNET för MySQL kan du ställa in säker kommunikation mellan dina servrar, internet och till och med ditt lokala privata molnnätverk. Dessa är vanligtvis konfigurerade för att kommunicera över ett enda nätverk, men om du behöver ansluta mer än en region kan du skapa flera VNET för att kommunicera via Virtual Network Peering.
Dessutom kan du hantera din MySQL-åtkomstkontroll genom regler för nätverkssäkerhetsgrupper (NSG) utan att behöva hantera IP-vitlistor. Detta är inte tillgängligt via Azure Database for MySQL, men både VNET och NSG kan konfigureras genom våra MySQL Bring Your Own Cloud (BYOC)-planer på Azure där du kan vara värd för dina kluster via ditt eget molnkonto.
Azure-instanstyper
En annan viktig aspekt att tänka på är prestandan för dina MySQL-instanser i det offentliga molnet. Azure-molnet erbjuder flera instanstyper som kan användas för ditt MySQL-värd, inklusive Es2 v3, Ds2, v2 och Ls4.
Vi rekommenderar att du börjar med en minnesoptimerad instanstyper eftersom databaser kräver mycket RAM och letar efter den snabbaste möjliga diskhastigheten för bästa prestanda. Es2-serien är vanligtvis en bra utgångspunkt för de flesta applikationer MySQL-arbetsbelastningar. Därifrån kan du göra en del prestandatester för att se om du behöver mer CPU, i vilket fall kan balanserade instanstyper eller CPU-intensiva instanstyper bättre tjäna dina MySQL-behov, till exempel Dv3-instanstyperna. Dina prestandatester kan också visa att du behöver mer I/O (ingång/utgång), du kan flytta till en diskintensiv instanstyp.
Om du planerar att utnyttja Azure som din MySQL-molnleverantör under de kommande 1-3 åren och bibehålla ganska konsekventa distributionskonfigurationer, kan du också överväga reserverade instanser. Dessa är i huvudsak förbetalda instanser som gör att du kan uppnå avsevärda kostnadsbesparingar för ditt MySQL-värd. I genomsnitt kan du spara runt 20 % till 30 % för ett års reserverade instanser och 40 % till 50 % på de 3 år reserverade instanserna.
Azure-disktyper
Den första bestämningen du måste göra när det gäller att välja en Azure-disktyp för dina MySQL-distributioner är om du ska välja en hanterad eller ohanterad disk. De ohanterade diskarna är de äldre diskar som Azure erbjuder där du måste konfigurera lagringskontot, mappa din disk till lagringskontot och övervaka IOPS-användningen och gränserna för det lagringskontot. Vi rekommenderar starkt att du använder hanterade diskar, och om du fortfarande distribuerar med ohanterade diskar bör du överväga att flytta till de hanterade.
MySQL Dev/Test-miljöer:Standarddiskar
Det finns flera hanterade disktyper tillgängliga via Azure, standarddiskarna är standard. Standarddiskar kan stödja upp till 500 IOPS (input/output operations per second) och är bra för utvecklings- och testoperationer eftersom de kan ändras dynamiskt, men bör inte användas för MySQL-produktionsinstallationer.
MySQL-produktionsinstallationer:Premium-diskar
För dina MySQL-produktionsservrar rekommenderar vi starkt att du använder Azure premium-diskar. Det finns ett brett utbud av premiumdiskar du kan välja mellan. För varje premiumdisk kan du välja den bästa storleken och varje storlek kommer med olika Provisioned IOPS så att du kan välja den som bäst passar dina applikationsbehov.
MySQL-produktionsinstallationer:Lokal SSD
Azure Local SSD är ett högpresterande alternativ till premiumdiskar, vanligtvis bäst lämpade för stora kluster. De lokala SSD:erna ger en mycket högre I/O-prestanda och den bästa genomströmningen i Azure. Men de har en nackdel i att de är tillfälliga diskar, inte ett permanent lager, så om du stoppar instansen försvinner data. Vi rekommenderar Ls v2-serien som är mycket snabb, men varning att CPU:n är riktigt svag vilket kan orsaka maskinflaskhalsar.
MySQL-säkerhetskopior på Azure
Det bästa sättet att säkerhetskopiera dina MySQL-data på Azure är genom att använda ögonblicksbilder av hanterade diskar. En ögonblicksbild är en skrivskyddad tidpunktsversion av en disk. Dessa säkerhetskopior kan läsas, kopieras eller raderas, men observera att de inte kan ändras. Det är en bra idé att göra fullständiga säkerhetskopior så att alla dina databaser, användare och inställningar säkerhetskopieras på instansen ifall du någonsin behöver återställa en MySQL-databas. Det är också en bra idé att kryptera dina säkerhetskopierade ögonblicksbilder så att säkerhetskopian endast kan återställas till den maskin där säkerhetskopieringen togs.
Dina MySQL-säkerhetskopior kommer att resultera i ytterligare Azure-datalagringsavgifter, såvida du inte använder en allomfattande MySQL på Azure-lösning som våra dedikerade värdplaner på ScaleGrid. För att kontrollera kostnaderna är det en bra idé att automatisera dina säkerhetskopior genom ett anpassningsbart schema som låter dig konfigurera frekvensen för dina säkerhetskopior, det maximala antalet säkerhetskopior som ska behållas och ditt backupmål. Detta hjälper dig naturligtvis också att säkerställa att din MySQL-data säkerhetskopieras regelbundet i händelse av dataförlust i din produktionsinstallation så att du snabbt kan återställa med en ny säkerhetskopia.
Om du har några frågor om det bästa sättet att vara värd för MySQL på Azure, lämna en kommentar nedan eller kontakta oss på support@scalegrid. io. Du kan också starta en gratis 30-dagars provperiod för att utforska fördelarna med att utnyttja en fullt hanterad MySQL-tjänst för att förbättra prestandan för dina implementeringar.
