Att köra ett MySQL Galera-kluster (antingen Percona-, MariaDB- eller Codership-bygget) stöds tyvärr inte (inte heller en del av) databaserna som stöds av Amazon RDS. De flesta databaser som stöds av RDS använder asynkron replikering, medan Galera Cluster är en synkron multi-master replikeringslösning. Galera kräver också InnoDB som sin lagringsmotor för att fungera korrekt, och även om du kan använda andra lagringsmotorer som MyISAM rekommenderas det inte att du använder denna lagringsmotor på grund av bristen på transaktionshantering.
På grund av bristen på stöd i RDS kommer den här bloggen att fokusera på de erbjudanden som är tillgängliga när du väljer och är värd för ditt Galera-baserade kluster med en AWS-miljö.
Det finns säkert många anledningar till varför du skulle välja eller inte välja AWS molnplattform, men för just det här ämnet kommer vi att gå över fördelarna och fördelarna med vad du kan utnyttja snarare än varför du skulle välja AWS-plattformen.
De virtuella servrarna (Elastic Compute-instanser)
Som nämnts tidigare är MySQL Galera inte en del av RDS och InnoDB är en transaktionslagringsmotor för vilken du behöver rätt resurser för dina applikationskrav. Den måste ha kapacitet att tillgodose efterfrågan från din kundförfrågningstrafik. Vid tidpunkten för den här artikeln är ditt enda val för att köra Galera Cluster genom att använda EC2, Amazons molnerbjudande för datorinstanser.
Eftersom du har fördelen av att köra ditt system på ett antal noder på EC2-instanser, så skiljer det sig inte mycket att köra ett Galera-kluster på EC2-verser på plats. Du kan komma åt servern på distans via SSH, installera dina önskade programvarupaket och välja vilken typ av Galera Cluster-bygge du vill använda.
Dessutom, med EC2 är detta erbjudande mer elastiskt och flexibelt, vilket gör att du kan leverera och erbjuda en enklare, granulerad installation. Du kan dra nytta av webbtjänsterna för att automatisera eller bygga ett antal noder om du behöver skala ut din miljö, eller till exempel automatisera byggandet av din iscensättning eller utvecklingsmiljö. Det ger dig också ett försprång att snabbt bygga din önskade miljö, välja och ställa in önskat operativsystem och hämta rätt datorresurser som passar dina krav (som CPU, minne och disklagring.) EC2 eliminerar tiden att vänta på hårdvara , eftersom du kan göra detta i farten. Du kan också använda deras AWS CLI-verktyg för att automatisera din Galera-klusterinstallation.
Priser för Amazon EC2-instanser
EC2 erbjuder ett antal val som är mycket flexibla för konsumenter som vill vara värd för sin Galera Cluster-miljö på AWS-beräkningsnoder. AWS Free Tier inkluderar 750 timmars Linux- och Windows t2.micro-instanser, varje månad, under ett år. Du kan stanna inom Free Tier genom att endast använda EC2 Micro-instanser, men detta kanske inte är det bästa för produktionsanvändning.
Det finns flera typer av EC2-instanser som du kan distribuera för när du tillhandahåller dina Galera-noder. Helst är dessa r4/r5/x1-familjen (minnesoptimerad) och c4/c5-familjen (datoroptimerad) ett idealiskt val, och dessa priser skiljer sig åt beroende på hur stort ditt behov av serverresurser är och typ av operativsystem.
Det här är de typer av betalda instanser du kan välja...
På begäran
Betala efter beräkningskapacitet (per timme eller per sekund), beror på vilken typ av instanser du kör. Till exempel kan priserna skilja sig åt när du tillhandahåller en Ubuntu-instans vs RHEL-instans bortsett från typen av instans. Den har inga långsiktiga åtaganden eller förskottsbetalningar som behövs. Den har också flexibiliteten att öka eller minska din beräkningskapacitet. Dessa instanser rekommenderas för billiga och flexibla miljöbehov som applikationer med kortsiktiga, taggiga eller oförutsägbara arbetsbelastningar som inte kan avbrytas, eller applikationer som utvecklas eller testas på Amazon EC2 för första gången. Kolla in den här för mer information.
Dedikerade värdar
Om du letar efter efterlevnad och regulatoriska krav såsom behovet av att skaffa en dedikerad server som körs på en dedikerad hårdvara för användning, passar denna typ av erbjudande dina behov. Dedikerade värdar kan hjälpa dig att hantera efterlevnadskrav och minska kostnaderna genom att låta dig använda din befintliga serverbundna programvarulicens, inklusive Windows Server, SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux eller andra programvarulicenser som är bundna till virtuella datorer , uttag eller fysiska kärnor, enligt dina licensvillkor. Det kan köpas On-Demand (en gång i timmen) eller som en reservation för upp till 70 % rabatt på On-Demand-priset. Kolla in den här för mer information.
Spotinstanser
De här instanserna låter dig begära reservdatorkapacitet för Amazon EC2 för upp till 90 % rabatt på On-Demand-priset. Detta rekommenderas för applikationer som har flexibla start- och sluttider, applikationer som endast är genomförbara till mycket låga beräkningspriser eller användare med akuta datorbehov för stora mängder extra kapacitet. Kolla in den här för mer information.
Reserverade instanser
Den här typen av betalningserbjudande ger dig möjlighet att få upp till 75 % rabatt och, beroende på vilken instans du vill reservera, kan du skaffa en kapacitetsreservation som ger dig ytterligare förtroende för din förmåga för att starta instanser när du behöver dem. Detta rekommenderas om dina applikationer har stabilt tillstånd eller förutsägbar användning, applikationer som kan kräva reserverad kapacitet eller kunder som kan åta sig att använda EC2 under en 1- eller 3-årsperiod för att minska sina totala datorkostnader. Kolla in den här för mer information.
Prisanmärkning
En sista sak med EC2, de erbjuder också en fakturering per sekund som också tar kostnaden för oanvända minuter och sekunder på en timmes avdrag från räkningen. Detta är fördelaktigt om du skalar ut under en minimal tid, bara för att hantera trafikförfrågan från en Galera-nod eller om du vill testa på en specifik nod för bara en begränsad tidsanvändning.
Databaskryptering på AWS
Om du är orolig för att dina data är konfidentiella eller att du följer de lagar som krävs för att din säkerhetsefterlevnad och bestämmelser ska uppfyllas, erbjuder AWS kryptering av data i vila. Om du använder MariaDB Cluster version 10.2+, har de inbyggt plugin-stöd för gränssnitt med Amazon Web Services (AWS) Key Management Service (KMS) API. Detta gör att du kan dra nytta av AWS-KMS-nyckelhanteringstjänsten för att underlätta åtskillnad av ansvar och fjärrloggning och granskning av förfrågningar om nyckelåtkomst. Istället för att lagra krypteringsnyckeln i en lokal fil, behåller detta plugin huvudnyckeln i AWS KMS.
När du först startar MariaDB kommer AWS KMS-pluginet att ansluta till AWS Key Management Service och be den generera en ny nyckel. MariaDB kommer att lagra den nyckeln på disken i en krypterad form. Nyckeln som är lagrad på disken kan inte användas för att dekryptera data; snarare, vid varje start ansluter MariaDB till AWS KMS och låter tjänsten dekryptera den eller de lokalt lagrade nyckelna. Den dekrypterade nyckeln lagras i minnet så länge MariaDB-serverprocessen körs, och den dekrypterade nyckeln i minnet används för att kryptera den lokala datan.
Alternativt, när du distribuerar dina EC2-instanser, kan du kryptera din datalagringsvolym med EBS (Elastic Block Storage) eller kryptera själva instansen. Kryptering för volymer av EBS-typ stöds alla, även om det kan ha en inverkan men latensen är mycket minimal eller till och med inte synlig för slutanvändarna. För kryptering av EC2-instanstyp stöds de flesta av de stora instanserna. Så om du använder dator- eller minnesoptimerade noder kan du dra nytta av dess kryptering.
Nedan är listan över instanstyper som stöds...
- Allmänt syfte:A1, M3, M4, M5, M5a, M5ad, M5d, T2, T3 och T3a
- Datoroptimerad:C3, C4, C5, C5d och C5n
- Minnesoptimerat:cr1.8xlarge, R3, R4, R5, R5a, R5ad, R5d, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, X1, X1e och z1d
- Lagringsoptimerad:D2, h1.2xlarge, h1.4xlarge, I2 och I3
- Accelererad beräkning:F1, G2, G3, P2 och P3
Du kan ställa in ditt AWS-konto för att alltid aktivera kryptering vid distribution av dina EC2-typ-instanser. Detta innebär att AWS kommer att kryptera nya EBS-volymer vid lanseringen och kryptera nya kopior av okrypterade ögonblicksbilder.
Multi-AZ/Multi-Region/Multi-Cloud-distributioner
Tyvärr, när detta skrivs, finns det inget sådant direkt stöd i AWS-konsolen (inte heller något av deras AWS API) som stöder Multi-AZ/-Region/-Cloud-distributioner för Galera-nodkluster.
Hög tillgänglighet, skalbarhet och redundans
För att uppnå en multi-AZ-distribution rekommenderar vi att du tillhandahåller dina galeranoder i olika tillgänglighetszoner. Detta förhindrar att klustret går ner eller ett klusterfel på grund av brist på beslutförhet.
Du kan också ställa in en AWS automatisk skalning och skapa en automatisk skalningsgrupp för att övervaka och göra statuskontroller så att ditt kluster alltid kommer att ha redundans, skalbar och hög tillgänglighet. Automatisk skalning bör lösa ditt problem om din nod går ner av någon okänd anledning.
För distribution i flera regioner eller flera moln har Galera sin egen parameter som heter gmcast.segment som du kan ställa in för vid serverstart. Den här parametern är utformad för att optimera kommunikationen mellan Galera-noderna och minimera mängden trafik som skickas mellan nätverkssegment, inklusive skrivuppsättningsrelä och IST- och SST-donatorval.
Den här typen av inställningar låter dig distribuera flera noder i olika regioner för ditt Galera-kluster. Bortsett från det kan du också distribuera dina Galera-noder på en annan leverantör, till exempel om den är värd i Google Cloud och du vill ha redundans på Microsoft Azure.
Jag skulle rekommendera dig att kolla in vår blogg Multiple Data Center Setups Using Galera Cluster for MySQL eller MariaDB and Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node för att samla mer information om hur man implementerar dessa typer av distributioner.
Databasprestanda på AWS
Beroende på din applikationsefterfrågan, om dina frågor är minneskrävande minnesoptimerade instanser ditt idealiska val. Om din applikation har högre transaktioner som kräver hög prestanda för webbservrar eller batchbearbetning, välj då beräkningsoptimerade instanser. Om du vill lära dig mer om att optimera ditt Galera Cluster kan du kolla in den här bloggen Hur man förbättrar prestanda för Galera Cluster för MySQL eller MariaDB.
Databassäkerhetskopior på AWS
Att skapa säkerhetskopior kan vara svårt eftersom det inte finns något direkt stöd inom AWS som är specifikt för MySQL Galera-teknik. AWS ger dig dock en katastrof- och återställningslösning med hjälp av EBS Snapshots. Du kan ta ögonblicksbilder av EBS-volymerna som är kopplade till din instans, sedan antingen ta en säkerhetskopia enligt schema med CloudWatch eller genom att använda Amazon Data Lifecycle Manager (Amazon DLM) för att automatisera ögonblicksbilderna.
Observera att de tagna ögonblicksbilderna är inkrementella säkerhetskopior, vilket innebär att endast de block på enheten som har ändrats efter din senaste ögonblicksbild sparas. Du kan lagra dessa ögonblicksbilder i AWS S3 för att spara lagringskostnader. Alternativt kan du använda externa verktyg som Percona Xtrabackup och Mydumper (för logiska säkerhetskopior) och lagra dessa på AWS EFS -> AWS S3 -> AWS Glacier.
Du kan också ställa in Lifecycle Management i AWS om du vill att dina säkerhetskopierade data ska lagras på ett mer kostnadseffektivt sätt. Om du har stora filer och ska använda AWS EFS kan du utnyttja deras AWS Backup-lösning eftersom detta också är en enkel men kostnadseffektiv lösning.
Å andra sidan kan du också använda externa tjänster (liksom ClusterControl) som ger dig både övervaknings- och backuplösningar. Kolla in det här om du vill veta mer.
Databasövervakning på AWS
AWS erbjuder hälsokontroller och vissa statuskontroller för att ge dig insyn i dina Galera-noder. Detta görs genom CloudWatch och CloudTrail.
CloudTrail låter dig aktivera och inspektera loggarna och utföra revisioner baserat på vilka åtgärder och spår som har gjorts.
CloudWatch låter dig samla in och spåra mätvärden, samla in och övervaka loggfiler och ställa in anpassade larm. Du kan ställa in den enligt dina anpassade behov och få systemomfattande insyn i resursanvändning, applikationsprestanda och drifttillstånd. CloudWatch kommer med en gratis nivå så länge du fortfarande faller inom dess gränser (se skärmdumpen nedan.)
CloudWatch kommer också med ett pris beroende på mängden mätvärden som distribueras. Kolla in dess nuvarande prissättning genom att kolla här.
Observera:det finns en nackdel med att använda CloudWatch. Den är inte utformad för att tillgodose databasens hälsa, särskilt för övervakning av MySQL Galera-klusternoder. Alternativt kan du använda externa verktyg som erbjuder högupplösta grafer eller diagram som är användbara vid rapportering och som är lättare att analysera vid diagnostisering av en problematisk nod.
För detta kan du använda PMM av Percona, DataDog, Idera, VividCortex eller vår alldeles egna ClusterControl (eftersom övervakning är GRATIS med ClusterControl Community.) Jag skulle rekommendera att du använder ett övervakningsverktyg som passar din behov baserat på dina individuella applikationskrav. Det är mycket viktigt att ditt övervakningsverktyg kan meddela dig aggressivt eller ge dig integration för snabbmeddelandesystem som Slack, PagerDuty eller till och med skicka SMS till dig när ett allvarligt hälsotillstånd eskalerar.
Databassäkerhet på AWS
Att säkra dina EC2-instanser är en av de viktigaste delarna av att distribuera din databas i det offentliga molnet. Du kan konfigurera ett privat undernät och ställa in de nödvändiga säkerhetsgrupperna som endast gynnas för att tillåta porten eller käll-IP beroende på din konfiguration. Du kan ställa in dina databasnoder med en icke-fjärråtkomst och bara ställa in en hoppvärd eller en Internet-gateway, om noder kräver åtkomst till internet för att komma åt eller uppdatera mjukvarupaket. Du kan läsa vår tidigare blogg Deploying Secure Multicloud MySQL Replication på AWS och GCP med VPN om hur vi ställer in detta.
Utöver detta kan du säkra din dataöverföring genom att använda TLS/SSL-anslutning eller kryptera din data när den är i vila. Om du använder ClusterControl är det enkelt och enkelt att distribuera en säker dataöverföring. Du kan kolla in vår blogg SSL Key Management and Encryption of MySQL Data in Transit om du vill testa. För data i vila kan lagring av dina data via S3 krypteras med AWS Server-Side Encryption eller använda AWS-KMS som jag har diskuterat tidigare. Kolla in den här externa bloggen om hur du ställer in och använder ett MariaDB-kluster med AWS-KMS så att du kan lagra dina data säkert i vila.
Galera Cluster Felsökning på AWS
AWS CloudWatch kan hjälpa till särskilt när man undersöker och kollar upp systemstatistiken. Du kan kontrollera nätverket, CPU, minne, disk och dess instans eller beräkna användning och balans. Detta kanske dock inte uppfyller dina krav när du gräver i ett specifikt fall.
CloudTrail kan utföra solida spår av åtgärder som har styrts baserat på ditt specifika AWS-konto. Detta hjälper dig att avgöra om händelserna inte kommer från MySQL Galera, utan kan vara något fel eller problem inom AWS-miljön (som Hyper-V har problem på värddatorn där din instans, som gäst, befinner sig värd.)
Om du använder ClusterControl, går du till Loggar -> Systemloggar, kommer du att kunna bläddra i de fångade felloggarna från själva MySQL Galera-noden. Förutom detta tillhandahåller ClusterControl realtidsövervakning som skulle förstärka ditt larm- och aviseringssystem i händelse av en nödsituation eller om din MySQL Galera-nod(er) är kaput.
Slutsats
AWS har inte rent stöd för en MySQL Galera Cluster-installation, till skillnad från AWS RDS som har MySQL-kompatibilitet. På grund av detta är de flesta rekommendationer eller åsikter som driver ett Galera-kluster för produktionsanvändning inom AWS-miljön baserade på erfarna och väl beprövade miljöer som har körts under mycket lång tid.
MariaDB Cluster kommer med en stor produktivitet, eftersom de ständigt ger kortfattat stöd för AWS-teknologistacklösningen. I den kommande versionen av MariaDB 10.5-versionen kommer de att erbjuda stöd för S3 Storage Engine, vilket kan vara värt att vänta på.
Externa verktyg kan hjälpa dig att hantera och kontrollera ditt MySQL Galera Cluster som körs på AWS Cloud, så det är inte ett stort problem om du har några dilemman och FUD om varför du ska köra eller byta till AWS Cloud Plattform.
AWS kanske inte är en lösning som passar alla i vissa fall, men den tillhandahåller ett brett utbud av lösningar som du kan anpassa och skräddarsy den för att passa dina behov.
I nästa del av vår blogg kommer vi att titta på en annan offentlig molnplattform, särskilt Google Cloud, och se hur vi kan dra nytta av om vi väljer att köra vårt Galera-kluster i deras plattform.