AWS Database Migration Service is een cloudservice die relationele databases, NoSQL-databases, datawarehouses en alle andere soorten gegevensopslag efficiënt en veilig migreert naar AWS Cloud of tussen cloud- en on-premises setups. DMS ondersteunt verschillende soorten bron- en doeldatabases zoals Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift en S3, enz.
Waarnemingen tijdens de gegevensmigratie
We hebben gewerkt aan het ontwerpen en creëren van een AWS S3 datameer en datawarehouse in AWS Redshift met de gegevensbronnen van on-premises voor Oracle, MS SQL Server, MySQL, Postgres SQL en MongoDB voor relationele databases. We hebben AWS DMS gebruikt voor de initiële volledige lading en dagelijkse incrementele gegevensoverdracht van deze bronnen naar AWS S3.
Met deze reeks berichten wil ik de verschillende uitdagingen uitleggen die zijn ondervonden tijdens de daadwerkelijke gegevensmigratie met verschillende relationele databases.
1. Gewijzigde datum niet correct ingevuld bij de bron
AWS DMS wordt gebruikt voor volledige lading en het vastleggen van gewijzigde gegevens uit bron-databases. AWS DMS legt gewijzigde records vast op basis van de transactielogs, maar een juist bijgewerkte gewijzigde datumkolom kan helpen bij het toepassen van deduplicatielogica en het extraheren van het laatst gewijzigde record voor een gegeven rij op het doel in S3.
Indien gewijzigde gegevens niet beschikbaar zijn voor een tabel of niet correct bijgewerkt zijn, biedt AWS DMS een optie van transformatieregels om een nieuwe kolom toe te voegen bij het extraheren van gegevens uit de brondatabase. Hier helpt deAR_H_CHANGE_SEQ header om een nieuwe kolom toe te voegen met een waarde als een uniek toenemend nummer uit de brondatabase, dat bestaat uit een tijdstempel en een automatisch toenemend nummer.
Het onderstaande codevoorbeeld voegt een nieuwe kolom toe als DMS_CHANGE_SEQ
aan het doel, die een uniek toenemend nummer uit de bron heeft. Dit is een 35-cijferig uniek nummer met de eerste 16 cijfers voor de tijdstempel en de volgende 19 cijfers voor het record-ID-nummer dat incrementeel is in de database.
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value": "DMS_CHANGE_SEQ",
"expression": "$AR_H_CHANGE_SEQ",
"data-type": {
"type": "string",
"length": 100
}
}
2. Supplemental Logging inschakelen voor Oracle als bron
Voor Oracle als brondatabase, om doorlopende wijzigingen vast te leggen, moet AWS DMS minimale supplemental logging inschakelen op de brondatabase. Hierdoor wordt aanvullende informatie en kolommen toegevoegd aan de redo-logs om de wijzigingen bij de bron te identificeren.
Supplemental logging kan worden ingeschakeld voor primaire, unieke sleutels, sets van kolommen of alle kolommen. Supplemental logging voor alle kolommen legt alle kolommen voor de tabellen in de brondatabase vast en helpt om de volledige records in de doel-AWS S3-laag te overschrijven.
Het aanvullend loggen van alle kolommen zal de grootte van de redo-logs vergroten, aangezien alle kolommen van de tabel worden gelogd in de logs. Men moet de redo- en archivelogs dienovereenkomstig configureren om extra informatie hierin op te nemen.
3. Netwerkbandbreedte tussen bron- en doeldatabases
De initiële volledige belasting van de on-premises bronnen voor Oracle, MS SQL Server, enz., verliep goed en ook de veranderde gegevenscaptatie werkte meestal prima.
Er waren meestal een redelijk aantal transacties gedurende de dag in een gegeven maand, behalve tijdens het eind-van-de-dag proces, dagelijks na middernacht en maandelijkse activiteiten aan het einde van de maand. We hebben opgemerkt dat DMS migratietaken uit synchronisatie liepen of mislukten gedurende deze tijd.
We hebben de metingen van de bron, doel en replicatie-instantie in de logs bekeken en de volgende observaties gedaan:
- CDCLatencySource – het gat, in seconden, tussen het laatste gebeurtenis dat is vastgelegd vanaf het bron-eindpunt en de huidige systeemtijdstempel van de AWS DMS-instantie.
- CDCIncomingchanges – het totale aantal veranderingsevenementen op een bepaald moment die wachten om toegepast te worden op het doel. Dit neemt toe van nul tot duizenden tijdens reconciliatieactiviteiten in de vroege ochtend.
- CDCLatencySource – het tijdsverschil, in seconden, tussen het laatste vastgelegde evenement vanaf het brondeindpunt en de actuele systeemtijdstempel van de AWS DMS-instantie. Dit loopt op van nul tot enkele duizenden tot 10-12K seconden tijdens dagelijkse verzoeningsactiviteiten na middernacht. Deze waarde liep op tot 40K tijdens activiteiten aan het einde van de maand.
Na verdere loganalyse en het bekijken van andere statistieken, hebben we vastgesteld dat:
De AWS DMS-statistieken NetworkReceiveThroughput dienen om het inkomende verkeer naar de DMS-replicatie-instantie te begrijpen voor zowel de klantendatabase als het DMS-verkeer. Deze statistieken helpen bij het begrijpen van eventuele netwerkgerelateerde problemen tussen de brondatabase en de DMS-replicatie-instantie.
Er werd waargenomen dat de netwerk ontvangsthoeveelheid tot 30 MB/s was, d.w.z. 250 Mb/s, als gevolg van de VPN-verbinding tussen de bron en AWS, die ook werd gedeeld voor andere toepassingen.
De uiteindelijke conclusie van dit probleem is dat connectiviteit tussen bron- en doeldatabases cruciaal is voor een succesvolle gegevensoverdracht. Zorg ervoor dat er voldoende bandbreedte is ingesteld tussen on-premises of andere cloudbronnen van databases en de AWS-omgeving voordat de daadwerkelijke gegevensoverdracht plaatsvindt.
- Een VPN-tunnel zoals AWS Site-to-Site VPN of Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS) kan een doorvoer bieden tot 1,25 Gbps. Dit zou voldoende zijn voor migratie van kleine tabellen of tabellen met minder DML-verkeersmigratie.
- Voor grote gegevensmigraties met zware transacties per seconde op de tabellen, moet u AWS Direct Connect overwegen. Het biedt een optie om een toegewijde privéverbinding te creëren met ondersteuning voor bandbreedtes van 1 Gbps, 10 Gbps, enz.
Conclusie
Dit is Deel I van de serie met meerdere delen voor demigratie van relationele databases uitdagingen met behulp van AWS DMS en de geïmplementeerde oplossingen. De meeste van deze uitdagingen die in deze serie worden genoemd, kunnen zich voordoen tijdens het database migratieproces en deze oplossingen kunnen worden geraadpleegd.
Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment