Arkitektur: hur replikeringsinstansen fungerar

DMS arkitektur är treskalig:

Nätverkskrav

Replikeringsinstansen placeras i en VPC. Om källdatabasen ligger on-prem behöver du antingen AWS Direct Connect eller VPN-tunnel. I vår erfarenhet är nätverkslatens och bandbredd de vanligaste flaskhalsarna – inte DMS i sig. En databas på 500 GB kan ta timmar eller dagar beroende på om du har 1 Gbps Direct Connect eller en 100 Mbps VPN.

Rekommendation: Kör alltid ett nätverkstest innan du dimensionerar tidsplanen. Vi använder iperf3 mellan on-prem och replikeringsinstansen för att mäta faktisk throughput.

Dimensionering av replikeringsinstansen

Underdimensionering är det vanligaste felet. AWS rekommenderar att börja med dms.r5.large för medelstora migreringar, men för produktionsdatabaser med tungt transaktionsflöde behöver du ofta dms.r5.xlarge eller större. Minnesanvändningen stiger snabbt vid LOB-kolumner (Large Objects) och hög CDC-volym.

Migreringstyper: full load, CDC och kombinationen

Full load

Kopierar all befintlig data från källa till mål. Snabbt och rakt på sak för mindre databaser eller engångsmigreringar där du kan acceptera ett längre driftfönster.

CDC (Change Data Capture)

Fångar löpande förändringar i källdatabasen efter att full load är klar. DMS läser transaktionsloggar (redo logs i Oracle, WAL i PostgreSQL, binlog i MySQL) och replikerar INSERT, UPDATE och DELETE till målet. Detta är nyckeln till nära noll driftstopp.

Full load + CDC (rekommenderat)

Den vanligaste metoden i produktion. Sekvensen:

1. Full load kopierar all befintlig data

2. CDC aktiveras och börjar fånga förändringar som skett under full load

3. Måldatabasen hinner ikapp (replication lag → 0)

4. Cutover: applikationen pekas om till måldatabasen under ett kontrollerat fönster

Opsio-perspektiv: Vi planerar alltid cutover till nätter eller helger, men det faktiska driftstoppet behöver bara vara minuter om CDC har hunnit ikapp. Det kritiska steget är att verifiera att replikeringslagget är noll och att applikationens skrivningar pausas under cutover.

Heterogen migrering med Schema Conversion Tool

Vid byte av databasmotor – exempelvis från Oracle till Aurora PostgreSQL – räcker inte DMS ensamt. Du behöver AWS SCT för att:

• Konvertera DDL-scheman (tabeller, vyer, index)
• Konvertera lagrade procedurer, funktioner och triggers
• Identifiera kod som inte kan konverteras automatiskt (SCT markerar dessa med färgkodning)

SCT genererar en assessment report som visar hur stor andel av databasens objekt som kan konverteras automatiskt. I verkligheten, baserat på vad vi ser hos Opsios kunder, ligger automatisk konvertering oftast på 70–90 % för scheman men betydligt lägre för komplex affärslogik i lagrade procedurer.

Förmigreringsfasen – där projektet faktiskt avgörs

De flesta misslyckade migreringar vi analyserar i Opsios SOC/NOC har en gemensam nämnare: otillräcklig förberedelse. Här är den checklista vi kör:

1. Inventering och beroendekartläggning

Vilka applikationer läser från och skriver till databasen? Finns replikering till andra system? Har ni CDC-beroenden i befintlig miljö (ETL-flöden, rapportdatabaser)?

2. Premigration assessment i DMS

DMS har en inbyggd assessmentfunktion som identifierar potentiella problem: datatyper utan direkt motsvarighet, teckenuppsättningsproblem, LOB-begränsningar. Kör detta tidigt.

3. Nätverks- och prestandatest

Som nämnts: mät faktisk throughput. Dimensionera tidsplanen baserat på verkliga siffror, inte AWS marknadsföringsmaterial.

4. Rollback-plan

Om något går fel under cutover – hur snabbt kan ni gå tillbaka? Vi rekommenderar att ha CDC igång i båda riktningarna under en övergångsperiod, alternativt att behålla källdatabasen intakt i minst en vecka efter cutover.

5. Validering

DMS erbjuder data validation som jämför rader mellan källa och mål. Komplettera med applikationsnivåtester – automatiserade regressionstester mot den nya databasen innan ni öppnar för produktion.

Vanliga fallgropar vi ser i produktion

LOB-kolumner som saktar ner allt. DMS hanterar Large Objects i "limited LOB mode" som standard, vilket trunkerar data. Full LOB mode behåller all data men är drastiskt långsammare. Lösningen: använd "limited LOB mode" med en tillräckligt hög maxstorlek, baserat på analys av era faktiska LOB-storlekar.

