Ich werde in Seminaren, Workshops oder in Kundenprojekten in Sachen MySQL immer mal wieder mit Dingen konfrontiert, auf die ich ad hoc keine Antwort habe bzw. mit denen ich noch keine Erfahrung gesammelt habe. 

Das Problem

In dieser Folge hat ein Teilnehmer danach gefragt, ob man mit der MySQL Shell auch direkt in die Cloud bzw. auf einen S3-kompatiblen Storage schrieben kann.

Zur Beantwortung der Frage nutze ich wie fast immer meine Docker Umgebung. Neben dem Standard MySQL Image [1] nutze ich zur Simulation eines S3-Storage-Systems das Image von MinIO [2]. Über die grafische Oberfläche habe ich mir für meinen Test einfach ein Bucket (mybackup) inkl. der zugehörigen Berechtigungsstruktur (User, Group, Access Key) „geklickt“.

Beide Container „hängen“ in Docker im gleichen Netz und können miteinander kommunizieren:

• Hostname „sakila“ beinhaltet die MySQL Instant und die MySQL Shell
• Hostname „minio“ beinhaltet unser S3-Storage
  

Die Lösung

Der MySQL Container erfüllt alle Voraussetzungen für den Test. Die Instanz läuft und eine Testdatenbank ist schnell geladen. Ich nutze für solche Fälle gerne die altbekannte Testdatenbank „sakila“, die auf der MySQL-Seite bereitgestellt wird [3]. Die MySQL-Shell ist ebenfalls bereits Bestandteil des Images.

Nach kurzer Recherche ist klar, dass die Shell für die Dump-Anweisung die notwendigen Berechtigungen für den Zugriff auf den S3-Storage benötigt. Die kann über entsprechende (im AWS-Umfeld bekannte) Konfigurationsdateien oder auch über Umgebungsvariablen der Shell erledigt werden. Für diesen Test habe ich mich für die zweite Variante entschieden:

 Zusätzlich zu den benötigten Keys zur Authentifizierung benötigt die Shell ebenso zwingend die Regio des Storage-Systems. Mit einer entsprechend vorbereiteten Shell, konnte der nächste Schritt in Angriff genommen werden: Der Dump!

Im ersten Schritt war es das Ziel nur das Schema „sakila“ zu sichern.

Die Methode "dumpSchemas" erwartet drei Argumente:

1. Ein Array mit einer Aufzählung der Schemata; hier nur „sakila“
2. Ein Ordner / Pfad, der im Bucket erzeugt werden soll
3. S3-Konfigurationsparameter (über die Shell-Umgebungsvariablen hinaus)
        a. Names des Buckets
        b. URL des Endpoints

Natürlich sind weitere, umfangreiche Konfigurationsmöglichkeiten gegeben, die entweder den Dump an sich [4] oder aber den S3-Storage [5] betreffen, möglich.

Natürlich ist auch ein Dump der gesamten Instanz möglich. Syntaktisch gibt es hier keine Überraschungen. Anstatt der Schemata wird ein Name für die Instanz (hier „produktion“) festgelegt. Um zu zeigen, dass auch weitere Parameter denkbar sind, wurde in diesem Beispiel die folgenden Optionen für den Dump-Prozess aufgenommen:

• showProgress; während des Dump-Vorgangs gibt es eine Fortschrittsanzeige.
• threads; Grad der Parallelität, mit welcher der Dump erzeugt werden soll.

Fazit

Die Dokumentation ist generell nicht immer hilfreich bzw. einfach zu lesen. Generell ist es aber mit ein bisschen „Try“ & „Error“ möglich, schnell ein erstes Ergebnis zu erreichen. Und darum gibt es in diesem Beispiel. Die Frage, ob man mit der Shell direkt in die Cloud bzw. auf einen S3-Storage „dumpen“ kann, ist beantwortet. Vor einem produktiven Einsatz sollten noch viele weitere Fragen gestellt und beantwortet werden (Performance, Sicherheit, …).

Sie haben eine Frage und/oder ein Problem mit MySQL? Schreiben Sie Ihr Anliegen in die Kommentare und wir melden uns zeitnah bei Ihnen!

Seminarempfehlung