Über viele Dinge macht man sich auch als erfahrender Berater erst Gedanken, wenn man vor Ihnen steht. Ich habe in den vergangenen Jahren einige InnoDB-Cluster inkl. MySQL-Router in Betrieb genommen. Bisher war dies immer ein interaktiver Prozess, bei dem es kein Problem war, auch Passwörter von privilegierten Usern einfach (an der Konsole) einzugeben. Dass dies auch anders gehen muss, war zumindest theoretisch klar, da ja z. B. der MySQL-Operator für Kubernetes auch in der Lage ist, Router zu „deployen“. Zeit für einen Blick in die Dokumentation. 

Mehr unter: https://blog.ordix.de/mysql-router-bootstrapping-ohne-root-account

Dieser Beitrag bezieht sich auf ein Problem eines unserer Kunden, welches beim Import einer Datenbank in ein neues InnoDB Cluster entstanden ist.

Unser Kunde ist dabei, seine bestehende (veraltete) MySQL-5.5-Single-Instanz-Datenbank zu migrieren. Die Zielumgebung soll dabei aus einem Drei-Knoten-InnoDB-Cluster bestehen.

Mehr dazu können Sie unter diesem Link lesen.

Save the date!

Ich halte auf der DOAG 2020 Datenbank am 25./26.05.2020 in Düsseldorf einen Vortrag zum Thema MySQL ReplicaSets.

Mein Vortrag ist am Dienstag, dem 26.05.2020 um 10:15 Uhr: Wie ein Ei dem anderen...MySQL ReplicaSets

 Nähere Informationen zu der Veranstaltung gibt es unter:



Weitere Infos zum Thema MySQL ReplicaSets gibt es aber auch hier: Blog-Beitrag

Manchmal gibt es Situationen in denen die Daten auf ungewöhnlichen Wegen aus der Datenbank extrahiert werden müssen. Im folgenden Blog habe ich ein Verfahren beschrieben, welches sich für InnoDB-Tabellen anwenden lässt: MySQL Retter in der Not (ORDIX Blog)

Anbei ein interessanter Blog-Beitrag von meinem Kollegen Raphael Salguero zum Thema MySQL InnoDB Cluster: MySQL Shell & InnoDB Cluster

So we tested the 5.6.7-RC. And ran into a strange problem:

Because of a test, a preexisting configuration with GTID enabled existed, and suddenly we did not have properly initialized grants in mysql.* created for a new installation. Turns out: GTID and non-transactional tables are no friends, and that is even documented.

When using GTIDs, updates to tables using nontransactional storage engines such as MyISAM are not supported. This is because updates to such tables mixed with updates to tables that use a transactional storage engine such as InnoDB can result in multiple GTIDs being assigned to the same transaction.

Also, this is supposed to work with GRANT and REVOKE, but not with INSERT and DELETE. Now guess what mysql-install-db and friends are using?

server:~ # less …

Hier ist eine wichtige Zahl:

Ein Coredump von einem MySQL auf einer Maschine mit knapp unter 200G Speicher dauert 15 Minuten. Auf SSD. Auf eine Festplatte dauert der gleiche Coredump dann knapp über 30 Minuten.

Warum ist das eine wichtige Zahl?

SSD sind schnell. Linear schreiben sie mehr als 200 MB pro Sekunde weg - ein ziemlich beeindruckendes Tempo, und noch dazu in einer Disziplin, wo sie nicht einmal optimal nutzbar sind. Auch moderne Serverfestplatten sind schnell - beim linearen Schreiben immerhin knapp halb so schnell wie eine SSD, oder 100 MB pro Spindel linear.

Aber moderne Maschinen haben halt auch eine sehr große Menge Speicher. Und 200 GB bei 200MB pro Sekunde sind halt dann eine Viertelstunde pro Full Dump oder Full Scan.

In Eine reiche NoSQL-Anfragesprache macht Ulf Wendel sich …

Wer dies und dies gelesen hat, versteht mehr.

InnoDB ist eine Storage Engine, die mit Hilfe von MVCC Transaktionen implementiert. Transaktionen zu implementieren bedeutet, daß man in der Lage ist, mehrere Änderungen zusammenzufassen und als eine Einheit als gültig zu markieren oder zurück zu nehmen. Damit das Ganze trotzdem schnell ist, muß man ein wenig herumtricksen.

Angenommen, wir wollen eine Spalte in einer Zeile in der Tabelle t ändern:

UPDATE t SET x=17 WHERE id=3

Dann muß InnoDB das zunächst einmal in eine Zeilennummer in einer Speicherseite übersetzen: InnoDB speichert Daten in Seiten von 16 …

"Kris, kannst Du bitte mal gucken?"

Seit heute morgen, 10:00 Uhr, wächst das Undo Log immer weiter an.

Immer wenn InnoDB Daten schreibt wird die alte Version einer Zeile aus der Tabelle in das Undo-Log verschoben, also physikalisch von der ibd-Datei der Tabelle in die ibdata1 im Datadir von MySQL. In der Tabelle wird in der veränderten Zeile ein Zeiger von der neuen Version auf die alte Version der Zeile im Undo-Log installiert, der Roll(back)-Pointer. Die alte Version im Undo-Log zeigt mit ihrem eigenen Roll-Pointer auf eine noch ältere Version derselben Zeile und so weiter - es entsteht für jede Zeile in der Datenbank eine lineare Liste von Versionen in die Vergangenheit einer Row.

Der InnoDB Purge Thread hat die Aufgabe, das Undo Log zu verkürzen. Wenn er das nicht tut, dann sieht das so aus wie oben im Graphen gezeigt. Dafür kann es zwei Gründe geben: Purge Lag - also mehr Writes als der Purge Thread …

Golem, Heise, Pro-Linux und viele andere auch schreiben über den neuen MySQL 5.5 Release Candidate, 5.5.6.

In den Kommentaren zu den Artikeln gibt es eine Reihe von Fragen, zum Beispiel wieso MySQL 5.5 zwischen 3 und 4.6 mal schneller als 5.1.50 sein soll. Eine bessere Quelle der Information als das Presserelease von Oracle sind vielleicht diese Präsentationen von Mikael Ronstrom.

InnoDB hat, um das "A" in "ACID" gewährleisten zu können, wie jede Datenbank, einen Haufen interne …