I dag er det ret almindeligt at have en database replikeret i en anden server/datacenter, og det er også et must i nogle tilfælde. Der er forskellige grunde til at replikere dine databaser til et helt separat miljø.
- Migrer til et andet datacenter.
- Opgraderingskrav (hardware/software).
- Oprethold et fuldt synkroniseret driftssystem på et Disaster Recovery-websted (DR), der kan tage over til enhver tid
- Behold en slavedatabase som en del af en DR-plan med lavere omkostninger.
- For krav til geo-placering (data skal være lokalt i et specifikt land).
- Hav et testmiljø.
- Formål med fejlfinding.
- Rapporteringsdatabase.
Og der er forskellige måder at udføre denne replikeringsopgave på:
- Sikkerhedskopiering/gendannelse :Sikkerhedskopiering af en produktionsdatabase og gendannelse af den i en ny server/miljø er den klassiske måde at gøre dette på, men det er også en gammeldags måde, da du ikke vil holde dine data opdaterede, og du skal vente for hver gendannelsesproces, hvis du har brug for nogle nyere data. Hvis du har en klynge (master-slave, multi-master), og hvis du vil genskabe den, bør du gendanne den indledende backup og derefter genskabe resten af noderne, hvilket kan være en tidskrævende opgave.
- Klonklynge :Den ligner den forrige, men backup- og gendannelsesprocessen er for hele klyngen, ikke kun én specifik databaseserver. På denne måde kan du klone hele klyngen i den samme opgave, og du behøver ikke at genskabe resten af noderne manuelt. Denne metode har stadig problemet med at holde data opdateret mellem kloner.
- Replikering :Denne måde inkluderer muligheden for sikkerhedskopiering/gendannelse, men efter den indledende gendannelse vil replikeringsprocessen holde dine data synkroniseret med masternoden. På denne måde, hvis du har en databaseklynge, skal du gendanne sikkerhedskopien til én node og genskabe alle noderne manuelt.
I denne blog vil vi se en ny ClusterControl 1.7.4-funktion, der giver dig mulighed for at bruge en blanding af den metode, som vi nævnte tidligere, til at forbedre denne opgave.
Hvad er klynge-til-klynge-replikering?
Replikering mellem to klynger er ikke det samme som at udvide en klynge til at køre på tværs af to datacentre. Når vi opsætter replikering mellem to klynger, har vi faktisk 2 separate systemer, der kan fungere autonomt. Replikering bruges til at holde dem synkroniseret, så slavesystemet har en opdateret tilstand og kan tage over.
Fra ClusterControl 1.7.4 er det muligt at oprette en ny klynge ved direkte at klone en kørende kildeklynge eller ved at bruge en nylig sikkerhedskopi af kildeklyngen.
Efter kloning af klyngen vil du have en Slave Cluster (SC), der modtager data, og en Master Cluster (MC) sender ændringer til den slave.
ClusterControl understøtter Cluster-to-Cluster-replikering for følgende klyngetyper:
- Percona XtraDB Cluster version 5.6.x og nyere.
- MariaDB Galera Cluster version 10.x og nyere.
- PostgreSQL 9.6 og nyere.
Klynge-til-klynge-replikering for Percona XtraDB / MariaDB Galera-klynge
For MySQL-baserede motorer kræves GTID for at bruge denne funktion, og asynkron replikering mellem Master- og Slave-klyngen vil blive brugt.
Der er et par handlinger, der skal udføres for at forberede den aktuelle klynge til dette job. Først skal mindst én node på den aktuelle klynge have de binære logfiler aktiveret. Derefter skal du tilføje backupbrugeren, der er konfigureret i databasenoden i ClusterControl-konfigurationsfilen, som vil blive brugt til administrationsopgaver. Alle disse handlinger kan udføres ved at bruge ClusterControl UI eller ClusterControl CLI.
Nu er du klar til at oprette Percona XtraDB/MariaDB Galera Cluster-to-Cluster-replikation. Når jobbet er færdigt, har du:
- Én node i slaveklyngen vil replikere fra én node i masterklyngen.
- Replikeringen vil være tovejsbestemt mellem klyngerne.
- Alle noder i slaveklyngen vil som standard være skrivebeskyttet. Det er muligt at deaktivere skrivebeskyttet flag på noderne én efter én.
- Active-Active clustering anbefales kun, hvis applikationer kun berører usammenhængende datasæt på en af klyngene, da motoren ikke tilbyder nogen konfliktdetektion eller -løsning.
Fra både ClusterControl UI eller ClusterControl CLI vil du være i stand til:
- Opret denne replikeringsklynge.
- Aktiver Active-Active-konfigurationen.
- Skift klyngetopologien.
- Genopbyg en replikeringsklynge.
- Stop/start en replikeringsslave.
- Nulstil replikeringsslave (kun implementeret ved hjælp af ClusterControl CLI atm).
Overvejelser
- Sikkerhedskopieringsbrugeren skal tilføjes manuelt i ClusterControl-konfigurationsfilen.
- Sikkerhedskopieringsbrugerlegitimationsoplysningerne skal være de samme i både den nuværende og nye klynge.
- MySQL root-adgangskoden, der blev angivet ved oprettelse af slaveklyngen, skal være den samme som root-adgangskoden, der bruges på masterklyngen.
Kendte begrænsninger
- Automatisk failover er ikke understøttet endnu. Hvis masteren fejler, er det administratorens ansvar at failover til en anden master.
- Det er kun muligt at "NULSTILLE" en replikeringsslave fra ClusterControl CLI'en, da den endnu ikke er implementeret i ClusterControl UI.
- Det er kun muligt at genopbygge en klynge, der er i skrivebeskyttet tilstand. Alle noder i en klynge skal være skrivebeskyttet for at tælle som skrivebeskyttet klynge.
Klynge-til-klynge-replikering til PostgreSQL
ClusterControl Cluster-to-Cluster-replikering understøttes på PostgreSQL ved hjælp af streaming-replikering.
Som et krav skal der være en PostgreSQL-server med ClusterControl-rollen 'master', og når du opsætter slaveklyngen, skal administratoroplysningerne være identiske med masterklyngen.
Nu er du klar til at oprette PostgreSQL Cluster-to-Cluster-replikeringen. Når jobbet er færdigt, har du:
- Én node i slaveklyngen vil replikere fra én node i masterklyngen.
- Replikeringen vil være ensrettet mellem klyngerne.
- Knuden i slaveklyngen vil være skrivebeskyttet.
Fra både ClusterControl UI eller ClusterControl CLI vil du være i stand til:
- Opret denne replikeringsklynge.
- Genopbyg en replikeringsklynge.
- Stop/start en replikeringsslave.
Overvejelse
- Administratorlegitimationsoplysningerne skal være identiske i master- og slaveklyngen.
Kendte begrænsninger
- Den maksimale størrelse af slaveklyngen er én node.
- Slaveklyngen kan ikke iscenesættes fra en sikkerhedskopi.
- Topologiændringer understøttes ikke.
- Kun envejsreplikering understøttes.
Konklusion
Ved at bruge denne nye ClusterControl-funktion behøver du ikke udføre hvert trin for at oprette en Cluster-replikering separat eller manuelt, og som et resultat af at bruge det, vil du spare tid og kræfter. Prøv det!