Molnmigrering av databaser: Erfarenheter från verkligheten
När man granskar företagens mjukvaruutveckling under de senaste tjugo åren, framstår en tydlig trend: övergången av databaser till molnet. Under de senaste åren har denna utveckling varit särskilt markant.
Jag har själv varit involverad i flera migreringsprojekt, med fokus på att flytta befintliga lokala databaser till Amazon Web Services (AWS) molndatabaser. Trots att AWS dokumentation kan framställa detta som en enkel process, har jag erfarit att genomförandet inte alltid är smidigt och att projekt kan misslyckas.
I detta inlägg delar jag verkliga erfarenheter kring följande aspekter:
- Källa: Oavsett vilken databaskälla du har (liknande metoder kan användas för de flesta populära databaser), kommer jag främst fokusera på Oracle, som länge varit ett vanligt val i större företag.
- Mål: Måldatabasen är inte specificerad här; metoden fungerar oavsett vilken AWS-databas du väljer.
- Metod: Migreringen kan vara en fullständig uppdatering eller en inkrementell uppdatering. Antingen en batchdataladdning (där käll- och måltillstånd är synkroniserade med fördröjning) eller en (nästan) realtidsdataladdning. Jag kommer att behandla båda.
- Frekvens: Du kan antingen göra en engångsmigrering med efterföljande fullständig övergång till molnet, eller under en övergångsperiod, synkronisera data dagligen mellan din lokala databas och AWS. Den första metoden är enklare, medan den senare är vanligare men också mer komplex. Jag kommer att diskutera båda alternativen.
Problemformulering
Kravet är ofta enkelt formulerat:
Vi vill börja utveckla tjänster i AWS, så vi behöver kopiera all vår data till ”ABC”-databasen, snabbt och enkelt. Vi behöver tillgång till data i AWS omedelbart. Senare ser vi över databasens struktur för att matcha våra behov.
Innan du påbörjar migreringen är det viktigt att reflektera över följande:
- Tänk inte för snabbt ”bara kopiera allt och ta itu med det senare”. Ja, det är det enklaste tillvägagångssättet för en snabb migrering, men det kan leda till grundläggande arkitekturproblem som är mycket svåra att åtgärda i efterhand. Molnmiljön skiljer sig markant från den lokala miljön. Nya tjänster kommer gradvis att introduceras, vilket kommer att påverka användningen av databasen. Att replikera den lokala strukturen 1:1 i molnet är sällan en bra idé, även om det kan fungera i vissa specifika fall.
- Ifågasätt kraven genom att ställa meningsfulla frågor:
- Vilka användare kommer att använda den nya plattformen? Är det transaktionsanvändare (som i den lokala miljön), eller datavetare/dataanalytiker? Eller kommer datan huvudsakligen att användas av tjänster (t.ex. Databricks, Glue, maskininlärningsmodeller)?
- Kommer de befintliga dagliga jobben att finnas kvar efter migreringen, och hur kommer de att förändras?
- Förväntar ni en betydande ökning av datamängden? Detta är ofta en av huvudorsakerna till att migrera till molnet, och er nya datamodell bör vara förberedd för det.
- Fundera över de typiska frågor som användare kommer att ställa till den nya databasen. Det hjälper er att bestämma hur mycket den befintliga datamodellen behöver anpassas för att bibehålla prestanda.
Förbereda Migreringen
När måldatabasen har valts och datamodellen är diskuterad, är nästa steg att utforska AWS Schema Conversion Tool. Det kan användas för att:
- Analysera och extrahera datamodellen från källan. SCT läser den befintliga lokala databasen och genererar en källdatamodell.
- Föreslå en struktur för måldatabasen baserat på vald måldatabas.
- Generera skript för att skapa måldatabasen med den föreslagna datamodellen. Efter att dessa skript körts är molndatabasen redo för dataladdning från den lokala databasen.
Referens: AWS-dokumentation om Schema Conversion Tool
Några tips för att använda Schema Conversion Tool:
För det första bör utdata från verktyget nästan aldrig användas direkt. Se det mer som en referenspunkt för hur du ska anpassa strukturen baserat på din förståelse av datan och hur den kommer att användas i molnet.
För det andra kan tabellerna tidigare ha valts med fokus på korta snabba resultat för specifika områden. I molnet kan datan istället användas för analytiska ändamål. Index som fungerade bra lokalt kan vara oanvändbara i molnet och kan till och med försämra prestandan. Dessutom kan du behöva partitionera data på ett annat sätt än vad som gjordes i källsystemet.
Överväg att göra datatransformationer under migreringen, vilket kan innebära att ändra måldatamodellen för vissa tabeller (så de inte blir 1:1-kopior). Transformationsregler måste sedan implementeras i migreringsverktyget.
Om käll- och måldatabaserna är av samma typ (t.ex. Oracle lokalt vs. Oracle i AWS, PostgreSQL vs. Aurora Postgresql), är det bäst att använda ett dedikerat migreringsverktyg som stöds av databasen (t.ex. export och import av datapumpar, Oracle Goldengate, etc.).
I många fall kommer dock käll- och måldatabaserna inte vara kompatibla. Då är AWS Database Migration Service (DMS) ett bra alternativ.
Referens: AWS-dokumentation om Database Migration Service
AWS DMS tillåter dig att konfigurera uppgifter på tabellnivå, som definierar:
- Källans databas och tabell som ska anslutas till.
- Specifikationer för frågan som används för att hämta data till måltabellen.
- Transformationsregler (om några), som definierar hur källdata ska mappas till måldata (om det inte är 1:1).
- Måldatabasen och tabellen som data ska laddas till.
DMS-uppgifter konfigureras i ett användarvänligt JSON-format.
I det enklaste scenariot räcker det med att köra distributionsskripten i måldatabasen och starta DMS-uppgiften. Men det finns mycket mer att ta hänsyn till.
Engångsmigrering av all data
Det enklaste scenariot är att migrera hela databasen till molnet en gång. Då ser processen i stort sett ut så här:
- Definiera en DMS-uppgift för varje källtabell.
- Säkerställ korrekt konfiguration av DMS-jobben. Detta inkluderar parallellitet, cache-variabler, DMS-serverkonfiguration, storlek på DMS-klustret osv. Denna fas kräver mest tid eftersom det innefattar omfattande tester och finjustering av den optimala konfigurationen.
- Se till att varje måltabell är skapad och tom i den förväntade strukturen.
- Schemalägg ett tidsfönster för datamigreringen. Innan dess, säkerställ (genom prestandatester) att detta tidsfönster är tillräckligt för att slutföra migreringen. Under migreringen kan källdatabasens prestanda vara begränsad. Det förväntas också att källdatabasen inte ändras under migreringen, annars kan data i måldatabasen skilja sig från källdatabasen när migreringen är klar.
Om DMS-konfigurationen är korrekt genomförd, bör inga problem uppstå i detta scenario. Varje källtabell kommer att kopieras till AWS-måldatabasen. Utmaningen är att säkerställa att resurserna är tillräckliga i varje steg så att migreringen inte misslyckas på grund av brist på lagringsutrymme.
Inkrementell daglig synkronisering
Här blir det mer komplicerat. I en idealisk värld skulle allt fungera perfekt hela tiden, men så är sällan fallet.
DMS kan konfigureras i två lägen:
- Full laddning: Det standardläge som beskrivits ovan. DMS-uppgifter startar antingen manuellt eller enligt ett schema. När uppgifterna är klara avslutas DMS-processen.
- Change Data Capture (CDC): I detta läge körs DMS-uppgiften kontinuerligt. DMS övervakar källdatabasen för ändringar på tabellnivå. Om en ändring sker replikeras den omedelbart till måldatabasen enligt DMS-konfigurationen för den aktuella tabellen.
När du väljer CDC måste du dessutom bestämma hur CDC ska hämta förändringarna från källdatabasen.
#1. Oracle Redo Logs Reader
Ett alternativ är att använda Oracles inbyggda redo-loggläsare, som CDC kan använda för att identifiera ändrad data och replikera den till måldatabasen.
Detta kan tyckas som ett självklart val om källan är Oracle, men det finns en nackdel: Oracles redo-loggläsare använder resurser från Oracle-klustret, vilket direkt påverkar alla andra aktiviteter i databasen (det skapar aktiva sessioner).
Ju fler DMS-uppgifter du har (eller ju fler DMS-kluster som körs parallellt), desto mer behöver du skala upp ditt Oracle-kluster, vilket ökar kostnaden för lösningen, särskilt om den dagliga synkroniseringen ska pågå under en längre tid.
#2. AWS DMS Log Miner
Till skillnad från alternativet ovan är detta en inbyggd AWS-lösning. I detta fall påverkar DMS inte Oracle DB direkt. Istället kopieras Oracles redo-loggar till DMS-klustret för bearbetning. Detta sparar resurser i Oracle, men kan vara en långsammare lösning då fler operationer är inblandade. Dessutom kan DMS anpassade läsare vara långsammare än Oracles egen läsare.
Beroende på storleken på källdatabasen och antalet dagliga ändringar, kan du i bästa fall uppnå nästan realtidsinkrementell synkronisering av data från den lokala Oracle-databasen till AWS molndatabas.
I andra fall kommer det inte vara nära realtidssynkronisering, men du kan försöka minska fördröjningen (mellan källa och mål) genom att justera konfigurationen av käll- och målklustren, samt parallellisera uppgifterna, och experimentera med antalet DMS-uppgifter och deras fördelning mellan CDC-instanserna.
Det är också viktigt att förstå vilka ändringar i källtabellerna som stöds av CDC (t.ex. tillägg av en kolumn), eftersom inte alla ändringar stöds. I vissa fall kan du behöva ändra måltabellen manuellt och starta om CDC-uppgiften (vilket kan leda till förlust av befintlig data i måldatabasen).
När saker och ting går fel
Jag har lärt mig den hårda vägen att det finns ett specifikt scenario med DMS där löftet om daglig replikering är svårt att uppnå.
DMS bearbetar redo-loggar med en viss hastighet. Det spelar ingen roll om det finns flera instanser av DMS som utför uppgifterna. Varje DMS-instans läser redo-loggarna med en viss hastighet och måste läsa alla loggar. Denna begränsning gäller både Oracle redo logs reader och AWS log miner.
Om källdatabasen har en stor mängd ändringar per dag som resulterar i stora redo-loggar (500 GB+), kommer CDC helt enkelt inte att fungera. Replikeringen kommer inte att slutföras före dagens slut. Det obearbetade arbetet kommer att skjutas fram till nästa dag, där en ny uppsättning ändringar redan väntar. Mängden obearbetad data ökar för varje dag.
I det här specifika fallet var CDC inte ett alternativ (efter många prestandatester). Det enda sättet att säkerställa att alla förändringar från den aktuella dagen replikerades samma dag, var att göra på följande sätt:
- Separera stora tabeller som inte används ofta och replikera dem en gång i veckan (t.ex. under helgerna).
- Konfigurera replikering av mindre, men ändå stora, tabeller genom att dela upp dem mellan flera DMS-uppgifter. En tabell migrerades av 10 eller fler separata DMS-uppgifter parallellt, där data uppdelningen var distinkt (anpassad kod var nödvändig) och de kördes dagligen.
- Lägg till fler (upp till 4 i detta fall) DMS-instanser och fördela DMS-uppgifterna jämnt mellan dem, inte bara baserat på antalet tabeller, utan även på storleken.
I grund och botten användes DMS i full load-läge för att replikera den dagliga datan, vilket var det enda sättet att uppnå datareplikering samma dag.
Det är inte en perfekt lösning, men den fungerar fortfarande bra även efter många år. Så kanske är det inte en så dålig lösning trots allt. 😃