MySQL NDB Cluster: Rolling Restart
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.
Schon nach einigen wenigen Testläufen zeichnete sich ab, dass ich die Grenzen für meine Clusterknoten zu eng gesteckt hatte: die data nodes nutzten eifrig ihren swap, und auch MEMORYUSAGE vermeldete, dass mehr Ressourcen dem System gut tun würden.
ndb_mgm> ALL REPORT MEMORYUSAGE
Node 3: Data usage is 61%(1579 32K pages of total 2560)
Node 3: Index usage is 18%(433 8K pages of total 2336)
Node 4: Data usage is 61%(1579 32K pages of total 2560)
Node 4: Index usage is 18%(433 8K pages of total 2336)
Ich entschied mich dazu, die Konfiguration zu überarbeiten und mein MySQL NDB Cluster ohne Ausfallzeiten durchzustarten (Rolling Restart), dazu auf beiden Management Nodes die /var/lib/mysql-cluster/config.ini überarbeiten:
[...]
## DataMemory=80M
DataMemory=512M
## IndexMemory=18M
IndexMemory=64M
[...]
Nun schießen wir auf management1 den Prozess ndb_mgmd tot und starten ihn anschließend mit der Option --reload neu. Sobald der Dienst wieder fehlerfrei läuft (und erst dann!) tun wir auf management2 genau das gleiche. Von der Management-Konsole aus können wir nun datanode1 stoppen und anschließend herunterfahren – grundsätzlich würde ein RESTART auf der Management-Konsole ausreichend, aber mehr RAM kann der Maschine nicht schaden.
ndb_mgm> 3 STOP
Node 3: Node shutdown initiated
Node 3: is being stopped
Sobald die Maschine aus ist, sprechen wir ihr in VirtualBox mehr RAM zu – ich hab mal auf 3GB erhöht – und starten sie wieder, wodurch der ndbd automatisch gestartet wird. Ein --initial habe ich an der Stelle nicht mitgeben müssen (vgl. auch restart types). Rufen wir uns auf einem der Management Nodes nun die Werte von MEMORYUSAGE sehen wir, dass datanode1 die geänderte Konfiguration erfolgreich nutzt:
ndb_mgm> Node 3: Started (version 7.4.6)
ndb_mgm> ALL REPORT MEMORYUSAGE
Node 3: Data usage is 9%(1579 32K pages of total 16384)
Node 3: Index usage is 5%(433 8K pages of total 8224)
Node 4: Data usage is 61%(1579 32K pages of total 2560)
Node 4: Index usage is 18%(433 8K pages of total 2336)
Mit datanode2 muss nun identisch verfahren werden: stoppen, herunterfahren, mehr RAM konfigurieren, hochfahren. Natürlich Logfiles beobachten. Im Idealfall sind alle Maschinen up&running, die Data Nodes haben mehr RAM als vorher, die MySQL NDB-Konfiguration wurde überall übernommen – und es gab keine Ausfälle…
ndb_mgm> ALL REPORT MEMORYUSAGE
Node 3: Data usage is 9%(1579 32K pages of total 16384)
Node 3: Index usage is 5%(433 8K pages of total 8224)
Node 4: Data usage is 9%(1563 32K pages of total 16384)
Node 4: Index usage is 5%(433 8K pages of total 8224)
Auf Ex-Twitter wurde mir neulich gesagt, dass ich 5 EUR in die Fluchkasse stecken muss, weil ich den Begriff Cluster verwendet hatte :D Ich muss an dieser Stelle allerdings gestehen, dass ich solcherlei Cluster-Setups äußerst sexy finde und auch gerne administriere. Krank, oder?
Es wird noch kranker: im nächsten Schritte setzte ich auf dem iMac das Setup identisch auf – und realisierte sozusagen eine Geographic Master-to-Master-Replication zwischen meinen beiden Workstations. Das ist nun der Punkt, an dem (sogar!) meine Ressourcen knapp zu werden beginnen: der iMac mit seinen nur 16GB RAM beginnt ein wenig zu pfeifen, und wenn beim Import einer Datenbank alle Knoten „anspringen“ wird es sowohl unterm Schreibtisch als auch darauf recht kuschelig. Davon dann bald mehr… :)
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
