Sammenligning af RDS vs EC2 til håndtering af MySQL eller MariaDB på AWS

RDS er en Database as a Service (DBaaS), der automatisk konfigurerer og vedligeholder dine databaser i AWS-skyen. Brugeren har begrænset magt over specifikke konfigurationer i forhold til at køre MySQL direkte på Elastic Compute Cloud (EC2). Men RDS er en bekvem tjeneste, så længe du kan leve med de forekomster og konfigurationer, den tilbyder.

Amazon RDS understøtter i øjeblikket forskellige MySQL- og MariaDB-versioner samt den MySQL-kompatible Amazon Aurora DB-motor. Det understøtter replikering, men som du kan forvente af en foruddefineret webkonsol, er der nogle begrænsninger.

Der er nogle afvejninger ved brug af RDS. Disse kan ikke kun påvirke den måde, du administrerer og klargør dine databaseforekomster på, men også vigtige ting som ydeevne, sikkerhed og høj tilgængelighed.

I denne blog vil vi tage et kig på forskellene mellem at bruge RDS og at køre MySQL på EC2, med fokus på replikering. Som vi vil se, er det ikke en let opgave at vælge mellem at hoste MySQL på en EC2-instans eller bruge Amazon RDS.

RDS-platformsafvejninger

Den største størrelse af databasen, som AWS kan hoste, afhænger af dit kildemiljø, allokeringen af ​​data i din kildedatabase og hvor travlt dit system er.

AWS er ​​opdelt i regioner. Hver AWS-konto har begrænsninger pr. region på antallet af AWS-ressourcer, der kan oprettes. Når en grænse for en ressource er nået, vil yderligere opkald til at oprette den ressource mislykkes.

For Amazon RDS MySQL DB-forekomster begrænser den maksimalt klargjorte lagergrænse størrelsen af ​​en tabel til en maksimal størrelse på 6 TB, når der bruges InnoDB fil-pr-table tablespaces.

InnoDB fil-per-tabel-funktion er noget, du bør overveje, selvom du ikke ønsker at migrere en stor database til skyen. Du bemærker måske, at nogle eksisterende DB-forekomster har en nedre grænse. For eksempel har MySQL DB-instanser oprettet før april 2014 en fil- og tabelstørrelsesgrænse på 2 TB. Denne grænse på 2 TB filstørrelse gælder også for DB-forekomster eller læsereplikaer, der er oprettet ud fra DB-øjebliksbilleder taget før april 2014.

En af de vigtigste forskelle, der påvirker den måde, du opsætter og vedligeholder databasereplikering på, er manglen på SUPER-bruger. For at imødegå denne begrænsning introducerede Amazon lagrede procedurer, der tager sig af forskellige DBA-opgaver. Nedenfor er de vigtigste procedurer til at administrere MySQL RDS-replikering.

Spring replikeringsfejl:

CALL mysql.rds_skip_repl_error;

Stop replikering:

CALL mysql.rds_stop_replication;

Start replikering

CALL mysql.rds_start_replication;

Konfigurerer en RDS-instans som en Read Replica af en MySQL-instans, der kører uden for AWS.

CALL mysql.rds_set_external_master;

Omkonfigurerer en MySQL-instans til ikke længere at være en Read Replica af en MySQL-instans, der kører uden for AWS.

CALL mysql.rds_reset_external_master;

Importerer et certifikat. Dette er nødvendigt for at aktivere SSL-kommunikation og krypteret replikering.

CALL mysql.rds_import_binlog_ssl_material;

Fjerner et certifikat.

CALL mysql.rds_remove_binlog_ssl_material;

Ændrer replikeringsmasterlogpositionen til starten af ​​den næste binære log på masteren.

CALL mysql.rds_next_master_log;

Mens lagrede procedurer tager sig af en række opgaver, er det lidt af en indlæringskurve. Mangel på SUPER-privilegier kan også skabe problemer med at bruge ekstern replikeringsovervågning.

Amazon RDS understøtter i øjeblikket ikke følgende:

