RDS vergelijken met EC2 voor het beheren van MySQL of MariaDB op AWS

RDS is een Database as a Service (DBaaS) die uw databases automatisch configureert en onderhoudt in de AWS-cloud. De gebruiker heeft beperkte macht over specifieke configuraties in vergelijking met het rechtstreeks uitvoeren van MySQL op Elastic Compute Cloud (EC2). Maar RDS is een handige service, zolang je maar kunt leven met de instanties en configuraties die het biedt.

Amazon RDS ondersteunt momenteel verschillende MySQL- en MariaDB-versies, evenals de MySQL-compatibele Amazon Aurora DB-engine. Het ondersteunt replicatie, maar zoals je mag verwachten van een vooraf gedefinieerde webconsole, zijn er enkele beperkingen.

Er zijn enkele compromissen bij het gebruik van RDS. Deze kunnen niet alleen van invloed zijn op de manier waarop u uw database-instanties beheert en inricht, maar ook op belangrijke zaken als prestaties, beveiliging en hoge beschikbaarheid.

In deze blog zullen we kijken naar de verschillen tussen het gebruik van RDS en het uitvoeren van MySQL op EC2, met de nadruk op replicatie. Zoals we zullen zien, is het geen gemakkelijke taak om te beslissen tussen het hosten van MySQL op een EC2-instantie of het gebruik van Amazon RDS.

RDS-platformafwegingen

De grootste databasegrootte die AWS kan hosten, hangt af van uw bronomgeving, de toewijzing van gegevens in uw brondatabase en hoe druk uw systeem is.

AWS is opgedeeld in regio's. Elk AWS-account heeft per regio limieten voor het aantal AWS-bronnen dat kan worden aangemaakt. Zodra een limiet voor een bron is bereikt, mislukken extra aanroepen om die bron te maken.

Voor Amazon RDS MySQL DB-instanties beperkt de maximale ingerichte opslaglimiet de grootte van een tabel tot een maximale grootte van 6 TB bij gebruik van InnoDB-bestand-per-tabel-tabelruimten.

InnoDB file-per-table-functie is iets waar u rekening mee moet houden, zelfs als u niet van plan bent een grote database naar de cloud te migreren. Het is u wellicht opgevallen dat sommige bestaande DB-instances een lagere limiet hebben. MySQL DB-instanties die vóór april 2014 zijn gemaakt, hebben bijvoorbeeld een maximale bestands- en tabelgrootte van 2 TB. Deze limiet voor bestandsgrootte van 2 TB is ook van toepassing op DB-instanties of leesreplica's die zijn gemaakt op basis van DB-snapshots die vóór april 2014 zijn gemaakt.

Een van de belangrijkste verschillen die van invloed zijn op de manier waarop u databasereplicatie instelt en onderhoudt, is het ontbreken van een SUPER-gebruiker. Om deze beperking aan te pakken, heeft Amazon opgeslagen procedures geïntroduceerd die zorgen voor verschillende DBA-taken. Hieronder staan ​​de belangrijkste procedures om MySQL RDS-replicatie te beheren.

Skip replicatiefout:

CALL mysql.rds_skip_repl_error;

Replicatie stoppen:

CALL mysql.rds_stop_replication;

Replicatie starten

CALL mysql.rds_start_replication;

Configureert een RDS-instantie als een leesreplica van een MySQL-instantie die buiten AWS wordt uitgevoerd.

CALL mysql.rds_set_external_master;

Configureert een MySQL-instantie opnieuw zodat deze niet langer een leesreplica is van een MySQL-instantie die buiten AWS wordt uitgevoerd.

CALL mysql.rds_reset_external_master;

Importeert een certificaat. Dit is nodig om SSL-communicatie en versleutelde replicatie mogelijk te maken.

CALL mysql.rds_import_binlog_ssl_material;

Verwijdert een certificaat.

CALL mysql.rds_remove_binlog_ssl_material;

Wijzigt de positie van het replicatiehoofdlogboek naar het begin van het volgende binaire logboek op het hoofd.

CALL mysql.rds_next_master_log;

Hoewel opgeslagen procedures een aantal taken uitvoeren, is het een beetje een leercurve. Gebrek aan SUPER-rechten kan ook problemen veroorzaken bij het gebruik van externe replicatiebewaking.

Amazon RDS ondersteunt momenteel het volgende niet:

