Når du ser på bedriftens programvareutvikling fra første rad i to tiår, er den ubestridelige trenden de siste årene klar – å flytte databaser inn i skyen.
Jeg var allerede involvert i noen få migrasjonsprosjekter, der målet var å bringe den eksisterende lokale databasen inn i Amazon Web Services (AWS) Cloud-database. Mens du fra AWS-dokumentasjonsmaterialet vil lære hvor enkelt dette kan være, er jeg her for å fortelle deg at gjennomføringen av en slik plan ikke alltid er enkel, og det er tilfeller der den kan mislykkes.
I dette innlegget vil jeg dekke den virkelige opplevelsen for følgende tilfelle:
- Kilden: Selv om det i teorien egentlig ikke spiller noen rolle hva kilden din er (du kan bruke en veldig lik tilnærming for de fleste av de mest populære DB-ene), var Oracle det foretrukne databasesystemet i store bedrifter i mange år, og det er der fokuset mitt vil være.
- Målet: Ingen grunn til å være spesifikk på denne siden. Du kan velge hvilken som helst måldatabase i AWS, og tilnærmingen vil fortsatt passe.
- Modusen: Du kan ha en full oppdatering eller inkrementell oppdatering. En batchdatabelastning (kilde- og måltilstander er forsinket) eller (nær) sanntidsdatabelastning. Begge vil bli berørt her.
- Frekvensen: Du ønsker kanskje engangsmigrering etterfulgt av en full bytte til skyen eller krever en overgangsperiode og å ha dataene oppdatert på begge sider samtidig, noe som innebærer å utvikle daglig synkronisering mellom lokalt og AWS. Førstnevnte er enklere og gir langt mer mening, men sistnevnte er oftere etterspurt og har langt flere bruddpunkter. Jeg vil dekke begge her.
Innholdsfortegnelse
problem beskrivelse
Kravet er ofte enkelt:
Vi ønsker å begynne å utvikle tjenester i AWS, så vennligst kopier alle dataene våre inn i «ABC»-databasen. Raskt og enkelt. Vi må bruke dataene i AWS nå. Senere vil vi finne ut hvilke deler av DB-design som skal endres for å matche aktivitetene våre.
Før du går videre, er det noe å vurdere:
- Ikke hopp inn i ideen om «bare kopier det vi har og takle det senere» for fort. Jeg mener, ja, dette er det enkleste du kan gjøre, og det vil bli gjort raskt, men dette har potensial til å skape et så grunnleggende arkitektonisk problem som vil være umulig å fikse senere uten seriøs refaktorisering av størstedelen av den nye skyplattformen . Tenk deg at skyøkosystemet er helt annerledes enn det lokale. Flere nye tjenester vil bli introdusert over tid. Naturligvis vil folk begynne å bruke det samme veldig forskjellig. Det er nesten aldri en god idé å gjenskape den lokale tilstanden i skyen på en 1:1-måte. Det kan være i ditt spesielle tilfelle, men sørg for å dobbeltsjekke dette.
- Still spørsmål ved kravet med noen meningsfulle tvil som:
- Hvem vil være den typiske brukeren som bruker den nye plattformen? Mens det er på stedet, kan det være en transaksjonell forretningsbruker; i skyen kan det være en dataforsker eller datavarehusanalytiker, eller dataens hovedbruker kan være en tjeneste (f.eks. Databricks, Glue, maskinlæringsmodeller osv.).
- Forventes de vanlige daglige jobbene å forbli selv etter overgangen til skyen? Hvis ikke, hvordan forventes de å endre seg?
- Planlegger du en betydelig vekst av data over tid? Mest sannsynlig er svaret ja, siden det ofte er den viktigste enkeltårsaken til å migrere inn i skyen. En ny datamodell skal være klar for det.
- Forvent at sluttbrukeren tenker på noen generelle, forventede forespørsler den nye databasen vil motta fra brukerne. Dette vil definere hvor mye den eksisterende datamodellen skal endres for å forbli ytelsesrelevant.
Sette opp migreringen
Når måldatabasen er valgt og datamodellen er tilfredsstillende diskutert, er neste trinn å bli kjent med AWS Schema Conversion Tool. Det er flere områder som dette verktøyet kan tjene på:
Referanse: AWS-dokumentasjon
Nå er det noen tips for bruk av Schema Conversion Tool.
For det første bør det nesten aldri være tilfelle å bruke utgangen direkte. Jeg vil betrakte det mer som referanseresultater, hvor du skal gjøre justeringene dine basert på din forståelse og formål med dataene og måten dataene skal brukes på i skyen.
For det andre, tidligere, ble tabellene sannsynligvis valgt av brukere som forventet raske korte resultater om en konkret datadomeneenhet. Men nå kan dataene velges for analytiske formål. For eksempel vil databaseindekser som tidligere jobbet i den lokale databasen nå være ubrukelige og definitivt ikke forbedre ytelsen til DB-systemet relatert til denne nye bruken. På samme måte vil du kanskje partisjonere dataene annerledes på målsystemet, slik det var før på kildesystemet.
Det kan også være greit å vurdere å gjøre noen datatransformasjoner under migreringsprosessen, som i utgangspunktet betyr å endre måldatamodellen for noen tabeller (slik at de ikke lenger er 1:1-kopier). Senere vil transformasjonsreglene måtte implementeres i migreringsverktøyet.
Hvis kilde- og måldatabasene er av samme type (f.eks. Oracle on-premise vs. Oracle i AWS, PostgreSQL vs. Aurora Postgresql, etc.), så er det best å bruke et dedikert migreringsverktøy som konkret database støtter naturlig ( f.eks. eksport og import av datapumper, Oracle Goldengate, etc.).
I de fleste tilfeller vil imidlertid ikke kilde- og måldatabasen være kompatible, og da vil det åpenbare verktøyet være AWS Database Migration Service.
Referanse: AWS-dokumentasjon
AWS DMS tillater i utgangspunktet å konfigurere en liste over oppgaver på tabellnivå, som vil definere:
- Hva er den nøyaktige kildedatabasen og tabellen å koble til?
- Uttalelsesspesifikasjoner som vil bli brukt for å innhente dataene for måltabellen.
- Transformasjonsverktøy (hvis noen), som definerer hvordan kildedataene skal kartlegges til måltabelldata (hvis ikke 1:1).
- Hva er den eksakte måldatabasen og tabellen for å laste dataene inn?
Konfigurasjonen av DMS-oppgaver gjøres i et brukervennlig format som JSON.
Nå i det enkleste scenariet er alt du trenger å gjøre å kjøre distribusjonsskriptene på måldatabasen og starte DMS-oppgaven. Men det er langt mer til det.
Engangs full datamigrering
Det enkleste tilfellet å utføre er når forespørselen er å flytte hele databasen én gang inn i målskydatabasen. Da vil i utgangspunktet alt som er nødvendig å gjøre se slik ut:
Hvis konfigurasjonen av DMS er gjort bra, skal ingenting dårlig skje i dette scenariet. Hver enkelt kildetabell vil bli plukket opp og kopiert over til AWS-måldatabasen. De eneste bekymringene vil være ytelsen til aktiviteten og å sørge for at dimensjoneringen er riktig i hvert trinn, slik at den ikke svikter på grunn av utilstrekkelig lagringsplass.
Inkrementell daglig synkronisering
Det er her ting begynner å bli komplisert. Jeg mener, hvis verden ville vært ideell, så ville den sannsynligvis fungere helt fint hele tiden. Men verden er aldri ideell.
DMS kan konfigureres til å fungere i to moduser:
- Full belastning – standardmodus beskrevet og brukt ovenfor. DMS-oppgavene startes enten når du starter dem eller når de er planlagt å starte. Når du er ferdig, er DMS-oppgavene gjort.
- Endre datafangst (CDC) – i denne modusen kjører DMS-oppgaven kontinuerlig. DMS skanner kildedatabasen for en endring på tabellnivå. Hvis endringen skjer, prøver den umiddelbart å replikere endringen i måldatabasen basert på konfigurasjonen i DMS-oppgaven relatert til den endrede tabellen.
Når du går for CDC, må du gjøre enda et valg – nemlig hvordan CDC vil trekke ut delta-endringene fra kilde-DB.
#1. Oracle Redo Loggleser
Ett alternativ er å velge innfødt databaseredo-loggleser fra Oracle, som CDC kan bruke for å få de endrede dataene, og, basert på de siste endringene, replikere de samme endringene på måldatabasen.
Selv om dette kan se ut som et opplagt valg hvis du arbeider med Oracle som kilde, er det en hake: Oracle redo-loggleser bruker kilde-Oracle-klyngen og påvirker derfor direkte alle de andre aktivitetene som kjører i databasen (den oppretter faktisk aktive økter direkte i databasen).
Jo flere DMS-oppgaver du har konfigurert (eller jo flere DMS-klynger parallelt), jo mer vil du sannsynligvis trenge å oppgradere Oracle-klyngen – i utgangspunktet, juster den vertikale skaleringen av din primære Oracle-databaseklynge. Dette vil helt sikkert påvirke de totale kostnadene for løsningen, i enda større grad dersom den daglige synkroniseringen er i ferd med å forbli med prosjektet over en lengre periode.
#2. AWS DMS Logg Miner
I motsetning til alternativet ovenfor, er dette en innebygd AWS-løsning på det samme problemet. I dette tilfellet påvirker ikke DMS kilden for Oracle DB. I stedet kopierer den Oracle redo-loggene til DMS-klyngen og utfører all behandlingen der. Selv om det sparer Oracle-ressurser, er det den tregere løsningen, ettersom flere operasjoner er involvert. Og også, som man lett kan anta, er den tilpassede leseren for Oracle redo-logger sannsynligvis tregere i jobben sin som den opprinnelige leseren fra Oracle.
Avhengig av størrelsen på kildedatabasen og antall daglige endringer der, i beste fall, kan du ende opp med nesten sanntids inkrementell synkronisering av dataene fra den lokale Oracle-databasen til AWS-skydatabasen.
I andre scenarier vil det fortsatt ikke være i nærheten av sanntidssynkronisering, men du kan prøve å komme så nært som mulig til den aksepterte forsinkelsen (mellom kilde og mål) ved å stille inn kilde- og målklyngers ytelseskonfigurasjon og parallellitet eller eksperimentere med mengden DMS-oppgaver og deres fordeling mellom CDC-instansene.
Og du vil kanskje lære hvilke kildetabellendringer som støttes av CDC (som f.eks. tillegg av en kolonne) fordi ikke alle mulige endringer støttes. I noen tilfeller er den eneste måten å endre måltabellen manuelt og starte CDC-oppgaven på nytt fra bunnen av (miste alle eksisterende data i måldatabasen underveis).
Når ting går galt, uansett hva
Jeg lærte dette på den harde måten, men det er ett spesifikt scenario knyttet til DMS der løftet om daglig replikering er vanskelig å oppnå.
DMS kan behandle gjenta-loggene bare med en viss definert hastighet. Det spiller ingen rolle om det er flere tilfeller av DMS som utfører oppgavene dine. Likevel leser hver DMS-forekomst gjenta-loggene bare med en enkelt definert hastighet, og hver enkelt av dem må lese dem hele. Det spiller til og med ingen rolle om du bruker Oracle redo-logger eller AWS log miner. Begge har denne grensen.
Hvis kildedatabasen inkluderer et stort antall endringer i løpet av en dag som Oracle-redologgene blir veldig store (som 500 GB+ store) hver eneste dag, vil CDC bare ikke fungere. Replikeringen vil ikke bli fullført før slutten av dagen. Det vil bringe noe ubehandlet arbeid til neste dag, hvor et nytt sett med endringer som skal replikeres allerede venter. Mengden ubehandlede data vil bare vokse fra dag til dag.
I dette spesielle tilfellet var ikke CDC et alternativ (etter mange ytelsestester og forsøk vi utførte). Den eneste måten å sikre at minst alle deltaendringer fra gjeldende dag blir replikert samme dag, var å nærme seg det slik:
- Skill virkelig store bord som ikke brukes så ofte og repliker dem bare én gang i uken (f.eks. i helgene).
- Konfigurer replikering av ikke-så-store-men-likevel-store tabeller for å deles mellom flere DMS-oppgaver; en tabell ble til slutt migrert av 10 eller flere adskilte DMS-oppgaver parallelt, noe som sikrer at datadelingen mellom DMS-oppgavene er distinkt (egendefinert koding involvert her) og utføre dem daglig.
- Legg til flere (opptil 4 i dette tilfellet) forekomster av DMS og del DMS-oppgavene jevnt mellom dem, noe som betyr ikke bare etter antall tabeller, men også etter størrelse.
I utgangspunktet brukte vi full load-modusen til DMS for å replikere daglige data fordi det var den eneste måten å oppnå fullføring av datareplikering samme dag.
Ikke en perfekt løsning, men den er der fortsatt, og selv etter mange år fungerer den fortsatt på samme måte. Så, kanskje ikke så ille løsning likevel. 😃