• Globale transaktions-id'er
• Transportabel bordplads
• Authentication Plugin
• Plugin til adgangskodestyrke
• Replikeringsfiltre
• Semi-synkron replikering

Sidst men ikke mindst - adgang til skallen. Amazon RDS tillader ikke direkte værtsadgang til en DB-instans via Telnet, Secure Shell (SSH) eller Windows Remote Desktop Connection (RDP). Du kan stadig bruge klienten på en applikationsvært til at oprette forbindelse til DB'en via standardværktøjer såsom mysql-klient.

Der er andre begrænsninger, som beskrevet i RDS-dokumentationen.

Høj tilgængelighed med MySQL på EC2

For at automatisere implementerings- og administrations-/vedligeholdelsesopgaver (og samtidig bevare kontrollen), er det muligt at bruge ClusterControl. Ligesom med RDS har du bekvemmeligheden ved at implementere en databaseopsætning på få minutter via en GUI. Tilføjelse af noder, planlægning af sikkerhedskopier, udførelse af failovers og så videre, kan også bekvemt ske via GUI.Der er muligheder for at betjene MySQL direkte på EC2, og derved bevare kontrollen over sine muligheder for høj tilgængelighed. Når du går denne vej, er det vigtigt at forstå, hvordan du kan udnytte de forskellige AWS-funktioner, der er til din rådighed. Sørg for at tjekke vores 'DIY Cloud Database' hvidbog.

Implementering

ClusterControl kan automatisere implementeringen af ​​forskellige databaseopsætninger med høj tilgængelighed - fra master-slave-replikering til multi-master-klynger. Alle de vigtigste MySQL-varianter er understøttet - Oracle MySQL, MariaDB og Percona Server. Nogle indledende opsætning af VPC/sikkerhedsgruppe er påkrævet, og disse er godt beskrevet i DIY Cloud Database whitepaper. Bemærk, at lignende koncepter gælder, uanset om det er AWS eller Google Cloud eller Azure

Galera Cluster er et godt alternativ at overveje, når du implementerer en meget tilgængelig MySQL-tjeneste. Det har etableret sig som en troværdig erstatning for traditionelle MySQL master-slave-arkitekturer, selvom det ikke er en drop-in erstatning. De fleste applikationer kan stadig tilpasses til at køre på den. Det er muligt at definere forskellige segmenter for databaser, der spænder over flere AWS-regioner.

Det er muligt at opsætte 'hybrid replikation' ved at kombinere synkron replikation i en Galera Cluster og asynkron replikation mellem klyngen og en eller flere slaver. Muligheder som at forsinke slaven giver et ekstra niveau af beskyttelse til dataene.

Proxylag

For at opnå høj tilgængelighed er det ikke nok at implementere en meget tilgængelig opsætning. Applikationerne skal på en eller anden måde vide, hvilke noder der fungerer, og hvilke der ikke gør. Ændringer i topologi, f.eks. flytning af en master til en anden vært, skal også udbredes på en eller anden måde for at undgå fejl i applikationslaget. ClusterControl understøtter implementeringer af proxyer som HAProxy, MaxScale og ProxySQL. For HAProxy og ProxySQL er der yderligere muligheder for at implementere redundante forekomster med Keepalved og VirtualIP.

Replika på tværs af regioner

Amazon RDS leverer læsereplikatjenester. Replikaer på tværs af regioner giver dig mulighed for at skalere læsninger, da AWS har sine tjenester i en række datacentre rundt om i verden. Alle læste replikaer er tilgængelige og kan bruges til læsning i et maksimalt antal af fem regioner. Disse noder er uafhængige og kan bruges i din opgraderingssti eller kan forfremmes til selvstændige databaser.

Derudover tilbyder Amazon Multi-AZ-implementeringer baseret på DRBD, synkron diskreplikering. Hvordan adskiller det sig fra Read Replicas? Den største forskel er, at kun databasemotoren på den primære instans er aktiv, hvilket fører til andre arkitektoniske variationer.

I modsætning til læsereplikaer sker opgraderinger af databasemotorversioner på den primære. En anden forskel er, at AWS RDS vil failover automatisk med DRBD, mens læsereplikaer (ved brug af asynkron replikering) vil kræve manuelle handlinger fra dig.

