Jämför RDS vs EC2 för att hantera MySQL eller MariaDB på AWS

RDS är en Database as a Service (DBaaS) som automatiskt konfigurerar och underhåller dina databaser i AWS-molnet. Användaren har begränsad makt över specifika konfigurationer i jämförelse med att köra MySQL direkt på Elastic Compute Cloud (EC2). Men RDS är en bekväm tjänst, så länge du kan leva med de instanser och konfigurationer som den erbjuder.

Amazon RDS stöder för närvarande olika MySQL- och MariaDB-versioner samt den MySQL-kompatibla Amazon Aurora DB-motorn. Den stöder replikering, men som du kan förvänta dig av en fördefinierad webbkonsol finns det vissa begränsningar.

Det finns vissa avvägningar när du använder RDS. Dessa kan inte bara påverka hur du hanterar och tillhandahåller dina databasinstanser, utan också viktiga saker som prestanda, säkerhet och hög tillgänglighet.

I den här bloggen kommer vi att ta en titt på skillnaderna mellan att använda RDS och att köra MySQL på EC2, med fokus på replikering. Som vi kommer att se är det ingen lätt uppgift att välja mellan att hosta MySQL på en EC2-instans eller använda Amazon RDS.

RDS-plattformsavvägningar

Den största storleken på databasen som AWS kan vara värd för beror på din källmiljö, allokeringen av data i din källdatabas och hur upptaget ditt system är.

AWS är uppdelat i regioner. Varje AWS-konto har gränser, per region, för antalet AWS-resurser som kan skapas. När en gräns för en resurs har nåtts kommer ytterligare anrop för att skapa den resursen att misslyckas.

För Amazon RDS MySQL DB-instanser begränsar den maximala lagringsgränsen storleken på en tabell till en maximal storlek på 6 TB när du använder InnoDB-fil-per-tabell-tabellutrymmen.

InnoDB fil-per-tabell-funktion är något som du bör överväga även om du inte vill migrera en stor databas till molnet. Du kanske märker att vissa befintliga DB-instanser har en lägre gräns. Till exempel har MySQL DB-instanser skapade före april 2014 en fil- och tabellstorleksgräns på 2 TB. Den här filstorleksgränsen på 2 TB gäller även för DB-instanser eller Read Replicas skapade från DB-ögonblicksbilder tagna före april 2014.

En av de viktigaste skillnaderna som påverkar hur du ställer in och underhåller databasreplikering är bristen på SUPER användare. För att komma till rätta med denna begränsning introducerade Amazon lagrade procedurer som tar hand om olika DBA-uppgifter. Nedan är de viktigaste procedurerna för att hantera MySQL RDS-replikering.

Hoppa över replikeringsfel:

CALL mysql.rds_skip_repl_error;

Stoppa replikering:

CALL mysql.rds_stop_replication;

Starta replikering

CALL mysql.rds_start_replication;

Konfigurerar en RDS-instans som en Read Replica av en MySQL-instans som körs utanför AWS.

CALL mysql.rds_set_external_master;

Konfigurerar om en MySQL-instans så att den inte längre är en Read Replica av en MySQL-instans som körs utanför AWS.

CALL mysql.rds_reset_external_master;

Importerar ett certifikat. Detta behövs för att möjliggöra SSL-kommunikation och krypterad replikering.

CALL mysql.rds_import_binlog_ssl_material;

Tar bort ett certifikat.

CALL mysql.rds_remove_binlog_ssl_material;

Ändrar replikeringsmasterloggpositionen till början av nästa binära logg på mastern.

CALL mysql.rds_next_master_log;

Medan lagrade procedurer tar hand om ett antal uppgifter, är det lite av en inlärningskurva. Brist på SUPER-behörighet kan också skapa problem med att använda extern replikeringsövervakning.

Amazon RDS stöder för närvarande inte följande:

