Cloud Disaster Recovery för MariaDB och MySQL

MySQL har en lång tradition av geografisk replikering. Att distribuera kluster till fjärrdatacenter minskar effekterna av geografisk latens genom att föra data närmare användaren. Det ger också en kapacitet för katastrofåterställning. På grund av den betydande kostnaden för att duplicera hårdvara på en separat webbplats var det inte många företag som hade råd med det tidigare. En annan kostnad är skicklig personal som kan designa, implementera och underhålla en sofistikerad miljö med flera datacenter.

Med Cloud och DevOps automationsrevolutionen har det aldrig varit mer tillgängligt för massorna att ha distribuerat datacenter. Molnleverantörer ökar utbudet av tjänster de erbjuder till ett bättre pris. Man kan bygga cross-moln, hybridmiljöer med data spridd över hela världen. Man kan göra flexibla och skalbara DR-planer för att närma sig ett brett spektrum av störningsscenarier. I vissa fall kan det bara vara en säkerhetskopia som lagras utanför platsen. I andra fall kan det vara en 1 till 1 kopia av en produktionsmiljö som körs någon annanstans.

I den här bloggen kommer vi att ta en titt på några av dessa fall och ta upp vanliga scenarier.

Lagra säkerhetskopior i molnet

En DR-plan är en allmän term som beskriver en process för att återställa störda IT-system och andra kritiska tillgångar som en organisation använder. Säkerhetskopiering är den primära metoden för att uppnå detta. När en säkerhetskopia finns i samma datacenter som dina produktionsservrar riskerar du att all data kan raderas ut ifall du skulle förlora det datacentret. För att undvika det bör du ha policyn att skapa en kopia på en annan fysisk plats. Det är fortfarande en god praxis att behålla en säkerhetskopia på disken för att minska tiden som krävs för att återställa. I de flesta fall kommer du att behålla din primära säkerhetskopia i samma datacenter (för att minimera återställningstiden), men du bör också ha en säkerhetskopia som kan användas för att återställa affärsrutiner när det primära datacentret är nere.

ClusterControl möjliggör sömlös integration mellan din databasmiljö och molnet. Det ger alternativ för att migrera data till molnet. Vi erbjuder en komplett kombination av säkerhetskopiering av databas för Amazon Web Services (AWS), Google Cloud Services eller Microsoft Azure. Säkerhetskopieringar kan nu köras, schemaläggas, laddas ner och återställas direkt från din valfria molnleverantör. Denna förmåga ger ökad redundans, bättre alternativ för katastrofåterställning och fördelar i både prestanda och kostnadsbesparingar.

Det första steget för att ställa in "datacenterfel - säkerhetskopiering" är att tillhandahålla autentiseringsuppgifter för din molnoperatör. Du kan välja mellan flera leverantörer här. Låt oss ta en titt på processen som ställts in för den mest populära molnoperatören - AWS.

Allt du behöver är AWS Key ID och hemligheten för regionen där du vill lagra din säkerhetskopia. Du kan få det från AWS-konsolen. Du kan följa några steg för att få det.

1. Använd e-postadressen och lösenordet för ditt AWS-konto för att logga in på AWS Management Console som AWS-kontorotanvändare.
2. På sidan IAM Dashboard väljer du ditt kontonamn i navigeringsfältet och väljer sedan Mina säkerhetsuppgifter .
3. Om du ser en varning om åtkomst till säkerhetsuppgifterna för ditt AWS-konto väljer du Fortsätt till säkerhetsuppgifterna .
4. Utöka avsnittet Åtkomstnycklar (åtkomstnyckel-ID och hemlig åtkomstnyckel).
5. Välj att Skapa ny åtkomstnyckel . Välj sedan Ladda ner nyckelfil för att spara åtkomstnyckel-ID och hemlig åtkomstnyckel till en fil på din dator. När du har stängt dialogrutan kommer du inte att kunna hämta denna hemliga åtkomstnyckel igen.

När allt är klart kan du justera ditt säkerhetskopieringsschema och aktivera alternativet för säkerhetskopiering till moln. För att minska nätverkstrafiken, se till att aktivera datakomprimering. Det gör säkerhetskopior mindre och minimerar tiden som behövs för uppladdning. En annan bra praxis är att kryptera säkerhetskopian. ClusterControl skapar en nyckel automatiskt och använder den om du bestämmer dig för att återställa den. Avancerade säkerhetskopieringspolicyer bör ha olika lagringstider för säkerhetskopior som lagras på servrar i samma datacenter och säkerhetskopieringar som lagras på en annan fysisk plats. Du bör ställa in en längre lagringsperiod för molnbaserade säkerhetskopior och kortare period för säkerhetskopior som lagras nära produktionsmiljön, eftersom sannolikheten för återställning minskar med säkerhetskopieringens livslängd.

Utöka ditt kluster med asynkron replikering

Galera med asynkron replikering kan vara en utmärkt lösning för att bygga en aktiv DR-nod i ett fjärrdatacenter. Det finns några goda skäl att koppla en asynkron slav till ett Galera-kluster. Långvariga frågor av OLAP-typ på en Galera-nod kan sakta ner ett helt kluster. Med alternativet för fördröjd applicering kan fördröjd replikering rädda dig från mänskliga fel så att alla dessa gyllene ingångar inte kommer att tillämpas omedelbart på din backupnod.

I ClusterControl görs förlängning av en Galera-nodgrupp med asynkron replikering i en ensidig guide. Du måste tillhandahålla nödvändig information om din framtida eller befintliga slavserver. Slaven kommer att ställas in från en befintlig säkerhetskopia, eller en nyströmmad XtraBackup från mastern till slaven.

Load Balancers i Multi-Datacenter

Lastbalanserare är en avgörande komponent i MySQL och MariaDB databas hög tillgänglighet. Det räcker inte att ha ett kluster som spänner över flera datacenter. Du behöver fortfarande dina tjänster för att komma åt dem. Ett fel på en lastbalanserare som är tillgänglig i ett datacenter kommer att göra hela din miljö oåtkomlig.

En av de populära metoderna för att dölja databaslagrets komplexitet från en applikation är att använda en proxy. Proxies fungerar som en ingångspunkt till databaserna, de spårar databasnodernas tillstånd och ska alltid dirigera trafik till endast de noder som är tillgängliga. ClusterControl gör det enkelt att distribuera och konfigurera flera olika lastbalanseringstekniker för MySQL och MariaDB, inklusive ProxySQL, HAProxy, med ett peka-och-klicka grafiskt gränssnitt.

Det gör det också möjligt att göra denna komponent överflödig genom att lägga keepalive ovanpå den. För att förhindra att dina lastbalanserare är en enda felpunkt, skulle man ställa in två identiska (en aktiv och en i olika DC som standby) HAProxy, ProxySQL eller MariaDB Maxscale-instanser och använda Keepalved för att köra Virtual Router Redundancy Protocol (VRRP) mellan dem. VRRP tillhandahåller en virtuell IP-adress till den aktiva lastbalanseraren och överför den virtuella IP-adressen till standby-HAProxy vid fel. Det är sömlöst eftersom de två proxyinstanserna inte behöver något delat tillstånd.

Naturligtvis finns det många saker att tänka på för att göra dina databaser immuna mot datacenterfel.
Rätt planering och automatisering kommer att få det att fungera! Lycka till med klustringen!