Kredit: Octopus Deploy
Den här veckan tillkännagav Facebooks utvecklingsorganisation att den hade slutfört den typ av uppgifter som företagen fruktar: en större uppgradering av sin kärndatabas. Larry Dignan redogjorde för höjdpunkterna i sin översikt igår. Och i den översikten antydde han mer än bara de prövningar och trängningar som migrationen stött på.
Databasmigrationer sker hela tiden, och det råder ingen brist på råd om hur de ska genomföras. Men Facebooks detaljerade blogginlägg gav värdefulla lärdomar, som vi kommer att gå in på mer detaljer här. Det var ett massivt, flerårigt projekt, särskilt för att Facebook har ett så stort antal MySQL-instanser.
Först och främst, vad var allt väsen om? Det finns ingen tvekan om att MySQL representerar en stor generationsuppgradering av denna plattform. Uppgraderingen var så betydelsefull att Oracle, som äger MySQL, uppmanades att genomföra en större uppdatering och uppgradering av sin egen moln MySQL-tjänst.
Det finns en lång tvättlista med ändringar i 8.0-versionen, men vi lyfter fram några av dem här. Det börjar med hanterbarhet: MySQL 8.0 lägger till ordboken för transaktionsdata som annars är standard för databaser i företagsklass. Det finns större enkelhet: alla uppgifter som är involverade i datadefinitionsspråk (DDL) som anropas för rutinkommandon kombineras nu till ett enda uttalande. Så du behöver inte skriva separata uttalanden för uppdateringar av datalistor, lagringsmotoroperationer och binära loggskrivningar. Tabellkryptering har strömlinjeformats och det finns förbättrat stöd för utökade datatyper som BLOB, TEXT, GEOMETRY och JSON.
Det finns den coola nya funktionen i “osynliga index” som gör det möjligt att testa effekterna av att ta bort index utan att behöva ta bort det fysiskt. Det är analogt med avancerade indexeringsfunktioner i Oracle Autonomous Database och Microsoft Azure SQL Database som gör det möjligt att testa alternativa indexeringsscheman för att utvärdera om vissa index slösar bort utrymme, eller nya eller modifierade skulle kunna hämta data med mindre beräkningsomkostnader.
Men som alla erfarna DBA kommer att intyga finns det alltid ett pris att betala vid uppgradering, till exempel destabiliserande applikationer, varför de flesta organisationer skjuter upp migrering tills behovet är för stort. Inte en tillfällighet spelar de flesta DBaaS-leverantörer (Cloud Database-as-a-Service) upp löftet om att eliminera smärtan vid uppgraderingar eftersom de tar huvudvärken från kundernas axlar.Så det är inte förvånande att högst upp på listan över lärdomar hanterar kompatibilitetsproblem. Låt oss börja med anpassningar, som är typiska för förankrade företagsdatainstallationer. Inte överraskande har detta också länge varit ett problem i företagens applikationsvärld, där automatiserade migreringsverktyg vanligtvis slutar när det gäller anpassningar. I själva verket uppmuntrar SAP nu kunderna att istället behålla kärnimplementeringarna vanilj och abstrakta implementeringarna genom API: er som ska förbli stabila. Facebook hade inte denna lyx med MySQL-migrationen. Som Larry noterade i sitt konto gjorde bara 1500 av 2300 anpassade korrigeringar flytten, med resten av dem utfasade.
Ett relaterat problem är API-kompatibilitet, och det är här Facebook upptäckte en dold “gotcha”. Som nämnts avskräcker kunder vanligtvis migreringar av stora företagssystem på grund av tid och störningar, och i det här fallet innebar det att Facebook hoppade över en cykel. Istället för att gå från MySQL 5.6 till 5.7 hoppade de över mellanliggande versionen och gick direkt till 8.0. Resultatet var behovet av att utföra detektivarbete avseende API: er som stöds; när de lärde sig på det hårda sättet ändrades ett antal API: er i 5.6-versionen som inte inkluderades i 8.0-dokumentationen. Detta tillförde en tidsstraf.
Migreringen involverade i vissa fall också den underliggande lagringsmotorn. MySQL är en databas som stöder pluggbara lagringsmotorer, och sedan 2016 har Facebook flyttat sina användarvänliga MySQL-implementeringar från InnoDB, den vanligaste motorn som används i MySQL, till MyRocks, en öppen källkodslagermotor som faktiskt Facebook utvecklade. Fördelen med MyRocks är effektivare komprimering och skrivning.
Att flytta från InnoDB till MyRocks krävde ett “skugg” testramverk som fångade produktionstrafik och spelade upp dem igen i testinstanser. Men denna process var inte idiotsäker; det missade frågor som hur MyRocks skulle hantera blockeringar för transaktionsskrivning. Historiens moral är att även om du kan simulera vissa scenarier, kommer buggarna i vissa fall inte att dyka upp förrän efter det faktum, och du bör bygga in faktiska korrigeringar i någon migrations- och testplan.
På grund av alla förväntade och oväntade kompatibilitetsproblem spelade Facebook det mycket försiktigt när det gäller att flytta data. I stället för den vanliga processen att replikera tabeller eller SQL-uttalanden, gick Facebook rad för rad – en mycket noggrann process. Behovet av en sådan drastisk åtgärd drevs av den stora portföljen av appar och sannolikheten för att stöta på ömsesidiga beroenden: vissa data som kan användas av applikation A kan ha härletts som ett resultat av bearbetning av applikation B.
Den överraskande lektionen är att migrering av företagsdatabaser sällan är trivial.
Det är mycket av anledningen till att Facebook tog en väg som är vanligt för stora företag att hålla kvar tills det är absolut nödvändigt, och eftersom det innebar att hoppa över en mellanliggande versionuppgradering, betalade den ett pris. Det fick Larry att ställa frågan i sin artikel om huruvida alla ansträngningar var värda det.
Frågan är om dessa huvudvärk skulle kunna undvikas eller minimeras i framtiden, när man säger, det finns en MySQL 9.0. Ett svar – om du inte är Facebook – flyttar till Cloud Database-as-a-Service DBaaS), där molnleverantörer kontinuerligt håller versionen uppdaterad och förmodligen isolerar kunder från underliggande plattformsändringar.
Men om du fortfarande provar det här hemma antydde Larry svaret: Börja planera nu för den eventualiteten. Mer specifikt gör uppgraderingen av dot release, men kanske i det långa loppet, börja abstrakta anpassningar med API: er, om möjligt. I framtiden kanske maskininlärning kan hjälpa till att förutsäga var kompatibilitetsproblem kan uppstå, men detta är verkligen en instans där mänsklig intuition måste förbli kontrollerad.
Big Data Var är IBM: s hybridmoln launchpad? Sju sätt att göra realtidsteknologi verklig för din organisation Maskininlärning vid kanten: TinyML blir stort Vad är nästa för Cloudera? McDonald's vill 'demokratisera' maskininlärning för alla användare över hela verksamheten
Relaterade ämnen:
Datahantering Digital Transformation Robotics Internet of Things Innovation Enterprise Software 