wall < "Erste tapsige Schritte auf dem MySQL NDB Cluster"

Broadcast message from spillerm@unixe.de (pts/1) (Fr Mai 15 10:12:02 2015):
4
Diesen Beitrag schrieb ich vor 4 Jahren. Behalte das beim Lesen bitte 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 heisst 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)

ALTER TABLEEs 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 (in nebenstehendem Munin-Screenshot nochmal visuell dargestellt).

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)

datanodes swapDoch nur wenige Spielereien später ist schon klar, dass meine data nodes überlastet sind: 2GB RAM reichen (erwartungsgemäss, 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…

4