MaxNoOfAttributes
Ich hatte ja zuvor schonmal beschrieben, daß wir einige Probleme haben, uns für eine geeignete Methode zur Skalierung unserer Datenbanken zu entscheiden. Es gibt einige Sharding-Lösungen, wie zum Beispiel HiveDB, die auf Applikationsseite implementiert werden müssen und deshalb für uns viel zu teuer sind. Es gäbe natürlich auch die Möglichkeit vertikal zu skalieren, das heißt einfach immer mehr CPUs und Platten nachzustopfen, aber das ist ineffektiv, teuer, unperformant und bietet auch keine zusätzliche Ausfallsicherheit.
Meine derzeit preferierte Lösung ist das MySQL Cluster. Bisher war es ja wohl so, daß die geclusterten Datenbankdaten komplett im Speicher vorgehalten werden mußten, weshalb diese Methode für uns mit den riesigen Datenmengen nicht in Frage kam, dies hat sich mit der aktuellen Version des MySQL Clusters aber erledigt. Das einzige Problem ist, daß die MySQL Cluster Engine keine Fremdschlüssel unterstützt, allerdings läßt sich diese Funktionalität aber auf entsprechende Trigger auslagern. Vielleicht nicht ganz so schnell, aber funktioniert wohl. Leider scheitere ich derzeit kläglich an einem ganz anderen Problem.
Jetzt habe ich also mal ein Test Cluster mit 4 NDB Nodes aufgesetzt, das folgendermaßen aussieht:
Cluster Configuration
---------------------
[ndbd(NDB)] 4 node(s)
id=2 @213.x.y.176 (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)
id=3 @213.x.y.177 (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0)
id=4 @213.x.y.178 (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)
id=5 @213.x.y.179 (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @213.x.y.180 (mysql-5.1.39 ndb-7.0.9)
[mysqld(API)] 1 node(s)
id=6 @213.x.y.180 (mysql-5.1.39 ndb-7.0.9)
Soweit so gut. Daß der mysqld auf dem Management Node läuft ist nur eine Zwischenlösung und sollte den Test erst einmal nicht behindern. Ich versuche dann als nächstes also ein aktuelles Schema zu importieren und damit fangen dann die Probleme an:
user@db0:~$ mysql -uroot -p mysql < db0_schema.sql
ERROR 1005 (HY000) at line 363: Can't create table 'datenbank.tabelle' (errno: 708)
Soweit, so schlecht. Also was bedeutet “errno: 708″?
NDB error code 708: No more attribute metadata records (increase MaxNoOfAttributes): Permanent error: Schema error
Ok, der Defaultwert 1000 ist vielleicht etwas wenig. Also flugs auf 5000 gesetzt und nochmal getestet. Und wieder ERROR 1005 (HY000) at line 363: Can't create table 'datenbank.tabelle' (errno: 708). An der exakt selben Stelle? Hm, immernoch zu wenig? Glaub ich eigentlich nicht.. aber gut, zum testen mal MaxNoOfAttributes=50000 in der [NDBD DEFAULT] Sektion gesetzt. Das half aber leider auch nicht. Der selbe Fehler an der selben Stelle.
Das kann ja nur zweierlei bedeuten:
- Entweder der Wert MaxNoOfAttributes aus der Konfiguration wird nicht verwendet
- Oder der Wert MaxNoOfAttributes ist garnicht das Problem
Tja. Und hier verließen sie Ihn. Ich habe keine Ahnung, wie man den eingestellen Wert auf Mysql-Seite kontrolliert (Im ´show status´ ist nix) oder was diesen Fehler sonst produzieren könnte.
Sollte das jemand lesen, der einen Tipp hat, dann immer gerne als Kommentar unten rein.
Anbei nochmal meine derzeitige Testkonfiguration:
[NDBD DEFAULT]
NoOfReplicas=2
DataMemory=2048M
IndexMemory=512M
MaxNoOfAttributes=5000
DataDir=/var/lib/mysql-cluster[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
Datadir=/var/lib/mysql-cluster[TCP DEFAULT]
[NDB_MGMD]
Id=1
Hostname=db0.xxx.de[NDBD]
Id=2
Hostname=db1.xxx.de[NDBD]
Id=3
Hostname=db2.xxx.de[NDBD]
Id=4
Hostname=db3.xxx.de[NDBD]
Id=5
Hostname=db4.xxx.de[MYSQLD]
Id=6
Hostname=db0.xxx.de#[MYSQLD]
#Id=7
#Hostname=db5.xxx.de
Comments