• Algemene transactie-ID's
• Verplaatsbare tafelruimte
• Verificatieplug-in
• Plugin voor wachtwoordsterkte
• Replicatiefilters
• Semi-synchrone replicatie

Last but not least - toegang tot de shell. Amazon RDS staat geen directe hosttoegang toe tot een DB-instantie via Telnet, Secure Shell (SSH) of Windows Remote Desktop Connection (RDP). U kunt de client nog steeds op een toepassingshost gebruiken om verbinding te maken met de database via standaardtools zoals mysql-client.

Er zijn andere beperkingen, zoals beschreven in de RDS-documentatie.

Hoge beschikbaarheid met MySQL op EC2

Om implementatie- en beheer-/onderhoudstaken te automatiseren (met behoud van controle), is het mogelijk om ClusterControl te gebruiken. Net als bij RDS heb je het gemak om een ​​database-setup in een paar minuten te implementeren via een GUI. Het toevoegen van nodes, het plannen van back-ups, het uitvoeren van failovers, enzovoort, kan ook gemakkelijk via de GUI worden gedaan. Er zijn opties om MySQL rechtstreeks op EC2 te bedienen en zo de controle te behouden over iemands high-availability-opties. Wanneer u deze route aflegt, is het belangrijk om te begrijpen hoe u gebruik kunt maken van de verschillende AWS-functies die tot uw beschikking staan. Zorg ervoor dat u onze whitepaper 'DIY Cloud Database' bekijkt.

Implementatie

ClusterControl kan de implementatie van verschillende database-setups met hoge beschikbaarheid automatiseren - van master-slave-replicatie tot multi-masterclusters. Alle belangrijke MySQL-smaken worden ondersteund - Oracle MySQL, MariaDB en Percona Server. Enige initiële configuratie van VPC/beveiligingsgroep is vereist, en deze worden goed beschreven in de DIY Cloud Database-whitepaper. Merk op dat vergelijkbare concepten van toepassing zijn, of het nu AWS of Google Cloud of Azure is

Galera Cluster is een goed alternatief om te overwegen bij het implementeren van een zeer beschikbare MySQL-service. Het heeft zichzelf bewezen als een geloofwaardige vervanging voor traditionele MySQL-master-slave-architecturen, hoewel het geen vervanging is. De meeste applicaties kunnen nog steeds worden aangepast om erop te draaien. Het is mogelijk om verschillende segmenten te definiëren voor databases die zich uitstrekken over meerdere AWS-regio's.

Het is mogelijk om ‘hybride replicatie’ in te stellen door synchrone replicatie binnen een Galera-cluster te combineren met asynchrone replicatie tussen het cluster en een of meer slaves. Opties zoals het uitstellen van de slave geven een extra niveau van bescherming aan de gegevens.

Proxylaag

Om hoge beschikbaarheid te bereiken, is het implementeren van een zeer beschikbare setup niet voldoende. De toepassingen moeten op de een of andere manier weten welke knooppunten werken en welke niet. Veranderingen in de topologie, b.v. het verplaatsen van een master naar een andere host, moet ook op de een of andere manier worden gepropageerd om fouten in de applicatielaag te voorkomen. ClusterControl ondersteunt implementaties van proxy's zoals HAProxy, MaxScale en ProxySQL. Voor HAProxy en ProxySQL zijn er extra opties om redundante instanties met Keepalive en VirtualIP te implementeren.

Replica in verschillende regio's

Amazon RDS biedt leesreplicaservices. Replica's tussen regio's bieden u de mogelijkheid om reads te schalen, aangezien AWS zijn services in een aantal datacenters over de hele wereld heeft. Alle leesreplica's zijn toegankelijk en kunnen worden gebruikt voor lezen in maximaal vijf regio's. Deze knooppunten zijn onafhankelijk en kunnen worden gebruikt in uw upgradepad of kunnen worden gepromoveerd tot zelfstandige databases.

Daarnaast biedt Amazon Multi-AZ-implementaties op basis van DRBD, synchrone schijfreplicatie. Wat is het verschil met Read Replica's? Het belangrijkste verschil is dat alleen de database-engine op de primaire instantie actief is, wat leidt tot andere architecturale variaties.

In tegenstelling tot leesreplica's, vinden upgrades van de database-engineversie plaats op de primaire. Een ander verschil is dat AWS RDS automatisch een failover uitvoert met DRBD, terwijl voor het lezen van replica's (met behulp van asynchrone replicatie) handmatige bewerkingen van u nodig zijn.

