Som den mest populære open source-database er MySQL blevet implementeret mange steder, lige fra små startups til meget store organisationer. Brugstilfælde varierer fra simple webstedsapplikationer til missionskritiske miljøer med krav til 99,999 % oppetid. MySQL får bare arbejdet gjort og er let at arbejde med.
Selvom MySQL er relativt let at administrere, kører det ikke af sig selv. Der er en vis administrationsomkostninger - software skal patches i ny og næ, databasen skal overvåges for fejl eller uregelmæssigheder i ydeevne eller sikkerhed, fejl skal håndteres og genoprettes fra, backups skal administreres.. og listen fortsætter.. Så det burde ikke være overraskende, at de største cloud-leverandører tilbyder offentlige DBaaS-tjenester baseret på MySQL.
Tre cloud-udbydere, der tilbyder MySQL som en tjeneste, inkluderer:
- Amazon Web Service med RDS til MySQL
- Google Compute Engine med CloudSQL til MySQL
- Microsoft Azure, Microsoft Azure MySQL
I denne blog vil vi sammenligne løsningerne fra disse cloud-udbydere.
MySQL-version og patches
Den seneste version af MySQL, der er tilgængelig i Amazon Web Services (AWS), er MySQL 8.0.20, som er ret tæt på den seneste version af den officielle Oracle MySQL ( 8.0.21 på tidspunktet for skrivning). Udover den seneste version tilbyder AWS RDS også den ældre version af MySQL (major version 5.5, 5.6 og 5.7), så du kan implementere den nøjagtige version, der er kompatibel med din applikation.
I Google Cloud Platform (GCP) er MySQL-versionen, der understøttes i CloudSQL til MySQL, stadig MySQL 5.6 &5.7, den seneste mindre version af udgivelse 5.6 er 5.6.42, mens den for version 5.7 er den seneste mindre version er 5.7.25.
Azure-databasen til MySQL understøtter version 5.6, 5.7, 8.0, desværre leverer de ikke den mindre version (eller fejlrettelsesversionen af databasen, som Azure kalder den), når de implementeres fra konsollen. For at bestemme versionen af din MySQL-serverinstans kan man bruge SELECT VERSION(); kommando ved MySQL-prompten.
Kendte problemer og begrænsninger
Der er nogle kendte problemer og begrænsninger, der eksisterer på databasen som en tjeneste, mens det ikke sker i MySQL on premise eller VM'er. På RDS er nogle af begrænsningerne:
- MySQL nøglering plugin er ikke understøttet.
- Maksimal lagergrænsestørrelse for en tabel er 16 TB, når du bruger InnoDB-lagermotoren.
- Der er nogle parametre, der kræver særlige overvejelser ved brug af RDS, f.eks.:long_query_time, small_case_table_name.
Der er nogle begrænsninger og problemer kendt i CloudSQL til MySQL, opdelt i forskellige kategorier, for eksempel:problemer med dataholdbarhed og tilgængelighed, problemer med forekomstforbindelser, administrative problemer og problemer med eksport og import af data. Hver kategori har specifikke problemer og begrænsninger, nogle af dem er:
- Længerevarende operationer kan ikke annulleres eller stoppes.
- Forekomstnavne kan ikke bruges umiddelbart efter, at vi har slettet forekomsten.
- DEFINER-sætningen vil få importen til at mislykkes.
Azure-databasen til MySQL har nogle begrænsninger og kendte problemer relateret til opgradering, privilegier og lagermotor. Nogle af detaljerne er:
- Større databaseopgradering er i øjeblikket ikke understøttet. Du skal lave et dump og gendanne til en ny server for en større opgradering.
- Azure-database til MySQL understøtter i øjeblikket InnoDB- og Memory-lagringsmotorer.
- Systemdatabase i azure-database til MySQL er indstillet til skrivebeskyttet. Du kan ikke ændre noget i mysql-systemdatabasen.
Du skal tjekke begrænsningerne og kendte problemer for MySQL på hver cloud-udbyder og sammenligne med dine krav for at forstå, om det påvirker applikationen.
Sikkerhedskopiering og gendannelse
Amazon RDS til MySQL kører den automatiske sikkerhedskopiering i henhold til tidsplanen, den tager et volumen-øjebliksbillede af databaseforekomsten. Standarden for sikkerhedskopieringsperioden er 7 dage. Ikke nok med det, RDS uploader dine transaktionslogfiler for databaseforekomster til S3 hvert 5. minut for at bevare tidspunktet for gendannelse.
Du kan gendanne en sikkerhedskopi til et bestemt tidspunkt ved at oprette en ny instans inden for sikkerhedskopieringsperioden. Du kan vælge den seneste gendannelsestid for at gendanne til den seneste mulige tid, eller du kan vælge en brugerdefineret for at definere et bestemt tidspunkt for gendannelse af dataene.
Sikkerhedskopiering, der finder sted i CloudSQL til MySQL, er trinvis. Den indeholder kun ændringer af data efter tidligere sikkerhedskopiering. Den ældste backup svarer til din nuværende databasestørrelse. Når den ældste sikkerhedskopi fjernes, øges størrelsen af den følgende ældste sikkerhedskopi, så den fulde sikkerhedskopi stadig eksisterer.
Automatisk sikkerhedskopiering finder sted hver dag, og den bevares som standard i 7 dage. CloudSQL gemmer backup-data i 2 regioner for redundans. Én region kan være i det samme, som forekomsten kører, og den anden er i en anden region.
Gendannelse af tidspunkt i CloudSQL vil oprette en ny instans, instansindstillingen vil arve med kilden til instansen. Før du foretager gendannelsen af tidspunktet, skal du sikre dig, at du allerede har aktiveret binær logning. Når du udfører punkt-in-tidsgendannelse, skal du blot udfylde det binære lognavn og gendannelsesposition.
Azure-database til MySQL tager backup af datafiler og transaktionslogfiler. Tidsplanen for selve backup er en kombination af fuld og differentiel backup for servere med op til 4TB lagerstørrelse, mens snapshot backup sker for op til 16TB max lagerserver.
Den fulde sikkerhedskopiering kører en gang om ugen, mens de differentielle sikkerhedskopier finder sted to gange om dagen. Standardopbevaringsperioden for sikkerhedskopien er 7 dage, men du kan altid konfigurere opbevaringen op til 35 dage.
Der er to typer gendannelse i Azure-databasen til MySQL, som er:
- Point-in-time gendannelse, tilgængelig som en redundans backup mulighed, eller du kan oprette en ny server i samme region som din oprindelige server ved at bruge den fulde backup og transaktionslog til at gendanne dataene.
- Geo-gendannelse, tilgængelig, hvis du konfigurerer en geo-redundant i lagerindstillingen. Det giver dig mulighed for at gendanne din sikkerhedskopi til forskellige områder.
Bemærk venligst, at hverken AWS, Google eller Azure tillader dig at downloade dine sikkerhedskopier.
Databaseovervågning
RDS giver overvågningsintegration med CloudWatch, du kan se nogle af metrikker såsom CPU-udnyttelse, DB-forbindelser, skrive IOPS og læse IOPS, skrivegennemløb og læsegennemløb, skrive- og læseforsinkelse. Du kan oprette en alarm for at udløse advarslen fra CloudWatch, baseret på nogle metrics-kategorier og blot definere tærsklen.
I lighed med RDS, integrerer GCP CloudSQL også med stackdriver, du kan se målinger som:CPU-udnyttelse, hukommelsesudnyttelse, aktive forbindelser, transaktioner/sek., ind-/udgående bytes, skrive- og læseoperationer, replikeringsforsinkelse .
Azure-database til MySQL giver nogle metrics, f.eks. Aktive forbindelser, CPU-procent, mislykket forbindelse, IO-procent, hukommelsesprocent, replikeringsforsinkelse, lagerprocent, brugt lagerplads. Du kan også oprette advarsler i Azure-databaser til MySQL, vælge metrics og definere reglerne.
Konklusion
Baseret på 4 nøgleområder; MySQL-version &patches, kendte problemer og begrænsninger, sikkerhedskopiering og gendannelse, databaseovervågning, efter min mening er Amazon RDS til MySQL stadig den bedste database som en tjeneste til MySQL. Det giver detaljerede versioner og patches, meget begrænsede problemer og begrænsninger sammenlignet med andre. Det er en bekvem måde at køre MySQL på, med det forbehold, at prisen for tjenesten er steget de seneste år.