MySQL: master-slave auf einem Server mit ramfs?

[mistersixt]

Guude,

ich habe folgendes Setup: zwei Server mit je 64 GB RAM, reichlich CPUs und /var/lib/mysql/ auf einem RAID-10 mit je 4 SAS-Platten. Rechner DB1 ist der MySQL-Master, DB2 der MySQL-Slave. Die Datenbank ansich ist ca. 30 GB gross. Soweit so gut.

Nun ist die Sofware, die auf DB1 läuft und auf den MySQL-Master zugreift, relativ zeitkritisch: manche Abfragen oder Speichervorgänge, die mehr als 0.5s oder 1s Sekunde dauern, sind eher unerwünscht. Nun habe ich mir überlegt, die Datenbank komplett in einer Ramdisk laufen zu lassen (genug Speicher ist ja vorhanden), und parallel auf dem gleichen Server einen zweiten Slave zu starten, so dass man im Falle eines Reboots immer noch einen konsistenten Stand auf dem RAID hat. Das Setup wäre also:

- DB1 MySQL-Master (DB in der Ramdisk)
- DB1 MySQL-Slave1 (DB auf RAID-10)
- DB2 MySQL-Slave2 (DB auf RAID-10)

Ich habe erstmal nur so eine MySQL-DB auf einem Testrechner komplett im RAM laufen lassen ... und das ist natürlich im Vergleich zu einem RAID pfeilschnell!

Hat Jemand mit so etwas schon mal Erfahrungen gesammelt?

Danke und Gruss, mistersixt.

[syssi]

Spricht etwas dagegen den MySQL-Server so zu parametrisieren, dass er alle Anfragen aus dem RAM beantworten kann? Ein tmpfs im Arbeitsspeicher nutzt man normalerweise nur, wenn man die Software oben drauf nicht dazu ueberreden kann freundlich zur Festplatte zu sein und Arbeitsspeicher zu nutzen. InnoDB und MyISAM kann man in der Regel soweit mit Cache (Arbeitsspeicher) versorgen, dass die Festplatte kaum mehr was tun muss. Bei vielen Schreibvorgaengen sieht es etwas anders aus.

[mistersixt]

Falls noch Jemand mal auf die Idee kommt --> heute mal das Ganze auf einem Testrechner durchgespielt:

o) Master-DB liegt komplett in einer ramdisk (hier 20 GB Daten, zu Tests in eine 25 GB ramdisk gepackt).
o) Slave-DB schreibt auf ein RAID-10 (mit 4 SSDs)
o) MySQL-Daemon 1 als Master macht Binary-Log und hat dedizierten Socket, PID und Port.
o) MySQL-Daamon 2 als Slave mit eigenem Log, PID, Socket, PID und Port.

Vorteil: genialer Speed (der RAM-Durchsatz ist mit 12 GB/s logischerweise wesentlich schneller als die 2 GB/s vom RAID, der schnelle Seek noch dazu).

Nachteil: beim Serverausfall muss man hoffen, dass alle Records in der Slave-DB gelandet sind. Und beim Neustart bedarf es eines speziellen Startscripts, das die DB vom Slave wieder in die ramdisk kopiert und die beiden MySQL Daemon und anschliessend die Replikation wieder startet, aber das klingt jetzt nicht sehr kompliziert.

Gruss, mistersixt.

[heisenberg]

Wie sieht es denn mit Lese- und Schreiblast aus?
Ist nur die Leseperformance wichtig, oder ist der Fokus auf Schreibperformance oder beides?

[mistersixt]

Schlussendlich beides: es gibt ab und an Requests, die viele Daten aus der DB grabbeln, und es gibt welche, die zu gewissen Zeitpunkten viele Daten in die DB kübeln wollen. Da die Applikation, die auf die DB zugreift, sehr zeitkritisch ist, habe ich aktuell in Extremsituationen grössere Delays, daher kam mir die Idee mit der ramdisk und der Replikation auf ein und demselben Server (und zur Not parallel noch einen zweiten Slave auf einem anderen Server, war hier mehr eine "Machbarkeitsstudie" ).

Gruss, mistersixt.

[heisenberg]

Mal so grundsätzlich würde ich mit dem Ratschlag von Syssi beginnen. Hast Du den MySQL schon gut auf die Speicherumgebung eingestellt?

..., und es gibt welche, die zu gewissen Zeitpunkten viele Daten in die DB kübeln wollen.

Ok, der ein oder andere Prozess schreibt auch viel in die DB. Muss das auch in Höchstgeschwindigkeit sein? Ist es extrem wichtig, dass die Leseprozesse zeitnah/in Echtheit an die geschriebenen Daten kommen?

Mal so 'ne Idee:

Ich würde vielleicht lieber den Slave in der Ramdisk laufen lassen und den Master auf dem RAID. Der Slave wird dann beim booten jedesmal neu initialisiert. Davor hängt dann ein Loadbalancer, der auf den Slave umschaltet, sobald der einsatzbereit ist. Anwendungen die den schnellen Lesezugriff benötigen gehen auf den Loadbalancer. Schreibvorgänge gehen immer auf den Master.

[mistersixt]

Mal so 'ne Idee:

Ich würde vielleicht lieber den Slave in der Ramdisk laufen lassen und den Master auf dem RAID. Der Slave wird dann beim booten jedesmal neu initialisiert. Davor hängt dann ein Loadbalancer, der auf den Slave umschaltet, sobald der einsatzbereit ist. Anwendungen die den schnellen Lesezugriff benötigen gehen auf den Loadbalancer. Schreibvorgänge gehen immer auf den Master.

Ja, die Idee hatte ich auch schon, aber die Applikation kann bisher nicht auf 2 DBs parallel zugreifen, um die Schreib- und Lesenzugriffe zu verteilen, da muss ich aber wohl mal einen grossen Wunsch aussprechen .

[hec_tech]

Lass mal mysqltuner deinen MySQL überprüfen dann siehst du eh ob du mit Optimierungen weiterkommst.
Wobei so kleine Datenbanken eigentlich keine Probleme machen sollten eventuell ist die DB nicht richtig entworfen worden und es fehlen Indexes.
Auf jeden Fall kontrollieren welche Queries abgesetzt werden. Lese und Schreibezugriffe auf jeden Fall mit Proxy trennen das bringt schon mal einiges.
Meistens sind irgendwelche softbuffer zu klein definiert. Das kann bei Abfragen dann zu langen Abfragezeiten führen.
Wie viele IOPs macht die Datenbank denn am Storage? Eventuell einfach SAS durch SSDs ersetzen damit sollten die IOPs sicher um ein vielfaches verbessert werden.