What will be the future of MySQL against the backdrop of the Oracle acquisition?


The German Oracle User Association (DOAG e.V.) has published a statement (in German) about the acquisition of Sun/MySQL by Oracle and its impact for Oracle users. You can find the statement here.

 

Oh and btw, I’ll give a session about „PHP5 & Oracle“ at the local Oracle usergroups in Frankfurt on June, 23rd and Hamburg on Sep 14th. The main goal is to promote the usage of PHP5 in Oracle environments (and how you can leverage PHP’s potential in Enterprise environments) as there are good Oracle database connectors for PHP5 available. See you there!

Sildes from „Googol Records (with MySQL)“-Session

IPC is over. My impression: The place was too big making it a little bit difficult to get in contact with others. Yet, from a technical and gastronomical point of view the Rheingoldhalle was a good choice. For the next IPC I would recommend to anker a hotel-ship near the hall (the Rheingoldhalle is situated at the bank of the river Rhine) to avoid a 30min shuttle bus ride from and to the hotel. ;-)


But back to my talk there.

The initial idea to this session was a performance consulting in spring this year: For a table with appr. 250 billion entries I found a way to store and read about 6,000 queries per second! I applied some very unusual ways to speed up a problem by factor 1,000 or 2,000 just by thinking about how I would do it, if I had to store the things in my home supposed they were real things such as cutlery.

I found out, that there are some patterns, which can be used in general and that they work for nearly every problem with very big tables. Just see for yourself how I solved the problem.

Please note: The slides could probably not be understood without explaining some of the ideas. Be free to post your questions as comment!
PS: The „C“ in the pictures is the „catalog“.
PSS: YES, we’ve uploaded a new slideshare, the pictures are now working.

Googol Data

View SlideShare presentation or Upload your own. (tags: performance database)

Is MySQL-partitioning useful for very big real-life-problems?

Some months ago I helped out in another project in which they had some performance problems. They had a very big table and the index of the table was bigger than the table itself. As every change in the table causes MySQL to recalculate/reload the index, this can take some seconds for such big tables.

So, I thought it would be a good idea to split that big table into very small ones. This should reduce the overhead of reloading big indices and instead reload only very small parts. And the next thought was: Is it possible to use the „new“ MySQL-Partitioning for that? Weiterlesen

Getting Certified with MySQL

Certifications are „in“. Nowadays you can get certifications for almost every aspect of life. Admittedly, some of those certs you can just get by surviving a boring day in a classroom or more luckily for having joined a 2 week 20k yacht trip offshore hawaii that was just regularly interrupted by attending conference speaches, workshops or lessons.

Weiterlesen

MySQL: Too many connections

Mit max_clients definiert man bei einem MySQL Server, wie viele Client Connections die Datenbank maximal akzeptiert. Wird diese Anzahl erreicht, können keine weiteren Verbindungen zur Datenbank gemacht werden und MySQL schmeißt uns den Fehler „Too many connections“ zurück.

Bei großen Applikationen wie zum Beispiel Communities oder Shopsystemen kommt es durchaus vor, dass man nicht nur die Webanwendung, vulgo das PHP hat, die auf die Datenbank zugreift. Unter Umständen gibt es noch Backend-Systeme, Batch-Prozesse, Shell-Scripte und ähnliches, die sich ebenfalls zur Datenbank verbinden wollen. In Summa greifen da also ganz schön viele verschiedene System auf die Datenbank zu. Nun muss man noch wissen, dass bei einer typischen Konfiguration aus Apache + PHP pro httpd Prozess in der Regel mindestens eine Datenbank-Verbindung offen ist (es sei denn man versucht sich mit einem Connection Pooling über SQLRelay oder MySQL Proxy). Das schöne an der „shared nothing“ Architektur von PHP ist ja, dass am Ende des Requests die Verbindung zur Datenbank wieder geschlossen wird, also wieder ein Connectionslot frei wird.