Teckenkodningskonflikter. Migreringar från äldre SQL Server-instanser med Latin1 till PostgreSQL med UTF-8 kan ge oväntade konverteringsfel. Testa med en representativ delmängd data först.

Indexåterskapande under full load. DMS rekommenderar att skapa index efter full load för bättre prestanda. Missar du detta kan full load ta flera gånger längre.

Underdimensionerad replikeringsinstans. Symtom: ökande replication lag, hög minnesanvändning, task failures. Lösning: övervaka CloudWatch-metriker (CDCLatencyTarget, MemoryUsage) och skala upp proaktivt.

DMS i en bredare migreringsstrategi

DMS är ett verktyg – inte en strategi. En komplett databasmigrering till AWS involverar:

• Beslut om databasmotor: Ska ni behålla Oracle eller byta till Aurora? Licensbesparingar vs. omskrivningskostnader.
• Miljöarkitektur: Multi-AZ för hög tillgänglighet, Read Replicas för läsprestanda, kryptering med KMS.
• Compliance: Om ni hanterar personuppgifter behöver ni säkerställa GDPR-efterlevnad. Aurora i eu-north-1 (Stockholm) ger data residency inom Sverige. Molnsäkerhet och compliance
• FinOps: RDS Reserved Instances eller Aurora Serverless v2 beroende på användningsmönster. Cloud FinOps

Enligt AWS Well-Architected Framework bör databasmigrering ingå i den bredare pilaren Operational Excellence, med fokus på observability, automatiserad drift och kontinuerlig förbättring.

Komplett molnmigrering

När DMS inte räcker

DMS fungerar utmärkt för relationsdatabaser och enklare NoSQL-migreringar. Men det finns scenarier där alternativa verktyg eller tillvägagångssätt är bättre:

• Mycket stora databaser (10+ TB): Överväg AWS Snowball Edge för initial datainläsning, sedan DMS CDC för att synka förändringar.
• Komplexa ETL-transformationer: AWS Glue eller egna Spark-pipelines ger mer kontroll.
• Mainframe-migreringar: Specialistverktyg och ofta manuell omskrivning.
• Databaskonsolidering: Om ni slår samman tio databaser till en behövs mer arkitekturarbete än vad DMS kan lösa.

Managerade molntjänster

Steg-för-steg: en typisk DMS-migrering

1. Skapa replikeringsinstans i rätt VPC med tillräcklig storlek

2. Konfigurera källändpunkt – testa anslutningen

3. Konfigurera måländpunkt – testa anslutningen

4. Kör premigration assessment

5. Skapa migreringsuppgift – välj full load + CDC

6. Starta och övervaka via DMS Console och CloudWatch

7. Verifiera data med DMS validation och applikationstester

8. Cutover när replication lag = 0 och validering godkänd

9. Övervakningsperiod – behåll replikeringen igång tills ni är säkra

10. Avveckla källdatabasen och replikeringsinstansen

Vanliga frågor

Vilka databaser stöder AWS DMS?

AWS DMS stöder bland annat Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, Amazon Aurora, Amazon Redshift, SAP ASE, MongoDB och Amazon S3 som källa eller mål. Listan uppdateras löpande – kontrollera alltid AWS officiella dokumentation för senaste kompatibilitetsstatus.

Vad är skillnaden mellan full load och CDC i AWS DMS?

Full load kopierar all befintlig data i ett svep. CDC (Change Data Capture) fångar sedan löpande förändringar i källdatabasen och replikerar dem till målet. De kombineras vanligen: full load först, sedan CDC för att hålla databaserna synkroniserade fram till cutover.

Hur minimerar jag driftstopp vid databasmigrering?

Använd full load + CDC så att måldatabasen hinner ikapp. Planera cutover-fönstret till en lågtrafiktid, validera data med DMS premigration assessment och ha en rollback-plan redo. Realistiskt landar du på minuter snarare än timmar om förberedelserna är gjorda.

Behöver jag AWS Schema Conversion Tool om källa och mål är samma databasmotor?

Nej. SCT behövs bara vid heterogena migreringar – exempelvis Oracle till PostgreSQL. Vid homogena migreringar (MySQL till MySQL, PostgreSQL till Aurora PostgreSQL) hanterar DMS schemat direkt.

Vad kostar AWS DMS?

Du betalar per timme för den replikeringsinstans du väljer, plus eventuell dataöverföringskostnad. Det finns ett free-tier-erbjudande för nya kunder. Kostnaden varierar kraftigt beroende på instansstorlek, datavolym och migreringsvaraktighet – använd AWS Pricing Calculator för en uppskattning.