Kreditt: Octopus Deploy
Denne uken kunngjorde Facebooks utviklingsorganisasjon at de var ferdige med den typen oppgaver bedriftene gruer seg til: en større oppgradering til kjernedatabasen. Larry Dignan skisserte høydepunktene i sin oversikt i går. Og i den oversikten antydet han mer enn prøvelser og trengsler som migrasjonen opplevde.
Databaseoverføringer skjer hele tiden, og det mangler ikke råd om hvordan de skal gjennomføres. Men Facebooks detaljerte blogginnlegg ga verdifulle leksjoner, som vi vil komme nærmere inn på her. Det var et massivt, flerårig prosjekt, spesielt fordi Facebook har et så stort utvalg av MySQL-forekomster.
Først og fremst, hva var alt oppstyret om? Det er lite spørsmål om at MySQL representerer en stor generasjonsoppgradering til denne plattformen. Oppgraderingen var så betydelig at Oracle, som eier MySQL, ble bedt om å gjennomføre en større oppdatering og oppgradering av sin egen sky MySQL-tjeneste.
Det er en lang vaskeliste med endringer i 8.0-versjonen, men vi vil fremheve noen av dem her. Det starter med håndterbarhet: MySQL 8.0 legger til ordboken for transaksjonsdata som ellers er standard for databaser med bedriftsklasse. Det er større enkelhet: alle oppgavene som er involvert i datadefinisjonsspråk (DDL) påkalt for rutinekommandoer, kombineres nå til en enkelt uttalelse. Så, du trenger ikke å skrive separate utsagn for oppdatering av dataordbok, drift av lagringsmotorer og binærlogg. Tabellkryptering er strømlinjeformet, og det er forbedret støtte for utvidede datatyper som BLOB, TEXT, GEOMETRY og JSON.
Det er den kule nye funksjonen til “usynlige indekser” som tillater tester på virkningen av å fjerne indekser uten å måtte fjerne den fysisk. Det er analogt med avanserte indekseringsfunksjoner i Oracle Autonomous Database og Microsoft Azure SQL Database som tillater testing av alternative indekseringsskjemaer for å evaluere om noen indekser kaster bort plass, eller at nye eller modifiserte kan hente data med mindre beregningsomkostninger.
Men som enhver erfaren DBA vil bevitne, er det alltid en pris å betale når du oppgraderer, for eksempel destabilisering av applikasjoner, og derfor utsetter de fleste organisasjoner migrasjon til behovet er for stort. Ikke tilfeldig, de fleste Cloud Database-as-a-Service (DBaaS) -leverandører spiller opp løftet om å eliminere smerten ved oppgraderinger fordi de tar hodepine fra kundenes skuldre.
Så det er ikke overraskende at toppen av listen over leksjoner har å gjøre med kompatibilitetsproblemer. La oss starte med tilpasninger, som er typiske for forankrede forretningsinstallasjoner. Ikke overraskende har dette også lenge vært et problem i bedriftens applikasjonsverden, hvor automatiserte migreringsverktøy vanligvis slutter når det gjelder tilpasninger. Faktisk oppfordrer SAP nå kunder til i stedet å beholde kjerneimplementeringene vanilje, og abstrakte implementeringene gjennom API-er som skal være stabile. Facebook hadde ikke denne luksusen med MySQL-migrasjonen. Som Larry bemerket i sin konto, var det bare 1500 av 2300 tilpassede oppdateringer som gjorde at resten ble avskaffet.
Et beslektet problem er API-kompatibilitet, og det er her Facebook oppdaget en skjult “gotcha”. Som nevnt utsetter kunder vanligvis migrasjoner av store bedriftssystemer på grunn av tiden og forstyrrelsen som er involvert, og i dette tilfellet betydde det at Facebook hoppet over en syklus. I stedet for å gå fra MySQL 5.6 til 5.7, hoppet de over midlertidig utgivelse og gikk direkte til 8.0. Resultatet var behovet for å utføre detektivarbeid angående støttede API-er; da de lærte på den harde måten, ble det endret en rekke API-er i 5.6-versjonen som ikke var inkludert i 8.0-dokumentasjonen. Dette tilførte en tidsstraff.
Migreringen involverte i noen tilfeller også den underliggende lagringsmotoren. MySQL er en database som støtter pluggbare lagringsmotorer, og siden 2016 har Facebook flyttet sine brukervendte MySQL-implementeringer fra InnoDB, den vanligste motoren som brukes i MySQL, til MyRocks, en open source-lagringsmotor som faktisk Facebook utviklet. Fordelen med MyRocks er mer effektiv komprimering og skriver.
Å flytte fra InnoDB til MyRocks krevde et “skygge” testrammeverk som fanget produksjonstrafikk og spilte dem på nytt i testtilfeller. Men denne prosessen var ikke idiotsikker; det gikk glipp av problemer som hvordan MyRocks ville håndtere deadlocks for transaksjonsskriving. Historien til historien er at mens du kan simulere noen scenarier, vil feilene i noen tilfeller ikke dukke opp før etter faktum, og du bør bygge inn faktiske rettelser i en hvilken som helst migrasjons- og testplan. p>
På grunn av alle forventede og uventede kompatibilitetsproblemer, spilte Facebook det veldig forsiktig når det gjaldt å flytte data. I stedet for den vanlige prosessen med å replikere tabeller eller SQL-setninger, gikk Facebook rad for rad – en veldig møysommelig prosess. Behovet for en så drastisk handling ble drevet av den store porteføljen av apper, og sannsynligheten for å møte gjensidig avhengighet: noen data som kan brukes av applikasjon A, kan ha blitt avledet som et resultat av behandling av applikasjon B.
Den overraskende leksjonen er at migrering av bedriftsdatabaser sjelden er trivielle.
Det er mye av grunnen til at Facebook gikk en vei som er vanlig for store bedrifter å holde ut til det er absolutt nødvendig, og fordi det betydde at man hoppet over en mellomliggende versjonsoppgradering, betalte den en pris. Det fikk Larry til å stille spørsmålet i stykket sitt om hvorvidt all innsatsen var verdt det.
Spørsmålet er om disse hodepine kan unngås eller minimeres i fremtiden, når det er sagt, det er en MySQL 9.0. Et svar – hvis du ikke er Facebook – flytter til Cloud Database-as-a-Service DBaaS), der skyleverandører kontinuerlig holder versjonen oppdatert og angivelig isolerer kunder fra underliggende plattformendringer.
Men hvis du fortsatt prøver dette hjemme, antydet Larry til svaret: Begynn å planlegge nå for den muligheten. Mer spesifikt, gjør oppgraderingen av dot release, men kanskje i det lange løp, begynn å abstrakte tilpasninger ved hjelp av APIer, hvis mulig. Kanskje i fremtiden kan maskinlæring gi en hjelp til å forutsi hvor kompatibilitetsproblemer kan oppstå, men dette er absolutt en forekomst der menneskelig intuisjon må være i kontroll.
Big Data Hvor er IBMs hybridsky launchpad? Syv måter å gjøre sanntidsteknologi ekte for organisasjonen din Maskinlæring på kanten: TinyML blir stor Hva er neste for Cloudera? McDonald's ønsker å 'demokratisere' maskinlæring for alle brukere på tvers av virksomheten.
Relaterte emner:
Data Management Digital Transformation Robotics Internet of Things Innovasjon Enterprise Software 