Um also zu verhindern, dass es in Spitzenlastzeiten zu der oben erwähnten Fehlermeldung kommt, muss man über alle Architekturbereiche hinweg berechnen, wie viele Verbindungen maximal zur MySQL Datenbank gleichzeitig erreicht werden könnten. Diesen Mindestwert muss man dann als max_connections eintragen. Zu Problemen kann es kommen, wenn man langlebige Prozesse (Batch-Applikationen oder irre gelaufene Prozesse, die wirr im System „stehen“, Rekursionsbugs, die n Verbindungen ungeplant öffnen usw.) hat, die entsprechend viele Verbindungen zur Datenbank „besetzen“, ob nun gewollt oder ungewollt.

 

Zu Problemen kann es aber auch kommen, wenn man Peaks in den Seitenaufrufen hat. Da ja ein httpd Prozess dann mindestens eine Verbindung zur Datenbank aufmacht, sollte über die Apache Konfigurationsdirektiven, die die Anzahl der maximalen httpd Prozesse festlegen, die Gesamtzahl der Datenbankverbindungsslots konfiguriert und damit geregelt werden.

 

Kollege Köhntopp ergänzt noch, dass zum Debugging ein „SHOW FULL PROCESSLIST“ + date ein mal pro Minute in ein Logfile eine Möglichkeit wäre, um zu monitoren, ob es Überläufe gibt. Ich meine, dass die Non-Bastelvariante, der MySQL Enterprise Monitor (Codename Merlin) aus der MySQL Enterprise Distribution, ebenfalls geeignete Mechanismen fürs Monitoring und Logging zur Verfügung stellt. Zusätzlich sollte man bedenken, dass ein max_clients auch immer noch mit einem open_files_limit einhergeht, weil jeder offene Socket natürlich auch ein Filehandle belegt. Eine Tabelle belegt 2-3 Filehandles, somit ergibt sich die knackige Formel open_files_limit = (max_clients + table_cache * 2 bis 3).

mod_magnet, lighty, MySQL Proxy und überhaupt

Der von mir sehr geschätzte Kollege Jo Brunner hat mal wieder tief in die Trickkiste gegriffen, und im Rahmen seiner Xenjo Cache Registry den wertvollen Urlaub dafür verwendet (Chapeau!), sich ausführlich mit lighttpd, mod_magnet und lua zu beschäftigen. Näheres findet man auf seinem Blog

 

Überhaupt lohnt sich ein Blick auf all das, was Jan Kneschke (der Autor von lighttpd) so baut. Wer mit MySQL einiges an Schweinereien vorhat (zum Beispiel Sharding, Verteilung von DB-Queries auf Master & Slaves), der sollte sich im Übrigen MySQL Proxy ansehen. MySQL Proxy ist ein Query Interceptor und sitzt zwischen dem Client (also zum Beispiel dem PHP) und dem Datenbankserver. Gesteuert wird MySQL Proxy wie üblich mit lua, der kleinen wendigen Scriptsprache. Man kann also Queries on the fly umschreiben oder auf andere DB-Server „redirecten“. Ein Vorteil dabei: man muss seinen Anwendungslayer nicht anpassen, um die INSERTs/UPDATEs und DELETEs auf den Master zu richten und die SELECTs auf die Slaves – das erledigt MySQL Proxy mit einem passenden kleinen lua-Script.

Web-2.0 Security

Hi Folks,

This is an announcement for a webinar in German. Therefore only written in German. If you are interested in the security topic be sure to see the english webinar, which is stored here.


Web-2.0-Anwendungen absichern

Die verbesserte Einsatztauglichkeit der Web-2.0-Anwendungen wird auf
Kosten von neuen Sicherheitsproblemen erworben. Sowohl die mächtige
Logik im JavaScript als auch der permanente Login auf vielen Sites
bergen Risiken, die anders und gezielt beantwortet werden müssen.
Dieses Webseminar gibt einen Überblick, bewertet die Probleme und
stellt Lösungswege vor.

Wenn Sie Web 2.0- und AJAX-Anwendungen entwickeln, ist dieser Vortrag genau das Richtige für Sie! Hier erfahren Sie:

  • Welche neuen Sicherheitsrisiken es für Webanwendungen gibt
  • Welche Bedeutung XSS hat
  • Ursprünge und Typen von JavaScript-Malware
  • Wege zur Absicherung Ihrer LAMP-Anwendungen für Web 2.0

Weiterlesen