Av Ben Slater , produktchef, Instaclustr.
Flytta en levande Apache Cassandra-distribution till en ny plats? Det är naturligt att ha vissa bekymmer, till exempel hur du kan hålla Cassandra-kluster 100% tillgängliga under hela processen. Men faktum är att om din applikation kan vara online under hela anslutningsinställningarna kan den förbli fullt tillgänglig under denna övergång. För extra skydd och sinnesfrid inkluderar följande teknik också en snabb återställningsstrategi för att återgå till din ursprungliga konfiguration, fram till det ögonblick då migreringen är klar.
Här är en rekommenderad ordning för migrering av Cassandra-kluster i sju steg som kommer att undvika driftstopp:
1. Förbered din befintliga miljö.
Först av allt, se till att din applikation använder en datacentermedveten belastningsbalanseringspolicy, såväl som LOCAL_*. Kontrollera också att alla av nyckelrymden som kommer att kopieras över till det nya klustret är inställda på att använda NetworkTopologyStrategy som sin replikeringsstrategi. Det rekommenderas också att alla tangentutrymmen använder denna replikeringsstrategi när de skapas, eftersom det kan bli komplicerat att ändra detta senare.
2. Skapa det nya klustret.
Nu är det dags att skapa det nya klustret som du ska migrera till. Några saker att vara försiktig med här:Se till att det nya klustret och det ursprungliga klustret använder samma Cassandra-version och klusternamn. Dessutom måste det nya datacenternamnet som du använder skilja sig från namnet på det befintliga datacentret.
3. Gå med i klustren tillsammans.
För att göra detta, gör först alla nödvändiga ändringar av brandväggsregeln för att tillåta klustren att anslutas, kom ihåg att vissa ändringar av källklustret också kan vara nödvändiga. Ändra sedan det nya klustrets frönoder – och starta dem. När detta är gjort kommer det nya klustret att vara ett andra datacenter i det ursprungliga klustret.
4. Ändra replikeringsinställningarna.
Därefter, i det befintliga klustret, uppdatera replikeringsinställningarna för nyckelområdena som kommer att kopieras, så att data nu replikeras med det nya datacentret som destination.
5. Kopiera data till det nya klustret.
När klustren är sammanfogade kommer Cassandra att börja replikera skrivningar till det nya klustret. Det är dock fortfarande nödvändigt att kopiera eventuella befintliga data över med nodetool rebuild-funktionen. Det är en bästa praxis att utföra den här funktionen på det nya klustret en eller två noder åt gången, för att inte lägga en överväldigande strömningsbelastning på det befintliga klustret.
6. Ändra programmets anslutningspunkter.
När all användning av återuppbyggnadsfunktionen är klar kommer vart och ett av klustren att innehålla en fullständig kopia av den data som migreras, som Cassandra kommer att synkronisera automatiskt. Det är nu dags att ändra de första anslutningspunkterna för din applikation till noderna i det nya klustret. När detta är klart kommer alla läsningar och skrivningar att betjänas av det nya klustret, och kommer därefter att replikeras i det ursprungliga klustret. Slutligen är det smart att köra en reparationsfunktion över klustret för att säkerställa att all data har replikerats framgångsrikt från originalet.
7. Stäng av originalklustret.
Slutför processen med en liten städning efter migreringen, och ta bort det ursprungliga klustret. Ändra först brandväggsreglerna för att koppla bort det ursprungliga klustret från det nya. Uppdatera sedan replikeringsinställningarna i det nya klustret för att sluta replikera data till det ursprungliga klustret. Slutligen, stäng av det ursprungliga klustret.
Och där har du det:Din Apache Cassandra-distribution har migrerats helt, med noll driftstopp, låg risk och på ett sätt som är helt sömlöst och transparent ur dina slutanvändares perspektiv.
Om författaren
Ben Slater är Chief Product Officer på Instaclustr, en leverantör av företagsklassad, värd och fullt hanterad Apache Cassandra datainfrastruktur med öppen källkod i molnet.