• Globala transaktions-ID:n
• Transportabelt bordsutrymme
• Autentiseringsplugin
• Plugin för lösenordsstyrka
• Replikeringsfilter
• Halvsynkron replikering

Sist men inte minst - tillgång till skalet. Amazon RDS tillåter inte direkt värdåtkomst till en DB-instans via Telnet, Secure Shell (SSH) eller Windows Remote Desktop Connection (RDP). Du kan fortfarande använda klienten på en applikationsvärd för att ansluta till DB via standardverktyg som mysql-klienten.

Det finns andra begränsningar, som beskrivs i RDS-dokumentationen.

Hög tillgänglighet med MySQL på EC2

För att automatisera driftsättning och hanterings-/underhållsuppgifter (med bibehållen kontroll) är det möjligt att använda ClusterControl. Precis som med RDS har du bekvämligheten att distribuera en databasinstallation på några minuter via ett grafiskt användargränssnitt. Att lägga till noder, schemalägga säkerhetskopior, utföra failovers, och så vidare, kan också bekvämt göras via GUI. Det finns alternativ att använda MySQL direkt på EC2 och därigenom behålla kontrollen över sina högtillgänglighetsalternativ. När du går den här vägen är det viktigt att förstå hur du kan utnyttja de olika AWS-funktionerna som står till ditt förfogande. Se till att du kollar in vår vitbok för "DIY Cloud Database".

Implementering

ClusterControl kan automatisera distributionen av olika databasinställningar med hög tillgänglighet - från master-slave replikering till multi-master kluster. Alla de viktigaste MySQL-smakerna stöds - Oracle MySQL, MariaDB och Percona Server. Vissa initiala inställningar av VPC/säkerhetsgrupp krävs, och dessa beskrivs väl i DIY Cloud Database whitepaper. Observera att liknande koncept gäller, oavsett om det är AWS eller Google Cloud eller Azure

Galera Cluster är ett bra alternativ att överväga när du distribuerar en mycket tillgänglig MySQL-tjänst. Det har etablerat sig som en trovärdig ersättare för traditionella MySQL master-slave-arkitekturer, även om det inte är en drop-in ersättare. De flesta applikationer kan fortfarande anpassas för att köras på den. Det är möjligt att definiera olika segment för databaser som sträcker sig över flera AWS-regioner.

Det är möjligt att ställa in "hybridreplikering" genom att kombinera synkron replikering inom ett Galera-kluster och asynkron replikering mellan klustret och en eller flera slavar. Alternativ som att fördröja slaven ger en extra skyddsnivå för data.

Proxylager

För att uppnå hög tillgänglighet räcker det inte med att implementera en högtillgänglig installation. Applikationerna måste på något sätt veta vilka noder som fungerar och vilka som inte gör det. Förändringar i topologi, t.ex. flytta en master till en annan värd, måste också spridas på något sätt för att undvika fel i applikationslagret. ClusterControl stöder distributioner av proxyservrar som HAProxy, MaxScale och ProxySQL. För HAProxy och ProxySQL finns det ytterligare alternativ för att distribuera redundanta instanser med Keepalved och VirtualIP.

Replika över region

Amazon RDS tillhandahåller läsreplikatjänster. Repliker över regioner ger dig möjligheten att skala läsningar, eftersom AWS har sina tjänster i ett antal datacenter runt om i världen. Alla läsrepliker är tillgängliga och kan användas för läsning i maximalt fem regioner. Dessa noder är oberoende och kan användas i din uppgraderingsväg, eller kan främjas till fristående databaser.

Utöver det erbjuder Amazon Multi-AZ-distributioner baserade på DRBD, synkron diskreplikering. Hur skiljer det sig från Read Replicas? Den största skillnaden är att endast databasmotorn på den primära instansen är aktiv, vilket leder till andra arkitektoniska variationer.

I motsats till läsrepliker sker uppgraderingar av databasmotorversioner på den primära. En annan skillnad är att AWS RDS kommer att failover automatiskt med DRBD, medan läsrepliker (med asynkron replikering) kräver manuella operationer från dig.

