Hallo,
wie kalkuliert man die notwendigen Hardware-Resourcen (Ram, CPU, Anzahl
der Nodes) für einen MySQL Cluster? Gibt es da bereits Benchmarks, was
z.B. ein Cluster mit 2, mit 4 und mehr Nodes leisten kann?
Danke,
Oliver
Am 04.06.2007 11:45 schrieb Oliver Benning:
> Hallo,
>
> wie kalkuliert man die notwendigen Hardware-Resourcen (Ram, CPU, Anzahl
> der Nodes) für einen MySQL Cluster? Gibt es da bereits Benchmarks, was
> z.B. ein Cluster mit 2, mit 4 und mehr Nodes leisten kann?
>
Ohne zu wissen, was die Anwendung tut, welche/wieviele Daten zu
verarbeiten sind - also ohne *irgendwelche* Rahmenbedingungen? Ich
glaube kaum.
Das könntest Du Dir auch selbst überlegen. Klarerweise dürfte eine
Anwendung, die ausschließlich ein bestimmtes, präpariertes SELECT auf
einer im Speicher liegenden Tabelle ausführt, deutlich weniger
anspruchsvoll sein als eine, die viele verschiedene INSERTs, UPDATEs
und DELETEs sowie transaktionierte SELECTs auf InnoDB-Daten ausführt.
"Oliver Benning"
>
> wie kalkuliert man die notwendigen Hardware-Resourcen (Ram, CPU, Anzahl
> der Nodes) für einen MySQL Cluster?
Da MySQL Cluster die Daten im RAM hält (5.1 kann BLOBs auch auf der
Platte ablegen), kannst du dir das leicht selber ausrechnen:
RAM ~= Rohdaten * 1.2 * #replicas / #nodes
Soviel RAM wird *nur für die Daten* je Node benötigt. Außerdem brauchen
OS und Programme noch RAM. Also nicht knauserig sein. Plattenplatz
brauchst du mindesten 10x so viel (REDO-Logs, Checkpoints, Backups).
Unter 4 Nodes brauchst du IMHO gar nicht erst anzufangen.
> Gibt es da bereits Benchmarks, was
> z.B. ein Cluster mit 2, mit 4 und mehr Nodes leisten kann?
Das ist *sehr* von der Anwendung abhängig. Aber 10.000 Transaktionen
pro Sekunde sollen drin sein. Allerdings muß man dann direkt mit dem
Cluster reden (nicht den Umweg über den MySQL-Server gehen).
MySQL Cluster ist ziemlich speziell; wenn du nicht ganz genau weißt
was du tust (es scheint nicht so) - investiere das Geld für das
Cluster Jumpstart Paket:
http://www.mysql.com/consulting/packaged/cluster.html
Wenn das nur so zum Spaß ist: lies erst mal *alle* verfügbare Doku.
XL
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
On 4 Jun., 16:01, Axel Schwenke
> Unter 4 Nodes brauchst du IMHO gar nicht erst anzufangen.
Wie muss ich denn das Verstehen? Gibt es da eine logische Erklärung
für? Ich teste gerade einen MySQL Cluster mir 2 NDB Nodes und würde
gerne wissen, wie sich 4 Nodes auswirken würden.
Dennis Hecken
> On 4 Jun., 16:01, Axel Schwenke
>> Unter 4 Nodes brauchst du IMHO gar nicht erst anzufangen.
>
> Wie muss ich denn das Verstehen? Gibt es da eine logische Erklärung
> für? Ich teste gerade einen MySQL Cluster mir 2 NDB Nodes und würde
> gerne wissen, wie sich 4 Nodes auswirken würden.
Auch wenn es theoretisch möglich ist, einen zwei-Knoten Cluster
mit NoReplicas=1 aufzusetzen, habe ich das in der Realität noch
nie gesehen. Ein zwei-Knoten System ist also immer eine Mirror-
Konfiguration.
Ein solcher Mirror bietet performancetechnisch aber keinerlei
Vorteile gegenüber einem Einzelknoten. Im Gegenteil. Lesezugriffe
gehen immer über den primären Node einer Nodegroup (eine Nodegroup
umfaßt alle Knoten, die die gleichen Daten speichern). Schreib-
zugriffe gehen seriell an die Knoten einer Nodegroup. Die Schreib-
performance ist also sogar schlechter als bei einem Einzelknoten.
Mit 4 Nodes kannst du zwei Nodegroups aufbauen. Jetzt verteilen
sich Lesezugriffe schon mal auf 2 Knoten (die primaries jeder
Nodegroup). Die Schreibperformance ist identisch zu 2 Knoten.
Wie ich schon mehrfach gesagt habe, ist MySQL Cluster eine
"besondere" Spezies. Es ist eher ein HP- als HA-Cluster.
Insbesondere erreicht MySQL-Cluster extremen Schreibdurchsatz.
Größenordnungen um 10.000 Transaktionen pro Sekunde sind möglich.
Wenn es rein um HA geht, ist InnoDB auf DRDB/Heartbeat eine
schicke Kombination.
XL
Am Fri, 06 Jul 2007 00:59:07 +0200 schrieb Axel Schwenke:
> Wenn es rein um HA geht, ist InnoDB auf DRDB/Heartbeat eine schicke
> Kombination.
Spricht bei so einem Setup eigentlich etwas gegen die Verwendung von
Replikation statt DRBD, abgesehen davon dass ein Fallback vom Slave
zurück auf den Master nicht ohne Eingriff des Admins möglich ist?
Norbert
Norbert Tretkowski
> Spricht bei so einem Setup eigentlich etwas gegen die Verwendung von=20
> Replikation statt DRBD, abgesehen davon dass ein Fallback vom Slave=20
> zurück auf den Master nicht ohne Eingriff des Admins möglich i=
st?
Idealerweise wuerde man dabei die Google-Patches(*) verwenden, die
sicherstellen, dass mindestens ein Slave die gleichen Daten committed hat,
wie der Master, so dass man dann wirklich ohne Datenverlust auf genau dies=
en
Slave umswitchen kann.
(*) http://code.google.com/p/google-mysql-tools/wiki/Mysql4Patch es
-> SemiSyncReplication
=20
(*) gibt's z.Z. offiziell nur fuer 4.0 - ja, das ist natuerlich eigentlich
ein KO-Kriterium
Norbert Tretkowski
> Am Fri, 06 Jul 2007 00:59:07 +0200 schrieb Axel Schwenke:
>> Wenn es rein um HA geht, ist InnoDB auf DRDB/Heartbeat eine schicke
>> Kombination.
>
> Spricht bei so einem Setup eigentlich etwas gegen die Verwendung von
> Replikation statt DRBD, abgesehen davon dass ein Fallback vom Slave
> zurück auf den Master nicht ohne Eingriff des Admins möglich ist?
MySQL-Replikation und DRBD sind zwei grundverschiedene Lösungen und
keineswegs direkt austauschbar:
Replikation:
+ mehrere Slaves möglich
+ Slave kann read-only genutzt werden
+ man kann Aktionen, die die Datenbank blockieren (z.B. ALTER TABLE)
gezielt auf dem jeweils passiven Node machen
- asynchron
- automatisches Failover ist schwierig, Failback noch schwieriger
- beim Failover gehen ziemlich sicher Transaktionen verloren
DRDB:
+ synchron
+ schlüsselfertige Lösung mit Heartbeat (mit Support von MySQL)
- nur zwei Knoten
- prinzipiell aktiv/passiv
XL