Credit: Octopus Deploy
Diese Woche gab die Entwicklungsorganisation von Facebook bekannt, dass sie die Art von Aufgaben abgeschlossen hat, die Unternehmen fürchten: ein umfassendes Upgrade ihrer Kerndatenbank. Larry Dignan hat gestern in seiner Übersicht die Höhepunkte skizziert. Und in dieser Übersicht hat er die Schwierigkeiten und Schwierigkeiten, die die Migration mit sich brachte, mehr als angedeutet.
Datenbankmigrationen finden ständig statt, und es gibt keinen Mangel an Ratschlägen, wie sie durchgeführt werden können. Aber der ausführliche Blog-Beitrag von Facebook hat wertvolle Erkenntnisse gebracht, auf die wir hier genauer eingehen werden. Es war ein riesiges, mehrjähriges Projekt, vor allem weil Facebook so viele MySQL-Instanzen hat.
Zunächst einmal, worum ging es bei all der Aufregung? Es steht außer Frage, dass MySQL ein bedeutendes Generations-Upgrade dieser Plattform darstellt. Das Upgrade war so bedeutend, dass Oracle, das Eigentümer von MySQL ist, aufgefordert wurde, eine umfassende Aktualisierung und ein Upgrade seines eigenen Cloud-MySQL-Dienstes durchzuführen.
Es gibt eine lange Liste von Änderungen in der Version 8.0, aber wir werden hier einige davon hervorheben. Es beginnt mit der Verwaltbarkeit: MySQL 8.0 fügt das Transaktionsdatenwörterbuch hinzu, das ansonsten für Datenbanken der Enterprise-Klasse Standard ist. Es gibt noch mehr Einfachheit: Alle Aufgaben, die mit der Data Definition Language (DDL) verbunden sind, die für Routinebefehle aufgerufen wird, sind jetzt in einer einzigen Anweisung zusammengefasst. Sie müssen also keine separaten Anweisungen für Datenwörterbuchaktualisierungen, Speicher-Engine-Operationen und Binärlog-Schreibvorgänge schreiben. Die Tabellenverschlüsselung wurde optimiert und erweiterte Datentypen wie BLOB, TEXT, GEOMETRY und JSON werden jetzt besser unterstützt.
Es gibt die coole neue Funktion der “unsichtbaren Indizes”, mit der die Auswirkungen des Entfernens von Indizes getestet werden können, ohne sie physisch entfernen zu müssen. Es entspricht den erweiterten Indizierungsfeatures in Oracle Autonomous Database und Microsoft Azure SQL Database, die das Testen alternativer Indizierungsschemata ermöglichen, um zu bewerten, ob einige Indizes Speicherplatz verschwenden oder neue oder geänderte Indizes Daten mit weniger Rechenaufwand abrufen könnten.
Aber wie jeder erfahrene DBA bestätigen kann, ist ein Upgrade immer mit einem Preis verbunden, z. B. durch das Destabilisieren von Anwendungen, weshalb die meisten Unternehmen die Migration verschieben, bis der Bedarf zu groß ist. Es ist kein Zufall, dass die meisten Cloud-Anbieter von Database-as-a-Service (DBaaS) das Versprechen einlösen, Upgrades zu vermeiden, weil sie den Kunden diese Kopfschmerzen nehmen.
Es ist daher nicht verwunderlich, dass Kompatibilitätsprobleme ganz oben auf der Liste der gewonnenen Erkenntnisse stehen. Beginnen wir mit Anpassungen, die typisch für fest verankerte Unternehmensdateninstallationen sind. Es überrascht nicht, dass dies auch in der Welt der Unternehmensanwendungen seit langem ein Problem ist, wo automatisierte Migrationstools normalerweise bei Anpassungen aufhören. Tatsächlich ermutigt SAP Kunden nun, stattdessen die Kernimplementierungen Vanille beizubehalten und die Implementierungen durch APIs zu abstrahieren, die stabil bleiben sollten. Diesen Luxus hatte Facebook mit der MySQL-Migration nicht. Wie Larry in seinem Bericht feststellte, wurden nur 1500 von 2300 benutzerdefinierten Patches umgezogen, der Rest wurde eingestellt.
Ein verwandtes Problem ist die API-Kompatibilität, und hier entdeckte Facebook einen versteckten “Gotcha”. Wie bereits erwähnt, haben Kunden die Migration großer Unternehmenssysteme aufgrund des damit verbundenen Zeitaufwands und der damit verbundenen Unterbrechungen in der Regel verschoben, und in diesem Fall bedeutete dies, dass Facebook einen Zyklus übersprang. Anstatt von MySQL 5.6 auf 5.7 zu wechseln, übersprangen sie die Zwischenversion und gingen direkt zu 8.0. Das Ergebnis war die Notwendigkeit, Detektivarbeit in Bezug auf unterstützte APIs durchzuführen; Wie sie auf die harte Tour lernten, wurden in der 5.6-Version eine Reihe von APIs geändert, die nicht in der 8.0-Dokumentation enthalten waren. Dies führte zu einem Zeitverlust.
Die Migration betraf in einigen Fällen auch die zugrunde liegende Speicher-Engine. MySQL ist eine Datenbank, die Pluggable-Storage-Engines unterstützt, und seit 2016 hat Facebook seine benutzerorientierten MySQL-Implementierungen von InnoDB, der am häufigsten in MySQL verwendeten Engine, zu MyRocks verlagert, einer Open-Source-Storage-Engine, die tatsächlich von Facebook entwickelt wurde. Der Vorteil von MyRocks ist eine effizientere Komprimierung und Schreibvorgänge.
Der Wechsel von InnoDB zu MyRocks erforderte ein „Schatten“-Test-Framework, das den Produktionsverkehr erfasst und in Testinstanzen wiedergibt. Aber dieser Prozess war nicht narrensicher; es übersah Probleme, wie beispielsweise, wie MyRocks Transaktionsschreib-Deadlocks handhaben würde. Die Moral der Geschichte ist, dass Sie zwar einige Szenarien simulieren können, in einigen Fällen die Fehler jedoch erst im Nachhinein auftauchen und Sie nachträgliche Korrekturen in jeden Migrations- und Testplan einbauen sollten.
Aufgrund all der erwarteten und unerwarteten Kompatibilitätsprobleme spielte Facebook beim Verschieben von Daten sehr vorsichtig. Anstelle des üblichen Replizierens von Tabellen oder SQL-Anweisungen ging Facebook Zeile für Zeile vor – ein sehr mühsamer Prozess. Die Notwendigkeit solch drastischer Maßnahmen wurde durch das große App-Portfolio und die Wahrscheinlichkeit, auf gegenseitige Abhängigkeiten zu stoßen, getrieben: Einige Daten, die von Anwendung A verwendet werden könnten, stammen möglicherweise aus der Verarbeitung durch Anwendung B.
Die nicht überraschende Erkenntnis ist, dass die Migration von Unternehmensdatenbanken selten trivial ist.
Aus vielen Gründen hat Facebook einen Weg eingeschlagen, der für große Unternehmen üblich ist, bis zum absoluten Notwendigen zu warten, und weil dies bedeutete, dass ein Zwischenversions-Upgrade übersprungen wurde, zahlte es seinen Preis. Es trieb Larry dazu, in seinem Beitrag die Frage zu stellen, ob sich der ganze Aufwand gelohnt hat.
Die Frage ist, ob diese Kopfschmerzen in Zukunft vermieden oder minimiert werden könnten, wenn es beispielsweise MySQL 9.0 gibt. Eine Antwort – wenn Sie nicht Facebook sind – ist die Umstellung auf Cloud Database-as-a-Service DBaaS), bei der Cloud-Anbieter die Version ständig auf dem neuesten Stand halten und Kunden angeblich von zugrunde liegenden Plattformänderungen isolieren.
Aber wenn Sie dies immer noch zu Hause versuchen, deutet Larry die Antwort an: Beginnen Sie jetzt mit der Planung für diesen Fall. Führen Sie insbesondere die Dot-Release-Upgrades durch, aber beginnen Sie möglicherweise auf lange Sicht, Anpassungen mithilfe von APIs zu abstrahieren, wenn möglich. Vielleicht könnte maschinelles Lernen in Zukunft helfen, vorherzusagen, wo Kompatibilitätsprobleme auftreten könnten, aber dies ist sicherlich ein Fall, in dem die menschliche Intuition die Kontrolle behalten muss.
Big Data
Wo ist das Hybrid Cloud Launchpad von IBM? Sieben Möglichkeiten, Echtzeit-Technologie für Ihr Unternehmen real zu machen Machine Learning am Edge: TinyML wird groß Was kommt als nächstes für Cloudera? McDonald's möchte maschinelles Lernen für alle Benutzer im gesamten Betrieb “demokratisieren”Verwandte Themen:
Datenmanagement Digitale Transformation Robotik Internet der Dinge Innovation Unternehmenssoftware 