Cloud Disaster Recovery til MariaDB og MySQL

MySQL har en lang tradition inden for geografisk replikering. Distribution af klynger til fjerntliggende datacentre reducerer virkningerne af geografisk latens ved at skubbe data tættere på brugeren. Det giver også mulighed for gendannelse efter katastrofe. På grund af de betydelige omkostninger ved at duplikere hardware på et separat websted, var der ikke mange virksomheder, der tidligere havde råd til det. En anden omkostning er dygtigt personale, der er i stand til at designe, implementere og vedligeholde et sofistikeret miljø med flere datacentre.

Med Cloud og DevOps automatiseringsrevolutionen har det aldrig været mere tilgængeligt for masserne at have distribueret datacenter. Cloud-udbydere øger rækken af ​​tjenester, de tilbyder til en bedre pris. Man kan bygge cross-cloud, hybride miljøer med data spredt over hele verden. Man kan lave fleksible og skalerbare DR-planer for at nærme sig en bred vifte af disruptionsscenarier. I nogle tilfælde kan det bare være en sikkerhedskopi, der er gemt offsite. I andre tilfælde kan det være en 1 til 1 kopi af et produktionsmiljø, der kører et andet sted.

I denne blog vil vi tage et kig på nogle af disse tilfælde og behandle almindelige scenarier.

Lagring af sikkerhedskopier i skyen

En DR-plan er en generel betegnelse, der beskriver en proces til at genoprette forstyrrede it-systemer og andre kritiske aktiver, som en organisation bruger. Backup er den primære metode til at opnå dette. Når en sikkerhedskopi er i samme datacenter som dine produktionsservere, risikerer du, at alle data kan blive slettet i tilfælde af, at du mister dette datacenter. For at undgå det bør du have politikken til at oprette en kopi et andet fysisk sted. Det er stadig en god praksis at opbevare en sikkerhedskopi på disken for at reducere den tid, det tager at gendanne. I de fleste tilfælde vil du beholde din primære backup i det samme datacenter (for at minimere gendannelsestiden), men du bør også have en backup, der kan bruges til at gendanne forretningsprocedurer, når det primære datacenter er nede.

ClusterControl giver mulighed for problemfri integration mellem dit databasemiljø og skyen. Det giver muligheder for at migrere data til skyen. Vi tilbyder en komplet kombination af database backups til Amazon Web Services (AWS), Google Cloud Services eller Microsoft Azure. Sikkerhedskopier kan nu udføres, planlægges, downloades og gendannes direkte fra din valgte cloud-udbyder. Denne evne giver øget redundans, bedre muligheder for gendannelse af katastrofer og fordele i både ydeevne og omkostningsbesparelser.

Det første skridt til at konfigurere "datacenterfejl - bevissikkerhedskopiering" er at give legitimationsoplysninger til din cloud-operatør. Du kan vælge mellem flere leverandører her. Lad os tage et kig på processen, der er sat op for den mest populære cloud-operatør - AWS.

Alt du behøver er AWS Key ID og hemmeligheden for den region, hvor du vil gemme din backup. Du kan få det fra AWS-konsollen. Du kan følge et par trin for at få det.

1. Brug din AWS-kontos e-mailadresse og adgangskode til at logge ind på AWS Management Console som AWS-kontoens root-bruger.
2. På IAM Dashboard-siden skal du vælge dit kontonavn i navigationslinjen og derefter vælge Mine sikkerhedsoplysninger .
3. Hvis du ser en advarsel om adgang til sikkerhedsoplysningerne for din AWS-konto, skal du vælge Fortsæt til sikkerhedsoplysningerne .
4. Udvid sektionen Adgangsnøgler (adgangsnøgle-id og hemmelig adgangsnøgle).
5. Vælg at Opret ny adgangsnøgle . Vælg derefter Download nøglefil for at gemme adgangsnøgle-id'et og den hemmelige adgangsnøgle til en fil på din computer. Når du har lukket dialogboksen, vil du ikke være i stand til at hente denne hemmelige adgangsnøgle igen.

Når alt er indstillet, kan du justere din backup tidsplan og aktivere backup til cloud-indstillingen. For at reducere netværkstrafikken skal du sørge for at aktivere datakomprimering. Det gør sikkerhedskopier mindre og minimerer den nødvendige tid til upload. En anden god praksis er at kryptere sikkerhedskopien. ClusterControl opretter automatisk en nøgle og bruger den, hvis du beslutter dig for at gendanne den. Avancerede sikkerhedskopieringspolitikker bør have forskellige opbevaringstider for sikkerhedskopier, der er gemt på servere i det samme datacenter, og sikkerhedskopier, der er gemt på en anden fysisk placering. Du bør indstille en længere opbevaringsperiode for skybaserede sikkerhedskopier og kortere periode for sikkerhedskopier, der er gemt i nærheden af ​​produktionsmiljøet, da sandsynligheden for gendannelse falder med sikkerhedskopieringens levetid.

Udvid din klynge med asynkron replikering

Galera med asynkron replikering kan være en fremragende løsning til at bygge en aktiv DR-node i et fjerndatacenter. Der er et par gode grunde til at knytte en asynkron slave til en Galera Cluster. Længerevarende forespørgsler af OLAP-typen på en Galera-node kan gøre en hel klynge langsommere. Med muligheden for forsinket anvendelse kan forsinket replikering redde dig fra menneskelige fejl, så alle disse gyldne indtastninger vil ikke straks blive anvendt på din backup-knude.

I ClusterControl udføres udvidelsen af ​​en Galera-nodegruppe med asynkron replikering i en enkelt side-guide. Du skal give de nødvendige oplysninger om din fremtidige eller eksisterende slaveserver. Slaven vil blive sat op fra en eksisterende backup eller en nystreamet XtraBackup fra masteren til slaven.

Load Balancers i Multi-Datacenter

Load balancers er en afgørende komponent i MySQL og MariaDB database høj tilgængelighed. Det er ikke nok at have en klynge, der spænder over flere datacentre. Du har stadig brug for dine tjenester for at få adgang til dem. En fejl i en load balancer, der er tilgængelig i ét datacenter, vil gøre hele dit miljø utilgængeligt.

En af de populære metoder til at skjule kompleksiteten af ​​databaselaget fra en applikation er at bruge en proxy. Proxyer fungerer som et indgangspunkt til databaserne, de sporer databasenodernes tilstand og bør altid lede trafik til kun de noder, der er tilgængelige. ClusterControl gør det nemt at implementere og konfigurere flere forskellige belastningsbalanceringsteknologier til MySQL og MariaDB, herunder ProxySQL, HAProxy, med en peg-og-klik grafisk grænseflade.

Det gør det også muligt at gøre denne komponent overflødig ved at tilføje keepalive oven på den. For at forhindre dine belastningsbalancere i at være et enkelt fejlpunkt, ville man opsætte to identiske (en aktiv og en i forskellige DC som standby) HAProxy, ProxySQL eller MariaDB Maxscale instanser og bruge Keepalved til at køre Virtual Router Redundancy Protocol (VRRP) mellem dem. VRRP giver en virtuel IP-adresse til den aktive load balancer og overfører den virtuelle IP til standby-HAProxy i tilfælde af fejl. Det er problemfrit, fordi de to proxy-instanser ikke behøver nogen delt tilstand.

Selvfølgelig er der mange ting at overveje for at gøre dine databaser immune over for datacenterfejl.
Korrekt planlægning og automatisering vil få det til at fungere! Glædelig klyngedannelse!