Som den mest populära databasen med öppen källkod har MySQL implementerats på många ställen, från små startups till mycket stora organisationer. Användningsfallen varierar från enkla webbplatsapplikationer till verksamhetskritiska miljöer med krav på drifttid på 99,999 %. MySQL får bara jobbet gjort och är lätt att arbeta med.
Även om MySQL är relativt lätt att hantera, körs det inte av sig självt. Det finns en viss förvaltningsoverhead - programvara måste korrigeras då och då, databasen måste övervakas för fel eller anomalier i prestanda eller säkerhet, fel måste hanteras och återställas från, säkerhetskopior måste hanteras.. och listan fortsätter... Så det borde inte vara någon överraskning att de största molnleverantörerna erbjuder offentliga DBaaS-tjänster baserade på MySQL.
Tre molnleverantörer som erbjuder MySQL som en tjänst inkluderar:
- Amazon Web Service med RDS för MySQL
- Google Compute Engine med CloudSQL för MySQL
- Microsoft Azure, Microsoft Azure MySQL
I den här bloggen kommer vi att jämföra lösningarna från dessa molnleverantörer.
MySQL-version och patchar
Den senaste versionen av MySQL som är tillgänglig i Amazon Web Services (AWS) är MySQL 8.0.20, vilket är ganska nära den senaste versionen av den officiella Oracle MySQL ( 8.0.21 vid tidpunkten för skrift). Förutom den senaste versionen tillhandahåller AWS RDS även den äldre versionen av MySQL (huvudversion 5.5, 5.6 och 5.7), så att du kan distribuera den exakta versionen som är kompatibel med din applikation.
I Google Cloud Platform (GCP) är MySQL-versionen som stöds i CloudSQL för MySQL fortfarande MySQL 5.6 &5.7, den senaste mindre versionen av release 5.6 är 5.6.42 medan för version 5.7, den senaste mindre version är 5.7.25.
Azure-databasen för MySQL stöder version 5.6, 5.7, 8.0, tyvärr tillhandahåller de inte den mindre versionen (eller buggfixversionen av databasen, som Azure kallar den) när de distribueras från konsolen. För att bestämma versionen av din MySQL-serverinstans kan man använda SELECT VERSION(); kommandot vid MySQL-prompten.
Kända problem och begränsningar
Det finns några kända problem och begränsningar som finns på databasen som en tjänst medan det inte händer i MySQL on premise eller virtuella datorer. På RDS är några av begränsningarna:
- MySQL-nyckelringsplugin stöds inte.
- Maximal lagringsgräns för en tabell är 16 TB när du använder InnoDB-lagringsmotorn.
- Det finns några parametrar som kräver speciella överväganden när du använder RDS, t.ex.:long_query_time, small_case_table_name.
Det finns några begränsningar och problem som är kända i CloudSQL för MySQL, uppdelade i olika kategorier, till exempel:datahållbarhet och tillgänglighetsproblem, anslutningsproblem, administrativa problem och problem med export och import av data. Varje kategori har specifika problem och begränsningar, några av dem är:
- Långa pågående operationer kan inte avbrytas eller stoppas.
- Förekomstnamn kan inte användas direkt efter att vi tagit bort instansen.
- DEFINER-satsen gör att importen misslyckas.
Azure-databasen för MySQL har vissa begränsningar och kända problem relaterade till uppgradering, privilegier och lagringsmotor. Några av detaljerna är:
- Större databasuppgradering stöds för närvarande inte. Du måste göra en dumpning och återställa till en ny server för en större uppgradering.
- Azure-databas för MySQL stöder för närvarande InnoDB- och minneslagringsmotorer.
- Systemdatabasen i azure-databasen för MySQL är inställd på skrivskyddad. Du kan inte ändra något i mysql-systemdatabasen.
Du måste kontrollera begränsningarna och kända problem för MySQL på varje molnleverantör och jämföra med dina krav för att förstå om det påverkar applikationen.
Säkerhetskopiera och återställa
Amazon RDS för MySQL kör den automatiska säkerhetskopieringen enligt schemat, den tar en volymögonblicksbild av databasinstansen. Standard för lagringsperioden för backup är 7 dagar. Inte bara det, RDS laddar upp dina transaktionsloggar för databasinstanser till S3 var 5:e minut för att behålla tidpunkten för återställning.
Du kan återställa en säkerhetskopia till en viss tidpunkt genom att skapa en ny instans inom säkerhetskopieringsperioden. Du kan välja den senaste återställningstiden för att återställa till den senaste möjliga tiden, eller så kan du välja en anpassad för att definiera en specifik tid för att återställa data.
Säkerhetskopiering som sker i CloudSQL för MySQL är inkrementell. Den innehåller endast ändringar av data efter tidigare säkerhetskopiering. Den äldsta säkerhetskopian liknar din nuvarande databasstorlek. När den äldsta säkerhetskopian tas bort ökar storleken på följande äldsta säkerhetskopia, så att den fullständiga säkerhetskopian fortfarande finns kvar.
Automatisk säkerhetskopiering sker varje dag och den sparas i 7 dagar som standard. CloudSQL lagrar säkerhetskopieringsdata i 2 regioner för redundans. En region kan vara i samma som instansen körs, och den andra är i en annan region.
Återställning av tidpunkt i CloudSQL kommer att skapa en ny instans, instansinställningen ärver med källan till instansen. Innan du återställer tidpunkten, se till att du redan har aktiverat binär loggning. När du utför tidpunktsåterställning behöver du bara fylla i det binära loggnamnet och återställningspositionen.
Azure-databasen för MySQL tar säkerhetskopiering av datafiler och transaktionsloggar. Schemat för säkerhetskopiering i sig är en kombination av fullständig och differentiell säkerhetskopiering för servrar med upp till 4 TB lagringsstorlek, medan ögonblicksbildssäkerhetskopiering sker för upp till 16 TB max lagringsserver.
Den fullständiga säkerhetskopieringen körs en gång i veckan, medan de olika säkerhetskopieringarna sker två gånger om dagen. Standardlagringsperioden för säkerhetskopian är 7 dagar, men du kan alltid konfigurera lagringen upp till 35 dagar.
Det finns två typer av återställning i Azure-databasen för MySQL, vilket är:
- Återställning vid tidpunkt, tillgänglig som ett alternativ för redundanssäkerhetskopiering, eller så kan du skapa en ny server i samma region som din ursprungliga server genom att använda den fullständiga säkerhetskopieringen och transaktionsloggen för att återställa data.
- Geo-restore, tillgängligt om du konfigurerar en geo-redundant i lagringsalternativet. Det låter dig återställa din säkerhetskopia till olika regioner.
Observera att varken AWS, Google eller Azure tillåter dig att ladda ner dina säkerhetskopior.
Databasövervakning
RDS tillhandahåller övervakningsintegration med CloudWatch, du kan se några mätvärden som CPU-användning, DB-anslutningar, skriv IOPS och läs IOPS, skrivkapacitet och läskapacitet, skriv- och läsfördröjning. Du kan skapa ett larm för att utlösa varningen från CloudWatch, baserat på vissa mätvärdeskategorier och bara definiera tröskeln.
I likhet med RDS, integreras GCP CloudSQL även med stackdriver, du kan se mätvärden som:CPU-användning, minnesutnyttjande, aktiva anslutningar, transaktioner/sek, ingångs-/utgående byte, skriv- och läsoperationer, replikeringsfördröjning .
Azure-databas för MySQL tillhandahåller vissa mätvärden, t.ex. Aktiva anslutningar, CPU-procent, misslyckad anslutning, IO-procent, minnesprocent, replikeringsfördröjning, lagringsprocent, lagringsutrymme som används. Du kan också skapa varningar i Azure-databaser för MySQL, välja mätvärden och definiera reglerna.
Slutsats
Baserat på 4 nyckelområden; MySQL-version &patchar, kända problem och begränsningar, säkerhetskopiering och återställning, databasövervakning, enligt min mening är Amazon RDS för MySQL fortfarande den bästa databasen som tjänst för MySQL. Det ger detaljerade versioner och patchar, mycket begränsade problem och begränsningar jämfört med andra. Det är ett bekvämt sätt att köra MySQL, med förbehållet att priset för tjänsten har ökat de senaste åren.