MySQL Proxy auf dem 8. MySQL UserGroup Treffen
Gestern war nach der Sommerpause endlich mal wieder ein MySQL Anwendertreffen. Wie immer im Ni-Hao in Wandsbek. Neben den üblichen Verdächtigen war diesmal Jan Kneschke dabei und hat einen Vortrag über MySQL Proxy gehalten. MySQL Proxy ist ganz grob gesehen eine Alternative für SQL Relay. Wobei "Alternative" hier eigentlich das falsche Wort ist. Denn MySQL Proxy ist in meinen Augen einfach besser. Nur die Idee ein Stück Software zwischen dem Client und der Datenbank zu haben ist gleich. Der MySQL Proxy macht hier aber alles "richtig", was bei SQL Relay stört.
MySQL Proxy ist ein eigener Daemon und sieht für die Applikation aus wie die Datenbank selbst. Abgesehen davon, dass der Proxy auf Layer 3 nicht zu verstecken ist (IP Adressen ...) wird die Applikation ihn nicht bemerken (außer man will es so).
Der Kern des Programms arbeitet eventbasiert, so dass auch 10.000 parallele Verbindungen (c10k) kein Problem darstellen. Der Kern erfüllt die Grundfunktion, alles weitere (Query Rewriting, Injection, etc.) wird über LUA Scripte erledigt. LUA ist eine Scripting Sprache, die speziell für das embedden in anderen Programmen entwickelt wurde und dabei eine sehr gute Performance bietet. Dadurch, dass man ein- und ausgehende Queries per Script bearbeiten kann sind dem Einsatzzweck des Proxies eigentlich keine Grenzen gesetzt.
Eines der Einsatzgebiete, welches für mich interessant ist, ist es den Proxy einzusetzen um einen Reader-Writer-Split zu realisieren ohne die Applikation anzupassen. Diese Technik zum Skalieren des Datenbanklayers ist gewönhlich der erste Schritt, den man geht wenn ein Datenbankserver die Last nicht mehr handeln kann. Schritte wie das Partitonieren der Daten würden erst später kommen, können aber mit dem MySQL-Proxy wahrscheinlich auch transparent für die Applikation realisiert werden, man muss nur die richtigen LUA Scripte schreiben.
Auch wenn ich den MySQL Proxy noch nicht eingesetzt habe, glaube ich dass er einige Probleme lösen kann, um die ich mich sonst im Applikations-Code kümmern müsste. Definitiv werde ich den Proxy (sobald Version 0.6.0 raus ist) mal zusammen mit dem Django Framework testen und von den Ergebnissen berichten. Ich denke, dass der MySQL Proxy einige Bemühungen der Entwickler in der multiple-db-support Branch überflüssig machen könnte, aber das werde ich mir noch mal im Detail anschauen.
Hallo
Bin zufällig auf diese Seite gekommen, was für ein Glück. Hat mir sehr weiter geholfen.
Geschrieben von jeannine 3 Tage, 5 Stunden nach Veröffentlichung des Blog-Eintrags am 7. Sept. 2007, 18:05. Antworten
auf http://forge.mysql.com/wiki/MySQL_Proxy_FAQ steht:
"Currently (0.6.0) there is no separation between read and writes and it is up the user to make sure that only reads are sent to the proxy."
wie krieg ich jetzt dann doch so ein read/write splitting hin?
dennoch war der artikel bisher schon hilfreich da er mich auf "sql relay" verwiesen hat ;-)
Geschrieben von sven 1 Monat nach Veröffentlichung des Blog-Eintrags am 9. Okt. 2007, 19:48. Antworten
Ich habe seit einigen Tagen den mysql-proxy im Testbetrieb und kann sagen, dass er mir generel auch besser gefällt als sqlrelay.
zumal die Installation und konfiguration einfacher ist.
Allerdings waren die ersten Benchmarks mit sql-proxy erher bescheiden.
So ergab sich z.b. das sich die Script Execution time verdopelte und der Speicher verbrauch unter last von sql-proxy ins bodenlose lief.
Für das Partitonieren der Daten gibt es ein sql-proxy plugin siehe->
http://www.hscale.org/
Best Regards
Andreas
Geschrieben von Andreas 10 Monate nach Veröffentlichung des Blog-Eintrags am 6. Juli 2008, 03:30. Antworten
Wie stabil ist mysql proxy eigentlich? Ich setze ungern Alpha Releases auf Produktivsystemen ein, aber scheinbar kommt mysql proxy nicht aus dem Alpha Stadium raus?
Geschrieben von Lars 1 Jahr, 11 Monate nach Veröffentlichung des Blog-Eintrags am 5. Aug. 2009, 19:12. Antworten