Liker du at komme i gang med verdens mest populære open source-database og spekulerer på, hvordan du skal konfigurere din MySQL-hosting? Så mange er standard til Amazon RDS, når MySQL klarer sig usædvanligt godt på Azure Cloud. Selvom Microsoft Azure tilbyder en administreret løsning, Azure Database, har løsningen nogle store begrænsninger, du bør kende til, før du migrerer dine MySQL-implementeringer. I dette indlæg skitserer vi den bedste måde at hoste MySQL på Azure, herunder administrerede løsninger, instanstyper, replikering med høj tilgængelighed, backup og disktyper, der skal bruges til at optimere din cloud-databaseydelse.
MySQL DBaaS vs. Self-Managed MySQL
Den første ting, du skal overveje, når du vejer mellem selvstyring og en MySQL Database-as-a-Service (DBaaS)-løsning, er, hvilke interne ressourcer du har til rådighed. Hvis du læser dette, kender du sandsynligvis allerede omfanget af operationelle opgaver forbundet med at vedligeholde en produktionsimplementering, men for en hurtig opsummering er der klargøring, deprovisioning, master-slave-konfigurationer, sikkerhedskopier, skalering, opgraderinger, logrotationer, OS-patching , og overvågning for at nævne nogle få.
En intern MySQL-ekspert eller et team af DBA'er afhængigt af din ansøgningsstørrelse kan helt sikkert håndtere disse med din organisation for dig, men spørgsmålet bliver, hvor du vil have dit teams indsats fokuseret . Mange beslutter at flytte til en MySQL DBaaS for at automatisere disse tidskrævende opgaver, så de kan fokusere mere på udvikling og optimering af deres applikationsdatabaser. Et godt eksempel ville være langsom forespørgselsanalyse. Selvom næsten alle DBaaS tilbyder et MySQL Slow Query Analyzer-værktøj til at hjælpe med at identificere problemforespørgsler, kræver denne opgave stadig menneskelige færdigheder og intuition for at bestemme, hvordan man optimerer disse forespørgsler, der påvirker deres applikationsydelse.
Uanset om du er en nystartet virksomhed eller en Fortune 500-virksomhed, vil du opdage, at mange organisationer vælger at udnytte en DBaaS til at optimere deres DBA's tid, mens de samme virksomhedstyper og -størrelser også vælge at holde fast i intern selvledelse. For mange virksomhedsvirksomheder kommer beslutningen i høj grad ned til tilpasning og kontrol. Dette er grunden til, at vi advarer mod at misligholde Azure Database, eller det er AWS-konkurrenten, Amazon RDS, da de ikke tillader dig at beholde MySQL-superbrugeradgang eller endda SSH-adgang til dine maskiner. Derudover er muligheden for at tilpasse din installationsopsætning meget begrænset, såsom de instanstyper, RAM, diskstørrelse eller IOPS, du kan bruge. Du vil lære mere om de bedste instanstyper og diske, der skal bruges nedenfor, og du kan tjekke denne MySQL-udbydersammenligning for at se fordelene og begrænsningerne ved de top fire administrerede MySQL-løsninger, ScaleGrid, Compose, Azure Database og Amazon RDS.
Høj tilgængelighedsimplementering
Hvis du implementerer i produktion, bør du altid konfigurere MySQL som en master-slave-implementering. Standalone implementeringer er en enkelt node uden nogen form for replikering og bør egentlig kun bruges til udviklings- eller testmiljøer. Med master-slave-implementeringer er du i stand til at konfigurere høj tilgængelighed, så hvis en af dine noder går ned, kan du failover til en slave uden nedetid. Dette er typisk sat op enten som en 3-node master-slave-slave eller et 2+1 node master-slave-quorum. Fordelen ved at bruge et kvorum er, at det er et billigere alternativ, men ulempen er, at du kun har 2 databærende noder, da den anden fungerer som en kvorum node for at bestemme det bedste failover-kursus. Hvis din applikation er i stand til at læse fra slaven, skal du lave læseskalering, så de returnerer de samme data fra klyngevolumen med minimal forsinkelse.
Den bedste måde at hoste MySQL på Azure CloudKlik for at tweete
Når du bruger en MySQL master-slave-konfiguration, anbefaler vi at opsætte semisynkron replikering for at forbedre din dataintegritet med dataredundans. Dette sikrer, at når en commit vender tilbage med succes, eksisterer dataene både i masteren og slaven, så i tilfælde af at et datacenter går ned, kan din MySQL master failover til en slave uden tab af data. Du kan gøre dette med enten asynkron eller semisynkron replikering, og lær mere om det i vores MySQL High Availability Explained – Part II blogindlæg.
Så hvordan konfigurerer vi høj tilgængelighed for MySQL på Azure? Vi er nødt til at distribuere vores slave-instanser på tværs af forskellige Azure-tilgængelighedszoner (AZ). Så vi vil sikre os, at vi vælger en Azure-region, der har mindst 3 AZ'er, og sætter hver instans i en anden AZ. Vi gør dette, fordi tilgængelighedsgarantierne er på tværs af AZ'er, så hvis 1 zone går ned, er din applikationsdatabase stadig i stand til at forblive online gennem de andre 2 AZ'er. Tilgængelighedszoner er ret nye for Azure, så hvis du arbejder i en region, der ikke tilbyder AZ'er, har du mulighed for at bruge tilgængelighedssæt. Disse er lidt svagere end AZ'er, men sørg for, at du er installeret på tværs af forskellige domæner og racks for at beskytte dig mod et potentielt udfald. Der er også mulighed for at implementere på tværs af regioner, men dette er en mere kompliceret opsætning, så vi anbefaler, at du kontakter dig for at diskutere før implementering.
Azure Virtual Networks
Den bedste måde at beskytte din database mod internettet på er ved at implementere den i et privat undernet for at sikre, at den ikke bliver eksponeret. Azure gør dette nemt at konfigurere ved at bruge et virtuelt netværk (VNET), som kan konfigureres til dine MySQL-servere. Med et Azure VNET til MySQL er du i stand til at konfigurere sikker kommunikation mellem dine servere, internettet og endda dit private cloud-netværk på stedet. Disse er typisk konfigureret til at kommunikere på tværs af et enkelt netværk, men hvis du har brug for at forbinde mere end én region, kan du oprette flere VNET'er til at kommunikere gennem Virtual Network Peering.
Derudover kan du administrere din MySQL-adgangskontrol gennem regler for netværkssikkerhedsgrupper (NSG) uden at skulle håndtere IP-hvidlister. Dette er ikke tilgængeligt gennem Azure Database til MySQL, men både VNET og NSG kan konfigureres gennem vores MySQL Bring Your Own Cloud (BYOC) planer på Azure, hvor du er i stand til at hoste dine klynger gennem din egen cloud-konto.
Azure-forekomsttyper
Et andet vigtigt aspekt at overveje er ydeevnen af dine MySQL-instanser i den offentlige sky. Azure cloud tilbyder flere instanstyper, der kan bruges til din MySQL-hosting, inklusive Es2 v3, Ds2, v2 og Ls4.
Vi anbefaler at starte med en hukommelsesoptimeret instanstyper, da databaser kræver meget RAM og leder efter den hurtigst mulige diskhastighed for den bedste ydeevne. Es2-serien er typisk et godt udgangspunkt for de fleste applikationers MySQL-arbejdsbelastninger. Derfra kan du udføre nogle ydelsestest for at se, om du har brug for mere CPU, i hvilket tilfælde balancerede instanstyper eller CPU-intensive instanstyper måske bedre opfylder dine MySQL-behov, såsom Dv3-instanstyperne. Dine ydeevnetest kan også vise, at du har brug for mere I/O (input/output), du kan flytte til en disk-intensiv instanstype.
Hvis du planlægger at udnytte Azure som din MySQL-cloududbyder i de næste 1-3 år og vedligeholde nogenlunde konsistente implementeringskonfigurationer, kan du også overveje reserverede forekomster. Disse er i det væsentlige forudbetalte tilfælde, som giver dig mulighed for at opnå betydelige omkostningsbesparelser for din MySQL-hosting. I gennemsnit kan du spare omkring 20 % til 30 % for et års reserverede tilfælde og 40 % til 50 % på de 3 år reserverede tilfælde.
Azure-disktyper
Den første beslutning, du skal tage, når det kommer til at vælge en Azure-disktype til dine MySQL-implementeringer, er, om du skal vælge en administreret vs. ikke-administreret disk. De ikke-administrerede diske er de ældre diske, Azure tilbyder, hvor du skal konfigurere lagerkontoen, tilknytte din disk til lagerkontoen og overvåge IOPS-brugen og grænserne for den lagerkonto. Vi anbefaler stærkt at bruge administrerede diske, og hvis du stadig implementerer med ikke-administrerede diske, bør du overveje at flytte til de administrerede.
MySQL Dev/Test-miljøer:Standarddiske
Der er flere administrerede disktyper tilgængelige via Azure, standarddiskene er standard. Standarddiske kan understøtte op til 500 IOPS (input/output-operationer pr. sekund) og er gode til udviklings- og testoperationer, da de kan ændres dynamisk, men bør ikke bruges til MySQL-produktionsinstallationer.
MySQL-produktionsinstallationer:Premium-diske
For dine MySQL-produktionsservere anbefaler vi på det kraftigste at bruge Azure premium-diske. Der er et bredt udvalg af premium-diske, du kan vælge imellem. For hver premium-disk kan du vælge den bedste størrelse, og hver størrelse leveres med forskellige Provisioned IOPS, så du kan vælge den, der bedst passer til dine applikationsbehov.
MySQL-produktionsinstallationer:Lokal SSD
Azure Local SSD'er er et højtydende alternativ til premium-diske, typisk bedst egnet til store klynger. De lokale SSD'er giver en meget højere I/O-ydeevne og den bedste gennemstrømning i Azure. Men de har en ulempe ved, at de er flygtige diske, ikke et permanent lager, så hvis du stopper forekomsten, forsvinder dataene. Vi anbefaler Ls v2-serien, som er meget hurtig, men vær opmærksom på, at CPU'en er virkelig svag, hvilket kan forårsage maskinflaskehalse.
MySQL-sikkerhedskopier på Azure
Den bedste måde at sikkerhedskopiere dine MySQL-data på Azure er ved at bruge administrerede disk-snapshots. Et snapshot er en skrivebeskyttet tidspunkt-version af en disk. Disse sikkerhedskopier kan læses, kopieres eller slettes, men bemærk, at de ikke kan ændres. Det er en god idé at lave fuld sikkerhedskopiering, så alle dine databaser, brugere og indstillinger sikkerhedskopieres på instansen, hvis du nogensinde får brug for at gendanne en MySQL-database. Det er også en god idé at kryptere dine backup-øjebliksbilleder, så sikkerhedskopien kun kan gendannes på den maskine, som backuppen blev taget i.
Dine MySQL-sikkerhedskopier vil resultere i yderligere Azure-datalagringsafgifter, medmindre du udnytter en altomfattende MySQL på Azure-løsning som vores dedikerede hostingplaner hos ScaleGrid. For at kontrollere omkostningerne er det en god idé at automatisere dine sikkerhedskopier gennem en tilpasselig tidsplan, der giver dig mulighed for at konfigurere frekvensen af dine sikkerhedskopier, det maksimale antal sikkerhedskopier, der skal beholdes, og dit backupmål. Dette hjælper dig selvfølgelig også med at sikre, at dine MySQL-data sikkerhedskopieres regelmæssigt i tilfælde af datatab i din produktionsimplementering, så du hurtigt kan gendanne med en nylig sikkerhedskopi.
Hvis du har spørgsmål om den bedste måde at hoste MySQL på Azure, så giv os en kommentar nedenfor eller kontakt os på support@scalegrid. io. Du kan også starte en gratis 30-dages prøveperiode for at udforske fordelene ved at udnytte en fuldt administreret MySQL-tjeneste til at forbedre ydeevnen af dine implementeringer.