Multi-AZ failover op RDS gebruikt een DNS wijziging om naar de standby instance te verwijzen, volgens Amazon zou dit binnen 60-120 seconden tijdens de failover moeten gebeuren. Omdat de stand-by dezelfde opslaggegevens gebruikt als de primaire, zal er waarschijnlijk transactie-/logherstel plaatsvinden. Grotere databases kunnen een aanzienlijke hoeveelheid tijd besteden aan InnoDB-herstel, dus houd daar rekening mee in uw DR-plan en RTO-berekening.

Dit gaat natuurlijk met extra kosten. Laten we eens kijken naar een eenvoudig voorbeeld. De kosten van db.t2.medium host met 2vCPU, 4GB ram bedragen 185,98 USD per maand, de prijs zal verdubbelen wanneer u Multizone (MZ) replica inschakelt naar 370,98 UDB. De prijs zal per regio verschillen, maar zal verdubbelen in MZ.

Om hetzelfde te bereiken met EC2 kunt u uw virtuele machines in verschillende regio's inzetten. Elke AWS-regio is volledig onafhankelijk. De instelling van de AWS-regio kan in de console worden gewijzigd door de omgevingsvariabele EC2_REGION in te stellen, of deze kan worden overschreven door de parameter --region te gebruiken met de AWS-opdrachtregelinterface. Wanneer uw set servers gereed is, kunt u ClusterControl gebruiken om uw replicatie te implementeren en te bewaken. Je kunt replicatie ook handmatig instellen via de console met behulp van standaardopdrachten.

Cross-technologie replicatie

Het is mogelijk om replicatie in te stellen tussen een Amazon RDS MySQL- of MariaDB DB-instantie en een MySQL- of MariaDB-instantie die extern is aan Amazon RDS. Dit wordt gedaan met behulp van de standaard replicatiemethode in mysql, door middel van binaire logboeken. Om binaire logboeken in te schakelen, moet u de my.cnf-configuratie wijzigen. Zonder toegang tot de shell werd deze taak onmogelijk in RDS. Het is op een niet zo voor de hand liggende manier gedaan. Je hebt twee opties. Een daarvan is het inschakelen van back-ups - stel geautomatiseerde back-ups in op uw Amazon RDS DB-instantie met retentie hoger dan 0. Of schakel replicatie naar een vooraf gebouwde slave-server in. Beide taken zullen binaire logboeken inschakelen die u later voor uw replicatie kunt gebruiken.

Bewaar de binlogs in uw hoofdinstantie totdat u hebt geverifieerd dat ze zijn toegepast op de replica. Dit onderhoud zorgt ervoor dat u uw master-instantie kunt herstellen in het geval van een storing.

Een andere wegversperring kunnen machtigingen zijn. De machtigingen die nodig zijn om replicatie op een Amazon RDS DB-instantie te starten, zijn beperkt en niet beschikbaar voor uw Amazon RDS-hoofdgebruiker. Daarom moet u de Amazon RDS-opdrachten mysql.rds_set_external_master en mysql.rds_start_replication gebruiken om replicatie in te stellen tussen uw live-database en uw Amazon RDS-database.

Bewaak failover-gebeurtenissen voor de Amazon RDS-instantie die uw replica is. Als er een failover optreedt, kan het DB-exemplaar dat uw replica is, mogelijk opnieuw worden gemaakt op een nieuwe host met een ander netwerkadres. Zie Amazon RDS Event Notification gebruiken voor informatie over het bewaken van failover-gebeurtenissen.

In het onderstaande voorbeeld zullen we zien hoe u replicatie van RDS naar een externe DB op een EC2-instantie kunt inschakelen.
U moet binaire logboeken hebben ingeschakeld, we gebruiken hier een RDS-slave.

Geef het aantal uren op om binaire logbestanden te bewaren.

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

Maak op RDS MASTER een replicatiegebruiker met de volgende opdrachten:

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

Voer op RDS SLAVE de volgende opdrachten uit:

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

Voer op RDS SLAVE mysqldump uit met het volgende formaat:

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

Importeer de DB-dump naar externe database:

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

Maak een replicatiefilter om tabellen die door AWS zijn gemaakt alleen op RDS te negeren

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

Replicatie starten

START SLAVE;

Controleer de replicatiestatus

SHOW SLAVE STATUS;

Dat is het voor nu. Het beheren van MySQL op AWS is een groot onderwerp. Laat ons uw mening weten in de opmerkingen hieronder.