Erste tapsige Schritte auf dem MySQL NDB Cluster
Diesen Beitrag schrieb ich 9 Jahre und 5 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Weitere Beiträge der Artikelserie „MySQL NDB Cluster“ findest du an dieser Stelle.
Unser Setup steht: wir haben ein MySQL-NDB-Cluster in VirtualBox eingerichtet, wir haben die User und deren Berechtigungen darauf verteilt und eine einfache Lastverteilung implementiert. Nun ist es an der Zeit, mal ein paar Daten einzufüttern und mit der Landschaft zu spielen. Zum Testen habe ich mir ein Backup meiner DSPAM-Datenbank geschnappt; ungepackt hat es 30MB.
root@webserver:~# du -sch /tmp/localhost-dspam-2015-05-12.sql
30M /tmp/localhost-dspam-2015-05-12.sql
30M total
Zuerst legen wir uns eine Datenbank dspam an sowie den User dspam mit unsicherem, aber leicht zu tippendem Passwort ;) Er erhält vollen Zugriff auf diese Datenbank.
root@datanode1:~# mysql -u root -p --prompt 'datanode1> '
datanode1> create user 'dspam'@'10.0.2.%' identified by 'dspam';
Query OK, 0 rows affected (0.08 sec)
datanode1> create database dspam;
Query OK, 1 row affected (0.08 sec)
datanode1> grant all privileges on dspam.* to 'dspam'@'10.0.2.%';
Query OK, 0 rows affected (0.07 sec)
datanode1> flush privileges;
Query OK, 0 rows affected (0.00 sec)
Von datanode2 aus können wir nun schauen, ob unser User in mysql.user sichtbar ist – ist er aber, wunderbar! (Hätten wir unsere Berechtigungen nicht verteilt, müsste der User auf allen Knoten einzeln angelegt werden.) Von einem unabhängigen Linux-System (meines heißt webserver) verbinden wir uns nun mal als User dspam:
root@webserver:~# mysql -h mysql -u dspam -p
Enter password:
...
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| dspam |
+--------------------+
2 rows in set (0.00 sec)
Es funktioniert! Nun füttern wir mal unseren Datenbank-Dump ein – 30MB, in meinem Fall dauerte das tatsächlich eine ganze Weile. Nun ist es ja so, dass ich hier einen bestehenden DB-Dump einspiele – die ENGINE der Tabellen steht in meinem Fall auf InnoDB. Sprich: die Datenbank ist auf allen Knoten verfügbar, die Tabellen jedoch nicht. Mit einem ALTER TABLE setzen wir die ENGINE auf NDBCLUSTER um, was die Tabellen auf allen Knoten verfügbar macht.
root@webserver:/tmp# mysql -h mysql -u dspam -p < localhost-dspam-2015-05-12.sql
mysql> SELECT TABLE_NAME, ENGINE
-> FROM information_schema.TABLES
-> WHERE TABLE_SCHEMA = 'dspam';
+----------------------+--------+
| TABLE_NAME | ENGINE |
+----------------------+--------+
| dspam_preferences | InnoDB |
| dspam_signature_data | InnoDB |
| dspam_stats | InnoDB |
| dspam_token_data | InnoDB |
| dspam_virtual_uids | InnoDB |
+----------------------+--------+
5 rows in set (0.00 sec)
mysql> ALTER TABLE dspam_preferences ENGINE=NDBCLUSTER;
Query OK, 11 rows affected (0.38 sec)
Records: 11 Duplicates: 0 Warnings: 0
… Für alle Tabellen wiederholen…
mysql> SELECT TABLE_NAME, ENGINE
-> FROM information_schema.TABLES
-> WHERE TABLE_SCHEMA = 'dspam';
+----------------------+------------+
| TABLE_NAME | ENGINE |
+----------------------+------------+
| dspam_preferences | ndbcluster |
| dspam_signature_data | ndbcluster |
| dspam_stats | ndbcluster |
| dspam_token_data | ndbcluster |
| dspam_virtual_uids | ndbcluster |
+----------------------+------------+
5 rows in set (0.00 sec)
Doch nur wenige Spielereien später ist schon klar, dass meine Data Nodes überlastet sind: 2GB RAM reichen (erwartungsgemäß, aber naja) nicht aus, und auch die in der config.ini hinterlegten Werte waren zu knapp bemessen. Im nächsten Schritt werden wir uns dieser Probleme annehmen – inklusive eines Rolling Restart unseres Clusters…
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
