Kredit: Octopus Deploy
Denne uge annoncerede Facebooks udviklingsorganisation, at den var færdig med den type opgaver, som virksomheder frygter: en større opgradering til sin kernedatabase. Larry Dignan skitserede de høje punkter i sin oversigt i går. Og i denne oversigt antydede han mere end de prøvelser og trængsler, som migrationen stødte på.
Databasemigrationer sker hele tiden, og der mangler ikke råd om, hvordan man gennemfører dem. Men Facebooks detaljerede blogindlæg gav værdifulde lektioner, som vi kommer nærmere ind på her. Det var et massivt, flerårigt projekt, især fordi Facebook har et så stort udvalg af MySQL-forekomster.
Først og fremmest, hvad handlede det hele om? Der er ikke meget spørgsmål om, at MySQL repræsenterer en større generationsopgradering til denne platform. Opgraderingen var så betydelig, at Oracle, der ejer MySQL, blev bedt om at foretage en større opdatering og opgradering af sin egen cloud MySQL-tjeneste.
Der er en lang vasketøjsliste med ændringer i 8.0-versionen, men vi fremhæver et par af dem her. Det starter med håndterbarhed: MySQL 8.0 tilføjer transaktionsdataordbogen, der ellers er standard for databaser i virksomhedsklasse. Der er større enkelhed: alle de opgaver, der er involveret i datadefinitionssprog (DDL), der påberåbes til rutinekommandoer, kombineres nu til en enkelt erklæring. Så du behøver ikke at skrive separate udsagn til opdateringer af datadeksbogen, lagringsmotorfunktioner og binære logskrivninger. Tabelkryptering er blevet strømlinet, og der er forbedret understøttelse af udvidede datatyper som BLOB, TEXT, GEOMETRY og JSON.
Der er den seje nye funktion af “usynlige indekser”, der tillader test på virkningerne af at fjerne indekser uden at skulle fjerne det fysisk. Det er analogt med avancerede indekseringsfunktioner i Oracle Autonomous Database og Microsoft Azure SQL Database, der tillader test af alternative indekseringsplaner til evaluering af, om nogle indekser spilder plads, eller nye eller modificerede kan hente data med mindre beregningsomkostninger.
Men som enhver erfaren DBA vil bevidne, er der altid en pris at betale, når man opgraderer, såsom destabilisering af applikationer, hvorfor de fleste organisationer udsætter migrering, indtil behovet er for stort. Ikke tilfældigt spiller de fleste Cloud Database-as-a-Service-udbydere (DBaaS) løftet om at eliminere smerten ved opgraderinger, fordi de tager hovedpine fra kundernes skuldre.
Så det er ikke overraskende, at øverst på listen over erfaringer har at gøre med kompatibilitetsproblemer. Lad os starte med tilpasninger, som er typiske for forankrede virksomhedsdatainstallationer. Ikke overraskende har dette også længe været et problem i virksomhedsapplikationsverdenen, hvor automatiserede migreringsværktøjer typisk holder af med hensyn til tilpasninger. Faktisk opfordrer SAP nu kunderne til i stedet at beholde de centrale implementeringer vanille og abstrakte implementeringerne gennem API'er, der skal forblive stabile. Facebook havde ikke denne luksus med MySQL-migrationen. Som Larry bemærkede i sin konto, var det kun 1500 ud af 2300 brugerdefinerede programrettelser, der blev flyttet, mens resten af dem blev udfaset.
Et relateret problem er API-kompatibilitet, og det er her, Facebook opdagede en skjult “gotcha”. Som nævnt udsætter kunder typisk migreringer af store virksomhedssystemer på grund af den involverede tid og afbrydelse, og i dette tilfælde betød det, at Facebook sprang over en cyklus. I stedet for at gå fra MySQL 5.6 til 5.7, sprang de over midlertidig frigivelse og gik direkte til 8.0. Resultatet var behovet for at udføre detektivarbejde vedrørende understøttede API'er; da de lærte på den hårde måde, blev et antal API'er ændret i 5.6-udgivelsen, som ikke var inkluderet i 8.0-dokumentationen. Dette tilføjede et tidsrum.
Migreringen involverede i nogle tilfælde også den underliggende lagermotor. MySQL er en database, der understøtter plugbare lagermotorer, og siden 2016 har Facebook flyttet sine brugervendte MySQL-implementeringer fra InnoDB, den mest almindelige motor, der bruges i MySQL, til MyRocks, en open source-lagermotor, som faktisk Facebook udviklede. Fordelen ved MyRocks er mere effektiv komprimering og skrivning.
Flytning fra InnoDB til MyRocks krævede en “skygge” -testningsramme, der fangede produktionstrafik og afspilte dem i testtilfælde. Men denne proces var ikke idiotsikker; det gik glip af problemer som hvordan MyRocks ville håndtere deadlocks for transaktionsskrivning. Historiens moral er, at selvom du kan simulere nogle scenarier, vil fejlene i nogle tilfælde ikke dukke op før efter kendsgerningen, og du skal bygge ind efterfølgende rettelser i enhver migrerings- og testplan.
På grund af alle de forventede og uventede kompatibilitetsproblemer spillede Facebook det meget forsigtigt, når det drejede sig om at flytte data. I stedet for den sædvanlige proces med replikering af tabeller eller SQL-udsagn gik Facebook række for række – en meget omhyggelig proces. Behovet for en sådan drastisk handling var drevet af den store portefølje af apps og sandsynligheden for at støde på indbyrdes afhængigheder: nogle data, der muligvis bruges af applikation A, kan være afledt som et resultat af behandling af applikation B.
Den ikke overraskende lektion er, at migrering af virksomhedsdatabaser sjældent er trivielle.
Det er meget af grunden til, at Facebook tog en vej, der er almindelig for store virksomheder at holde ud, indtil det er absolut nødvendigt, og fordi det betød at springe over en mellemliggende versionopgradering, betalte den en pris. Det fik Larry til at stille spørgsmålet i sit stykke om, hvorvidt al indsatsen var det værd.
Spørgsmålet er, om disse hovedpine kunne undgås eller minimeres i fremtiden, når man siger, der er en MySQL 9.0. Et svar – hvis du ikke er Facebook – flytter til cloud Database-as-a-Service DBaaS), hvor cloud-leverandører løbende holder versionen opdateret og angiveligt isolerer kunder fra underliggende platformændringer.
Men hvis du stadig prøver dette hjemme, antydede Larry svaret: Begynd at planlægge nu for den eventualitet. Mere specifikt skal du udføre opgraderinger af punktudgivelser, men måske i det lange løb, begynd at abstrakte tilpasninger ved hjælp af API'er, hvis det er muligt. Måske i fremtiden kan maskinindlæring være en hjælp til at forudsige, hvor kompatibilitetsproblemer kan opstå, men dette er bestemt et tilfælde, hvor menneskelig intuition skal forblive i kontrol.
Big Data Hvor er IBMs hybrid cloud-startplade? Syv måder at gøre realtidsteknologi til virkelighed for din organisation Maskinindlæring på kanten: TinyML bliver stor Hvad er næste for Cloudera? McDonald's ønsker at 'demokratisere' maskinindlæring for alle brugere på tværs af sine operationer
Relaterede emner:
Data Management Digital Transformation Robotics Internet of Things Innovation Enterprise Software 