Wilt u aan de slag met 's werelds populairste open-sourcedatabase en vraagt u zich af hoe u uw MySQL-hosting moet instellen? Zoveel standaard ingesteld op Amazon RDS, terwijl MySQL uitzonderlijk goed presteert op Azure Cloud. Hoewel Microsoft Azure een beheerde oplossing biedt, Azure Database, heeft de oplossing enkele belangrijke beperkingen die u moet kennen voordat u uw MySQL-implementaties migreert. In dit bericht schetsen we de beste manier om MySQL op Azure te hosten, inclusief beheerde oplossingen, instantietypen, replicatie met hoge beschikbaarheid, back-up en schijftypen die u kunt gebruiken om de prestaties van uw clouddatabase te optimaliseren.
MySQL DBaaS versus zelfbeheerde MySQL
Het eerste waar u rekening mee moet houden bij het afwegen tussen zelfbeheer en een MySQL Database-as-a-Service (DBaaS)-oplossing, is welke interne bronnen u beschikbaar heeft. Als u dit leest, kent u waarschijnlijk al de omvang van de operationele taken die gepaard gaan met het onderhouden van een productie-implementatie, maar voor een snelle samenvatting zijn er provisioning, deprovisioning, master-slave-configuraties, back-ups, schaling, upgrades, logrotaties, OS-patching , en monitoring om er maar een paar te noemen.
Een interne MySQL-expert, of een team van DBA's, afhankelijk van uw applicatiegrootte, kan dit zeker met uw organisatie voor u afhandelen, maar de vraag is waar u de inspanningen van uw team wilt concentreren . Velen besluiten over te stappen op een MySQL DBaaS om deze tijdrovende taken te automatiseren, zodat ze zich meer kunnen concentreren op de ontwikkeling en optimalisatie van hun applicatiedatabases. Een goed voorbeeld is een trage analyse van zoekopdrachten. Hoewel bijna elke DBaaS een MySQL Slow Query Analyzer-tool biedt om probleemquery's te identificeren, vereist deze taak nog steeds menselijke vaardigheid en intuïtie om te bepalen hoe die queries kunnen worden geoptimaliseerd die van invloed zijn op hun applicatieprestaties.
Of u nu een startend bedrijf bent of een Fortune 500-bedrijf, u zult merken dat veel organisaties ervoor kiezen om een DBaaS te gebruiken om de tijd van hun DBA te optimaliseren, terwijl dezelfde bedrijfstypes en -groottes kies er ook voor om vast te houden aan intern zelfmanagement. Voor veel zakelijke bedrijven komt de beslissing grotendeels neer op maatwerk en controle. Daarom waarschuwen we ervoor om niet in gebreke te blijven met Azure Database, of zijn AWS-concurrent, Amazon RDS, omdat u hiermee geen MySQL-superuser-toegang of zelfs SSH-toegang tot uw machines kunt behouden. Bovendien is de mogelijkheid om uw implementatie-instellingen aan te passen zeer beperkt, zoals de instantietypen, RAM, schijfgrootte of IOPS die u kunt gebruiken. Hieronder vindt u meer informatie over de beste instantietypen en schijven die u kunt gebruiken, en u kunt deze MySQL-providervergelijking bekijken om de voordelen en beperkingen te zien van de vier beste beheerde MySQL-oplossingen, ScaleGrid, Compose, Azure Database en Amazon RDS.
implementatie met hoge beschikbaarheid
Als u in productie implementeert, moet u MySQL altijd instellen als een master-slave-implementatie. Standalone implementaties zijn een enkel knooppunt zonder enige replicatie en zouden eigenlijk alleen moeten worden gebruikt voor ontwikkel- of testomgevingen. Met master-slave-implementaties kunt u hoge beschikbaarheid configureren, dus als een van uw knooppunten uitvalt, kunt u een failover naar een slave uitvoeren zonder downtime. Dit wordt meestal ingesteld als een master-slave-slave met 3 knooppunten of een master-slave-quorum met 2+1 knooppunten. Het voordeel van het gebruik van een quorum is dat het een goedkoper alternatief is, maar het nadeel is dat u slechts 2 gegevensdragende knooppunten hebt, aangezien de andere als een quorumknooppunt fungeert om de beste failover-cursus te bepalen. Als uw toepassing in staat is om van de slave te lezen, moet u leesschaling uitvoeren zodat ze dezelfde gegevens van het clustervolume retourneren met minimale vertraging.
De beste manier om MySQL te hosten op Azure CloudClick To Tweet
Als u een MySQL-master-slave-configuratie gebruikt, raden we aan om semi-synchrone replicatie in te stellen om uw gegevensintegriteit te verbeteren met gegevensredundantie. Dit zorgt ervoor dat wanneer een commit met succes terugkeert, de gegevens zowel in de master als in de slave bestaan, dus in het geval dat een datacenter uitvalt, kan uw MySQL-master een failover naar een slave uitvoeren zonder enig gegevensverlies. U kunt dit doen met asynchrone of semi-synchrone replicatie, en leer er meer over in onze MySQL High Availability Explained – Part II blogpost.
Dus, hoe configureren we hoge beschikbaarheid voor MySQL op Azure? We moeten onze slave-instanties verdelen over verschillende Azure-beschikbaarheidszones (AZ). We willen er dus zeker van zijn dat we een Azure-regio kiezen die ten minste 3 AZ's heeft, waarbij elke instantie in een andere AZ wordt geplaatst. We doen dit omdat de beschikbaarheidsgaranties voor alle AZ's gelden, dus als 1 zone uitvalt, kan uw applicatiedatabase nog steeds online blijven via de andere 2 AZ's. Beschikbaarheidszones zijn vrij nieuw voor Azure, dus als je in een regio werkt die geen AZ's aanbiedt, heb je de mogelijkheid om beschikbaarheidssets te gebruiken. Deze zijn iets zwakker dan die van AZ, maar zorgen ervoor dat u over verschillende domeinen en racks wordt ingezet om u te beschermen tegen een mogelijke storing. Er is ook de mogelijkheid om in verschillende regio's te implementeren, maar dit is een ingewikkelder configuratie, dus we raden u aan contact op te nemen om dit te bespreken voordat u het implementeert.
Azure virtuele netwerken
De beste manier om uw database tegen internet te beschermen, is door deze in een privésubnet te implementeren om ervoor te zorgen dat deze niet wordt blootgesteld. Azure maakt dit eenvoudig in te stellen door het gebruik van een virtueel netwerk (VNET) dat kan worden geconfigureerd voor uw MySQL-servers. Met een Azure VNET voor MySQL kunt u veilige communicatie opzetten tussen uw servers, internet en zelfs uw on-premise private cloud-netwerk. Deze zijn meestal geconfigureerd om via één netwerk te communiceren, maar als u meer dan één regio moet verbinden, kunt u meerdere VNET's maken om te communiceren via Virtual Network Peering.
Bovendien kunt u uw MySQL-toegangscontrole beheren via Network Security Groups (NSG)-regels zonder te maken te krijgen met IP-witte lijsten. Dit is niet beschikbaar via Azure Database for MySQL, maar zowel VNET als NSG kunnen worden geconfigureerd via onze MySQL Bring Your Own Cloud (BYOC)-abonnementen op Azure, waar u uw clusters kunt hosten via uw eigen cloudaccount.
Azure-instantietypen
Een ander belangrijk aspect om rekening mee te houden, zijn de prestaties van uw MySQL-instanties in de openbare cloud. Azure cloud biedt meerdere typen instanties die kunnen worden gebruikt voor uw MySQL-hosting, waaronder Es2 v3, Ds2, v2 en Ls4.
We raden aan te beginnen met een voor geheugen geoptimaliseerde instantie, aangezien databases veel RAM vereisen en op zoek zijn naar de snelst mogelijke schijfsnelheid voor de beste prestaties. De Es2-serie is doorgaans een goed startpunt voor de meeste MySQL-workloads voor toepassingen. Van daaruit kunt u prestatietests uitvoeren om te zien of u meer CPU nodig heeft. In dat geval kunnen gebalanceerde instantietypen of CPU-intensieve instantietypen beter voldoen aan uw MySQL-behoeften, zoals de Dv3-instantietypen. Uw prestatietests kunnen ook aantonen dat u meer I/O (invoer/uitvoer) nodig heeft, u kunt overstappen op een schijfintensief instantietype.
Als u van plan bent om Azure de komende 1-3 jaar als uw MySQL-cloudprovider te gebruiken en redelijk consistente implementatieconfiguraties te behouden, kunt u ook rekening houden met gereserveerde instanties. Dit zijn in wezen prepaid-instanties waarmee u aanzienlijke kostenbesparingen kunt realiseren voor uw MySQL-hosting. U kunt gemiddeld zo'n 20% tot 30% besparen voor een jaar gereserveerde instanties en 40% tot 50% voor de 3 jaar gereserveerde instanties.
Azure-schijftypen
De eerste beslissing die u moet nemen als het gaat om het kiezen van een Azure-schijftype voor uw MySQL-implementaties, is of u een beheerde of een onbeheerde schijf wilt gebruiken. De onbeheerde schijven zijn de verouderde schijven die Azure aanbiedt, waarbij u het opslagaccount moet instellen, uw schijf moet toewijzen aan het opslagaccount en het IOPS-gebruik en de limieten voor dat opslagaccount moet bewaken. We raden u ten zeerste aan om beheerde schijven te gebruiken en als u nog steeds met onbeheerde schijven implementeert, kunt u overwegen over te stappen op beheerde schijven.
MySQL-ontwikkel-/testomgevingen:standaardschijven
Er zijn meerdere typen beheerde schijven beschikbaar via Azure, waarbij de standaard schijven de standaard zijn. Standaardschijven kunnen tot 500 IOPS (invoer-/uitvoerbewerkingen per seconde) ondersteunen en zijn goed voor ontwikkelings- en testbewerkingen omdat de grootte ervan dynamisch kan worden gewijzigd, maar mogen niet worden gebruikt voor MySQL-productie-implementaties.
MySQL-productie-implementaties:Premium-schijven
Voor uw MySQL-productieservers raden we u ten zeerste aan om Azure Premium-schijven te gebruiken. Er is een grote verscheidenheid aan premium schijven waaruit u kunt kiezen. Voor elke premium schijf kunt u de beste grootte kiezen, en elke grootte wordt geleverd met verschillende Provisioned IOPS, zodat u degene kunt selecteren die het beste bij uw toepassingsbehoeften past.
MySQL-productie-implementaties:lokale SSD
Azure Local SSD's zijn een krachtig alternatief voor premium schijven, doorgaans het meest geschikt voor grote clusters. De lokale SSD's bieden veel hogere I/O-prestaties en de beste doorvoer in Azure. Maar ze hebben wel het nadeel dat het kortstondige schijven zijn, geen permanente opslag, dus als je de instantie stopt, verdwijnen de gegevens. We raden de Ls v2-serie aan die erg snel is, maar pas op dat de CPU erg zwak is, wat machineknelpunten kan veroorzaken.
MySQL-back-ups op Azure
De beste manier om een back-up van uw MySQL-gegevens op Azure te maken, is door momentopnamen van beheerde schijven te gebruiken. Een momentopname is een alleen-lezen tijdstipversie van een schijf. Deze back-ups kunnen worden gelezen, gekopieerd of verwijderd, maar houd er rekening mee dat ze niet kunnen worden gewijzigd. Het is een goed idee om volledige back-ups te maken, zodat er een back-up wordt gemaakt van al uw databases, gebruikers en instellingen op de instance voor het geval u ooit een MySQL-database moet herstellen. Het is ook een goed idee om uw back-upmomentopnamen te versleutelen, zodat de back-up alleen kan worden teruggezet op de computer waarop de back-up is gemaakt.
Uw MySQL-back-ups leiden tot extra kosten voor Azure-gegevensopslag, tenzij u gebruikmaakt van een allesomvattende MySQL op Azure-oplossing zoals onze Dedicated Hosting-abonnementen bij ScaleGrid. Om de kosten te beheersen, is het een goed idee om uw back-ups te automatiseren via een aanpasbaar schema waarmee u de frequentie van uw back-ups, het maximale aantal back-ups dat moet worden bewaard en uw back-updoel kunt configureren. Dit helpt u natuurlijk ook om ervoor te zorgen dat er regelmatig een back-up van uw MySQL-gegevens wordt gemaakt in het geval van gegevensverlies in uw productie-implementatie, zodat u snel kunt herstellen met een recente back-up.
Als je vragen hebt over de beste manier om MySQL op Azure te hosten, laat dan hieronder een reactie achter of neem contact met ons op via support@scalegrid. io. U kunt ook een gratis proefperiode van 30 dagen starten om de voordelen te ontdekken van het gebruik van een volledig beheerde MySQL-service om de prestaties van uw implementaties te verbeteren.
