Als de meest populaire open source database, is MySQL op veel plaatsen geïmplementeerd, van kleine startups tot zeer grote organisaties. Use cases variëren van eenvoudige website-applicaties tot bedrijfskritische omgevingen met 99,999% uptime-vereisten. MySQL klaart gewoon de klus en is gemakkelijk om mee te werken.
Hoewel MySQL relatief eenvoudig te beheren is, draait het niet op zichzelf. Er is een zekere beheeroverhead - software moet zo nu en dan worden gepatcht, de database moet worden gecontroleerd op fouten of afwijkingen in de prestaties of beveiliging, fouten moeten worden afgehandeld en hersteld, back-ups moeten worden beheerd.. en de lijst gaat maar door.. Het zou dus geen verrassing moeten zijn dat de grootste cloudleveranciers openbare DBaaS-diensten aanbieden op basis van MySQL.
Drie cloudproviders die MySQL als een service aanbieden zijn:
- Amazon-webservice met RDS voor MySQL
- Google Compute Engine met CloudSQL voor MySQL
- Microsoft Azure, Microsoft Azure MySQL
In deze blog vergelijken we de oplossingen van deze cloudproviders.
MySQL-versie en patches
De nieuwste versie van MySQL die beschikbaar is in Amazon Web Services (AWS) is MySQL 8.0.20, wat vrij dicht in de buurt komt van de nieuwste versie van de officiële Oracle MySQL ( 8.0.21 ten tijde van schrijven). Naast de nieuwste versie biedt AWS RDS ook de oudere versie van MySQL (hoofdversie 5.5, 5.6 en 5.7), zodat u de exacte versie kunt implementeren die compatibel is met uw applicatie.
In Google Cloud Platform (GCP) is de MySQL-versie die wordt ondersteund in CloudSQL voor MySQL nog steeds MySQL 5.6 &5.7, de nieuwste secundaire versie van release 5.6 is 5.6.42, terwijl voor versie 5.7 de nieuwste kleine versie is 5.7.25.
Azure-database voor MySQL ondersteunt versies 5.6, 5.7, 8.0, helaas bieden ze niet de secundaire versie (of de bugfix-versie van de database, zoals Azure het noemt) bij implementatie vanaf de console. Om de versie van uw MySQL-serverinstantie te bepalen, kunt u de SELECT VERSION(); commando achter de MySQL-prompt.
Bekende problemen en beperkingen
Er zijn enkele bekende problemen en beperkingen die bestaan op de database als een service, terwijl dit niet gebeurt in MySQL op locatie of VM's. Op RDS zijn enkele beperkingen:
- De plug-in voor MySQL-sleutelhangers wordt niet ondersteund.
- Maximale opslaglimiet voor een tabel is 16 TB bij gebruik van de InnoDB-opslagengine.
- Er zijn enkele parameters die speciale overwegingen vereisen bij het gebruik van RDS, bijvoorbeeld:long_query_time, lower_case_table_name.
Er zijn enkele beperkingen en problemen bekend in CloudSQL voor MySQL, onderverdeeld in verschillende categorieën, bijvoorbeeld:problemen met de duurzaamheid en beschikbaarheid van gegevens, verbindingsproblemen met instanties, administratieve problemen en problemen met het exporteren en importeren van gegevens. Elke categorie heeft specifieke problemen en beperkingen, sommige zijn:
- Langlopende bewerkingen kunnen niet worden geannuleerd of gestopt.
- Instantienamen kunnen niet onmiddellijk worden gebruikt nadat we de instantie hebben verwijderd.
- De DEFINER-clausule zorgt ervoor dat het importeren mislukt.
Azure-database voor MySQL heeft enkele beperkingen en bekende problemen met betrekking tot upgrades, bevoegdheden en opslagengine. Enkele details zijn:
- Grote database-upgrade wordt momenteel niet ondersteund. Je moet een dump doen en terugzetten naar een nieuwe server voor een grote upgrade.
- Azure-database voor MySQL ondersteunt momenteel InnoDB- en geheugenopslagengines.
- Systeemdatabase in azure-database voor MySQL is ingesteld op alleen-lezen. U kunt niets wijzigen in de mysql-systeemdatabase.
U moet de beperkingen en bekende problemen voor MySQL bij elke cloudprovider controleren en deze vergelijken met uw vereisten om te begrijpen of dit van invloed is op de toepassing.
Back-up maken en terugzetten
Amazon RDS voor MySQL voert de automatische back-up uit volgens het schema, er wordt een volume-snapshot van de database-instantie gemaakt. De standaard bewaartermijn voor back-ups is 7 dagen. Niet alleen dat, RDS uploadt uw transactielogboeken voor database-instances elke 5 minuten naar S3 om het herstel op het juiste moment te behouden.
Je kunt een back-up terugzetten naar een specifiek tijdstip door een nieuwe instantie te maken binnen de bewaarperiode voor back-ups. U kunt de laatst herstelbare tijd kiezen om te herstellen naar de laatst mogelijke tijd, of u kunt een gewoonte kiezen om een specifieke tijd te definiëren voor het herstellen van de gegevens.
Back-up die plaatsvindt in CloudSQL voor MySQL is incrementeel. Het bevat alleen de wijzigingen van gegevens na eerdere back-up. De oudste back-up is vergelijkbaar met uw huidige databasegrootte. Wanneer de oudste back-up wordt verwijderd, neemt de grootte van de volgende oudste back-up toe, zodat de volledige back-up nog steeds bestaat.
Geautomatiseerde back-up vindt elke dag plaats en wordt standaard 7 dagen bewaard. CloudSQL slaat back-upgegevens op in 2 regio's voor redundantie. De ene regio kan zich in dezelfde regio bevinden als de instantie die wordt uitgevoerd, en de andere bevindt zich in een andere regio.
Op een bepaald moment herstel in CloudSQL zal een nieuwe instantie maken, de instantie-instelling erft met de bron van de instantie. Voordat u het punt in de tijd herstelt, moet u ervoor zorgen dat u binaire logboekregistratie al hebt ingeschakeld. Wanneer u herstel op een bepaald tijdstip uitvoert, hoeft u alleen de binaire lognaam en herstelpositie in te vullen.
Azure-database voor MySQL maakt back-up van gegevensbestanden en transactielogboeken. Het back-upschema zelf is een combinatie van volledige en differentiële back-up voor servers met een opslagcapaciteit tot 4 TB, terwijl snapshot-back-up plaatsvindt voor een opslagserver tot maximaal 16 TB.
De volledige back-up wordt eenmaal per week uitgevoerd, terwijl de differentiële back-ups twee keer per dag plaatsvinden. De standaard retentieperiode van de back-up is 7 dagen, maar u kunt de retentie altijd configureren tot 35 dagen.
Er zijn twee soorten herstel in Azure-database voor MySQL, namelijk:
- Terugzetten op een bepaald tijdstip, beschikbaar als redundante back-upoptie, of u kunt een nieuwe server maken in dezelfde regio als uw oorspronkelijke server, waarbij u de volledige back-up en het transactielogboek gebruikt om de gegevens te herstellen.
- Geo-herstel, beschikbaar als u een geo-redundant configureert in de opslagoptie. Hiermee kunt u uw back-up terugzetten naar verschillende regio's.
Houd er rekening mee dat noch AWS, Google of Azure u toestaan uw back-ups te downloaden.
Databasecontrole
RDS biedt monitoring-integratie met CloudWatch, u kunt enkele statistieken zien, zoals CPU-gebruik, DB-verbindingen, IOPS schrijven en IOPS lezen, schrijfdoorvoer en leesdoorvoer, schrijf- en leeslatentie. U kunt een alarm maken om de waarschuwing van CloudWatch te activeren, op basis van een bepaalde metrische categorie en gewoon de drempel definiëren.
Vergelijkbaar met RDS, integreert GCP CloudSQL ook met stackdriver, u kunt statistieken zien zoals:CPU-gebruik, geheugengebruik, actieve verbindingen, transacties/sec, inkomende/uitgaande bytes, schrijf- en leesbewerkingen, replicatievertraging .
Azure-database voor MySQL biedt enkele statistieken, bijv.; Actieve verbindingen, CPU-percentage, mislukte verbinding, IO-percentage, geheugenpercentage, replicatievertraging, opslagpercentage, gebruikte opslag. U kunt ook waarschuwingen maken in Azure-databases voor MySQL, de metrische gegevens kiezen en de regels definiëren.
Conclusie
Gebaseerd op 4 belangrijke gebieden; MySQL-versie en patches, bekende problemen en beperkingen, back-up en herstel, databasebewaking, naar mijn mening is Amazon RDS voor MySQL nog steeds de beste database als een service voor MySQL. Het biedt gedetailleerde versies en patches, zeer beperkte problemen en beperkingen in vergelijking met andere. Het is een handige manier om MySQL te gebruiken, met het voorbehoud dat de prijs voor de service de afgelopen jaren is gestegen.