Multi-AZ-failover på RDS använder en DNS-ändring för att peka på standby-instansen, enligt Amazon ska detta ske inom 60-120 sekunder under failover. Eftersom vänteläget använder samma lagringsdata som den primära, kommer det förmodligen att ske transaktions-/loggåterställning. Större databaser kan spendera en betydande tid på InnoDB-återställning, så tänk på det i din DR-plan och RTO-beräkning.

Naturligtvis medför detta en extra kostnad. Låt oss ta en titt på några grundläggande exempel. Kostnaden för db.t2.medium värd med 2vCPU, 4GB ram är 185,98 USD per månad, priset kommer att fördubblas när du aktiverar Multizone (MZ) replika till 370,98 UDB. Priset kommer att variera beroende på region men det kommer att fördubblas i MZ.

För att uppnå samma sak med EC2 kan du distribuera dina virtuella maskiner i olika regioner. Varje AWS-region är helt oberoende. Inställningen av AWS Region kan ändras i konsolen genom att ställa in miljövariabeln EC2_REGION, eller så kan den åsidosättas genom att använda parametern --region med AWS kommandoradsgränssnitt. När din uppsättning servrar är klara kan du använda ClusterControl för att distribuera och övervaka din replikering. Du kan också ställa in replikering manuellt via konsolen med standardkommandon.

Tvärteknologisk replikering

Det är möjligt att ställa in replikering mellan en Amazon RDS MySQL- eller MariaDB DB-instans och en MySQL- eller MariaDB-instans som är extern till Amazon RDS. Detta görs med standardreplikeringsmetoden i mysql, genom binära loggar. För att aktivera binära loggar måste du ändra my.cnf-konfigurationen. Utan tillgång till skalet blev denna uppgift omöjlig i RDS. Det är gjort på ett inte så självklart sätt. Du har två alternativ. En är att aktivera säkerhetskopieringar - ställ in automatiska säkerhetskopior på din Amazon RDS DB-instans med retention till högre än 0. Eller aktivera replikering till en förbyggd slavserver. Båda uppgifterna kommer att aktivera binära loggar som du senare kan använda för din replikering.

Behåll binloggarna i din masterinstans tills du har verifierat att de har applicerats på repliken. Detta underhåll säkerställer att du kan återställa din huvudinstans i händelse av ett fel.

En annan vägspärr kan vara behörigheter. Behörigheterna som krävs för att starta replikering på en Amazon RDS DB-instans är begränsade och inte tillgängliga för din Amazon RDS-huvudanvändare. På grund av detta måste du använda kommandona Amazon RDS mysql.rds_set_external_master och mysql.rds_start_replication för att ställa in replikering mellan din livedatabas och din Amazon RDS-databas.

Övervaka failover-händelser för Amazon RDS-instansen som är din replik. Om en failover inträffar kan DB-instansen som är din replik återskapas på en ny värd med en annan nätverksadress. För information om hur man övervakar failover-händelser, se Använda Amazon RDS-händelsemeddelande.

I exemplet nedan kommer vi att se hur man aktiverar replikering från RDS till en extern DB som finns på en EC2-instans.
Du bör ha binära loggar aktiverade, vi använder en RDS-slav här.

Ange antalet timmar för att behålla binära loggar.

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

På RDS MASTER skapar du en replikeringsanvändare med följande kommandon:

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

På RDS SLAVE, kör kommandona:

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

På RDS SLAVE, kör mysqldump med följande format:

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

Importera DB-dumpen till extern databas:

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>;

Skapa ett replikeringsfilter för att ignorera tabeller skapade av AWS endast på RDS

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

Starta replikering

START SLAVE;

Verifiera replikeringsstatus

SHOW SLAVE STATUS;

Det var allt för nu. Att hantera MySQL på AWS är ett stort ämne. Låt oss veta dina tankar i kommentarsfältet nedan.