Af Ben Slater , Chief Product Officer, Instaclustr.
Flytter du en live Apache Cassandra-implementering til en ny placering? Det er naturligt at have nogle bekymringer, såsom hvordan du kan holde Cassandra-klynger 100% tilgængelige under hele processen. Men faktum er, at hvis din applikation er i stand til at forblive online under ændringer af forbindelsesindstillinger, kan den forblive fuldt tilgængelig under denne overgang. For ekstra beskyttelse og ro i sindet inkluderer følgende teknik også en hurtig rollback-strategi for at vende tilbage til din oprindelige konfiguration, indtil det øjeblik, hvor migreringen er fuldført.
Her er en anbefalet syv-trins Cassandra-klynge-migreringsrækkefølge, der vil undgå enhver nedetid:
1. Gør dit eksisterende miljø klar.
Først og fremmest skal du sørge for, at din applikation bruger en datacenter-bevidst belastningsbalanceringspolitik samt LOCAL_*. Tjek også, at alle af de nøglerum, der vil blive kopieret over til den nye klynge, er indstillet til at bruge NetworkTopologyStrategy som deres replikeringsstrategi. Det anbefales også, at alle nøglerum bruger denne replikeringsstrategi, når de oprettes, fordi det kan blive kompliceret at ændre dette senere.
2. Opret den nye klynge.
Nu er det tid til at oprette den nye klynge, som du vil migrere til. Et par ting, du skal være opmærksom på her:Sørg for, at den nye klynge og den originale klynge bruger den samme Cassandra-version og klyngenavn. Det nye datacenternavn, du bruger, skal også være forskelligt fra navnet på det eksisterende datacenter.
3. Slut dig til klyngerne sammen.
For at gøre dette skal du først foretage eventuelle nødvendige firewall-regelændringer for at tillade klyngerne at blive forbundet, og husk at nogle ændringer af kildeklyngen også kan være nødvendige. Skift derefter den nye klynges frøknuder - og start dem. Når dette er gjort, vil den nye klynge være et andet datacenter i den oprindelige klynge.
4. Skift replikeringsindstillingerne.
Dernæst skal du i den eksisterende klynge opdatere replikeringsindstillingerne for de nøglerum, der vil blive kopieret, så data nu vil blive replikeret med det nye datacenter som destination.
5. Kopier dataene til den nye klynge.
Når klyngerne er sat sammen, vil Cassandra begynde at replikere skrivninger til den nye klynge. Det er dog stadig nødvendigt at kopiere eksisterende data over med nodetool-genopbygningsfunktionen. Det er en bedste praksis at udføre denne funktion på den nye klynge en eller to noder ad gangen for ikke at placere en overvældende streamingbelastning på den eksisterende klynge.
6. Skift applikationens forbindelsespunkter.
Efter al brug af genopbygningsfunktionen er fuldført, vil hver af klyngerne indeholde en komplet kopi af de data, der migreres, som Cassandra automatisk vil holde synkroniseret. Det er nu tid til at ændre de indledende forbindelsespunkter for din applikation til noderne i den nye klynge. Når dette er afsluttet, vil alle læsninger og skrivninger blive serveret af den nye klynge, og efterfølgende vil blive replikeret i den originale klynge. Endelig er det smart at køre en reparationsfunktion på tværs af klyngen for at sikre, at alle data er blevet replikeret med succes fra originalen.
7. Luk den originale klynge ned.
Fuldfør processen med en lille oprydning efter migreringen, og fjern den originale klynge. Først skal du ændre firewall-reglerne for at frakoble den originale klynge fra den nye. Opdater derefter replikeringsindstillingerne i den nye klynge for at stoppe replikering af data til den oprindelige klynge. Til sidst skal du lukke den originale klynge ned.
Og der har du det:Din Apache Cassandra-implementering er blevet fuldt migreret, med ingen nedetid, lav risiko og på en måde, der er fuldstændig problemfri og gennemsigtig fra dine slutbrugeres perspektiv.
Om forfatteren
Ben Slater er Chief Product Officer hos Instaclustr, en udbyder af virksomhedsgrad, hostet og fuldt administreret Apache Cassandra open source-datainfrastruktur i skyen.