Krediet: Octopus Deploy
Deze week kondigde de ontwikkelingsorganisatie van Facebook de voltooiing aan van het soort taken waar bedrijven bang voor zijn: een grote upgrade van de kerndatabase. Larry Dignan schetste de hoogtepunten in zijn overzicht. En in dat overzicht zinspeelde hij meer dan op de beproevingen en beproevingen die de migratie tegenkwam.
Databasemigraties vinden voortdurend plaats en er is geen gebrek aan advies over hoe ze moeten worden uitgevoerd. Maar de gedetailleerde blogpost van Facebook leverde waardevolle lessen op, die we hier in meer detail zullen bespreken. Het was een enorm, meerjarig project, vooral omdat Facebook zo'n groot aantal MySQL-instanties heeft.
Ten eerste, waar ging al die ophef over? Het lijdt geen twijfel dat MySQL een belangrijke generatie-upgrade naar dit platform vertegenwoordigt. De upgrade was zo belangrijk dat Oracle, dat eigenaar is van MySQL, werd gevraagd om een ingrijpende vernieuwing en upgrade van zijn eigen cloud MySQL-service uit te voeren.
Er is een lange waslijst met veranderingen in de 8.0-versie, maar we zullen er hier een paar uitlichten. Het begint met beheersbaarheid: MySQL 8.0 voegt de transactionele datadictionary toe die anders standaard is voor enterprise-grade databases. Er is meer eenvoud: alle taken die betrokken zijn bij Data Definition Language (DDL) die worden aangeroepen voor routineopdrachten, worden nu gecombineerd in één enkele instructie. U hoeft dus geen afzonderlijke instructies te schrijven voor het bijwerken van dat woordenboek, bewerkingen van de opslagengine en het schrijven van binaire logboeken. Tabelversleuteling is gestroomlijnd en er is verbeterde ondersteuning voor uitgebreide gegevenstypen zoals BLOB, TEXT, GEOMETRY en JSON.
Er is de coole nieuwe functie van “onzichtbare indexen” waarmee tests op de impact van het verwijderen van indexen mogelijk zijn zonder deze fysiek te hoeven verwijderen. Het is analoog aan geavanceerde indexeringsfuncties in Oracle Autonomous Database en Microsoft Azure SQL Database waarmee alternatieve indexeringsschema's kunnen worden getest om te evalueren of sommige indexen ruimte verspillen, of dat nieuwe of gewijzigde indexen gegevens kunnen ophalen met minder rekenoverhead.
Maar zoals elke ervaren DBA zal beamen, moet er altijd een prijs worden betaald bij het upgraden, zoals het destabiliseren van applicaties. Daarom stellen de meeste organisaties de migratie uit totdat de behoefte te groot is. Het is niet toevallig dat de meeste cloud Database-as-a-Service (DBaaS)-providers de belofte van het elimineren van de pijn van upgrades waarmaken, omdat ze de pijn van upgrades van de schouders van klanten wegnemen.
Het is dus niet verwonderlijk dat compatibiliteitsproblemen bovenaan de lijst van geleerde lessen staan. Boven aan de lijst staan aanpassingen, die typisch zijn voor diepgewortelde enterprise data-installaties. Het is niet verrassend dat dit ook al lang een probleem is in de wereld van bedrijfsapplicaties, waar geautomatiseerde migratietools doorgaans achterwege blijven als het gaat om aanpassingen. In feite moedigt SAP klanten nu aan om in plaats daarvan de kernimplementaties vanille te houden en de implementaties te abstraheren via API's die stabiel moeten blijven. Facebook had deze luxe niet met de MySQL-migratie. Zoals Larry opmerkte in zijn account, hebben slechts 1500 van de 2300 aangepaste patches de overstap gemaakt, terwijl de rest is verouderd.
Een gerelateerd probleem is API-compatibiliteit, en dit is waar Facebook een verborgen 'gotcha' ontdekte. Zoals opgemerkt, stellen klanten migraties van grote bedrijfssystemen doorgaans uit vanwege de tijd en de verstoring die ermee gemoeid is, en in dit geval betekende dat dat Facebook een cyclus oversloeg. In plaats van van MySQL 5.6 naar 5.7 te gaan, sloegen ze de tussentijdse release over en gingen direct naar 8.0. Het resultaat was de noodzaak om speurwerk te verrichten met betrekking tot ondersteunde API's; zoals ze op de harde manier leerden, werden een aantal API's gewijzigd in de 5.6-release die niet waren opgenomen in de 8.0-documentatie. Dit zorgde voor tijdverlies.
Bij de migratie was in sommige gevallen ook de onderliggende storage-engine betrokken. MySQL is een database die pluggable storage-engines ondersteunt, en sinds 2016 heeft Facebook zijn gebruikersgerichte MySQL-implementaties verplaatst van InnoDB, de meest gebruikte engine in MySQL, naar MyRocks, een open source storage-engine die in feite door Facebook is ontwikkeld. Het voordeel van MyRocks is efficiëntere compressie en schrijven.
De overstap van InnoDB naar MyRocks vereiste een “schaduw”-testraamwerk dat productieverkeer vastlegde en in testinstanties opnieuw afspeelde. Maar dit proces was niet onfeilbaar; het miste problemen zoals hoe MyRocks zou omgaan met deadlocks bij het schrijven van transacties. De moraal van het verhaal is dat hoewel je sommige scenario's kunt simuleren, de bugs in sommige gevallen pas achteraf verschijnen, en dat je achteraf oplossingen moet inbouwen in elk migratie- en testplan.
Vanwege alle verwachte en onverwachte compatibiliteitsproblemen speelde Facebook het erg voorzichtig als het ging om het verplaatsen van gegevens. In plaats van het gebruikelijke proces van het repliceren van tabellen of SQL-instructies, ging Facebook rij voor rij – een zeer nauwgezet proces. De noodzaak voor dergelijke drastische maatregelen werd gedreven door de grote portfolio van apps en de waarschijnlijkheid van onderlinge afhankelijkheden: sommige gegevens die door toepassing A kunnen worden gebruikt, zijn mogelijk afgeleid als gevolg van verwerking door toepassing B.
De niet-verrassende les is dat migratie van bedrijfsdatabases zelden triviaal is.
Het is een van de redenen waarom Facebook een pad insloeg dat voor grote ondernemingen gebruikelijk is om te wachten tot het absoluut noodzakelijk is, en omdat dat betekende dat een tussenversie-upgrade moest worden overgeslagen, betaalde het een prijs. Het dreef Larry ertoe om in zijn stuk de vraag te stellen of alle moeite de moeite waard was.
De vraag is of deze hoofdpijn in de toekomst kan worden vermeden of geminimaliseerd, als er bijvoorbeeld een MySQL 9.0 is. Een antwoord – als u geen Facebook bent – is overstappen naar de cloud Database-as-a-Service DBaaS), waar cloudleveranciers de versie voortdurend up-to-date houden en klanten zogenaamd isoleren van onderliggende platformwijzigingen.
Maar als je dit thuis nog steeds probeert, hintte Larry op het antwoord: begin nu met plannen voor die mogelijkheid. Meer specifiek, voer de dot release-upgrades uit, maar misschien op de lange termijn, begin met het abstraheren van aanpassingen met behulp van API's, indien mogelijk. Misschien kan machine learning in de toekomst een hulpmiddel zijn om te voorspellen waar compatibiliteitsproblemen kunnen ontstaan, maar dit is zeker een geval waarin de menselijke intuïtie de baas moet blijven.
Big Data
Waar is IBM's hybride cloud launchpad? Zeven manieren om realtime technologie echt te maken voor uw organisatie Machine learning aan de edge: TinyML wordt groot Wat biedt Cloudera nu? McDonald's wil machine learning 'democratiseren' voor alle gebruikers in al haar activiteitengerelateerde onderwerpen:
gegevensbeheer Digitale transformatie Robotica Internet of Things Innovatie Enterprise Software 