MySQL, die Qual der Wahl…
Nach einer langen Nacht voller RTFM, RFCs und diversen MySQL-Artikeln bin ich noch relativ unschlüssig.
Einerseits wäre eine Cluster die perfekte Lösung (redundant, ausfallsicher und flexibel), andererseits sind alle Maschinen mit zu wenig Arbeitsspeicher ausgerüstet um mehr als 2 Datenbanken im Arbeitsspeicher zu halten. Was leider eine Voraussetzung bei einem Cluster mit MySQL 5.0 ist. Jedenfalls hätte ich noch keine gegenteiligen Infos gefunden. Natürlich könnte ich den Server mit 5.1 oder 6.0 selber kompilieren, aber dann müsste ich mich selbst um das Patchmanagement kümmern (im Moment machen das die vielen fleißigen Packagemaintainer bei Debian 
).
Als alternative hätte ich eine Multi-Master Replikation in die engere Auswahl gezogen. Also exakt die gleiche Konfiguration, wie sie jetzt noch im Einsatz ist. Problematisch wird dieses Setup erst, wenn einer der beiden Master den Dienst versagt, aber trotzdem noch Veränderungen an den Daten passieren, weil der Client (zum Großteil PHP Anwendungen auf den Apache Servern) nicht mitbekommt, dass die Replikation aufgebrochen wurde (warum sollte er das ja auch wissen, es hat ihm ja egal zu sein ).
Vielleicht finde ich noch eine Möglichkeit, den MySQL Cluster einzusetzen, zumal ich endlich wieder so ein Teil unter meiner Fuchtel haben will Und weil ein Cluster auch das Problem des Storageservers ausschalten würde, da jede Datanode eine Kopie aller Daten des Clusters bereithalten würde. Somit wäre die I/O Belastung des Storageservers wieder verringert, da bei weitem mehr Datenbank Aktivitäten passieren, als Webzugriffe (1 Seitenaufruf verursacht zwischen 10 und 100 SQL Abfragen (Prefetch )).
Somit wird heute Nacht wieder viel gelesen, probiert und geflucht 
