wall < "MySQL NDB Cluster: Rolling Restart"

Broadcast message from spillerm@unixe.de (pts/1) (Mo Mai 18 09:44:25 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.

MySQL NDB Cluster datanodes swapSchon 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 schiessen wir auf management1 den Prozess ndb_mgmd tot und starten ihn anschliessend 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 anschliessend herunterfahren — grundsätzlich würde ein RESTART auf der Management-Konsole ausreichen, 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 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 äusserst sexy finde und auch gerne administriere. Krank, oder?

MarianneEs 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… :)

4