4 Minuten Lesezeit (738 Worte)

Kurz und gut - Episode #01 MySQL Dumps in die Cloud

Freitag, 21. April 2023

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:

SAKILA> export AWS_ACCESS_KEY_ID=lx0CCjegkecAh6yU
SAKILA> export AWS_SECRET_ACCESS_KEY=UhyWlfvHsXCpUZsoctocxlVTYK4zBFcX
SAKILA> export AWS_REGION=eu-north-1

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.

SAKILA> mysqlsh -uroot -proot -hlocalhost --quiet-start=1

Your MySQL connection id is 3170
Server version: 8.0.32 MySQL Community Server - GPL
No default schema selected; type \use <schema> to set one.

MySQL  localhost  JS > util.dumpSchemas(['sakila'], 'sakila_230308', {'s3BucketName': 'mybackup', 's3EndpointOverride': 'http://minio:9000'})
Acquiring global read lock
Global read lock acquired
Initializing - done
1 schemas will be dumped and within them 16 tables, 7 views, 6 routines, 6 triggers.
Gathering information - done
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Running data dump using 4 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
99% (47.28K rows / ~47.69K rows), 0.00 rows/s, 0.00 B/s uncompressed, 0.00 B/s compressed
                                                                               Dump duration: 00:00:00s
                                                                               Total duration: 00:00:00s
                                                                               Schemas dumped: 1
                                                                               Tables dumped: 16
                                                                               Uncompressed data size: 3.03 MB
                                                                               Compressed data size: 715.45 KB
                                                                               Compression ratio: 4.2
                                                                               Rows written: 47277
                                                                               Bytes written: 715.45 KB
                                                                               Average uncompressed throughput: 3.03 MB/s
                                                                               Average compressed throughput: 715.45 KB/s
 MySQL  localhost  JS >

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.

MySQL  localhost  JS > util.dumpInstance('produktion', 
{'s3BucketName': 'mybackup', 's3EndpointOverride': 
'http://0c0e6d2f83e7:9000', 'showProgress': 'true', 'threads': 8})

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!