Multi-AZ failover på RDS bruger en DNS-ændring til at pege på standby-instansen, ifølge Amazon skulle dette ske inden for 60-120 sekunder under failover. Fordi standbyen bruger de samme lagringsdata som den primære, vil der sandsynligvis være transaktions-/loggendannelse. Større databaser kan bruge en betydelig mængde tid på InnoDB-gendannelse, så tag det med i din DR-plan og RTO-beregning.

Dette er naturligvis forbundet med ekstra omkostninger. Lad os tage et kig på nogle grundlæggende eksempler. Prisen på db.t2.medium vært med 2vCPU, 4GB ram er 185,98 USD pr. måned, prisen fordobles, når du aktiverer Multizone (MZ) replika til 370,98 UDB. Prisen vil variere efter region, men den fordobles i MZ.

For at opnå det samme med EC2 kan du installere dine virtuelle maskiner i forskellige regioner. Hver AWS-region er fuldstændig uafhængig. Indstillingen af ​​AWS Region kan ændres i konsollen ved at indstille miljøvariablen EC2_REGION, eller den kan tilsidesættes ved at bruge parameteren --region med AWS Command Line Interface. Når dit sæt servere er klar, kan du bruge ClusterControl til at implementere og overvåge din replikering. Du kan også manuelt konfigurere replikering gennem konsollen ved hjælp af standardkommandoer.

Replikering på tværs af teknologi

Det er muligt at opsætte replikering mellem en Amazon RDS MySQL- eller MariaDB DB-instans og en MySQL- eller MariaDB-instans, der er ekstern i forhold til Amazon RDS. Dette gøres ved hjælp af standard replikeringsmetode i mysql, gennem binære logfiler. For at aktivere binære logfiler skal du ændre my.cnf-konfigurationen. Uden adgang til skallen blev denne opgave umulig i RDS. Det er gjort på en ikke så indlysende måde. Du har to muligheder. Den ene er at aktivere sikkerhedskopier - sæt automatiske sikkerhedskopier på din Amazon RDS DB-instans med retention til højere end 0. Eller aktiver replikering til en forudbygget slaveserver. Begge opgaver vil aktivere binære logfiler, som du senere kan bruge til din replikering.

Vedligehold binlogs i din masterinstans, indtil du har bekræftet, at de er blevet anvendt på replikaen. Denne vedligeholdelse sikrer, at du kan gendanne din masterinstans i tilfælde af en fejl.

En anden vejspærring kan være tilladelser. De nødvendige tilladelser for at starte replikering på en Amazon RDS DB-instans er begrænsede og ikke tilgængelige for din Amazon RDS-masterbruger. På grund af dette skal du bruge Amazon RDS mysql.rds_set_external_master og mysql.rds_start_replication kommandoerne til at opsætte replikering mellem din live database og din Amazon RDS database.

Overvåg failover-hændelser for Amazon RDS-instansen, der er din replika. Hvis der opstår en failover, kan den DB-instans, der er din replika, blive genskabt på en ny vært med en anden netværksadresse. For information om, hvordan man overvåger failover-hændelser, se Brug af Amazon RDS-hændelsesmeddelelse.

I eksemplet nedenfor vil vi se, hvordan du aktiverer replikering fra RDS til en ekstern DB placeret på en EC2-instans.
Du bør have binære logfiler aktiveret, vi bruger en RDS-slave her.

Angiv antallet af timer for at beholde binære logfiler.

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

På RDS MASTER skal du oprette en replikeringsbruger med følgende kommandoer:

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

På RDS SLAVE skal du køre kommandoerne:

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 skal du køre mysqldump med følgende format:

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

Importer DB-dumpet til ekstern 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>;

Opret et replikeringsfilter for at ignorere tabeller oprettet af AWS kun på RDS

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

Start replikering

START SLAVE;

Bekræft replikeringsstatus

SHOW SLAVE STATUS;

Det er det for nu. Håndtering af MySQL på AWS er ​​et stort emne. Fortæl os dine tanker i kommentarfeltet nedenfor.