Wir haben unser Datenbank-Backend Anfang 2008 geplant. Ziel war es jede Kundendatenbank jederzeit mindestens 1x repliziert zu haben. Im Notfall muss also sofort mindestens ein Standby-Server als neuer Master für den Kunden parat sein. Da wir diesen Service "intern" als Bestandteil unseres Notfallplans ansehen sollte das alles möglichst ohne Performance-Verluste und ohne zusätzliche Limitierungen für den Kunden passieren. (Trigger, SP, Views, etc.) Im Hinblick auf Backups brauchen wir weiterhin genug Flexibilität um Kunden-DBs aus verschiedenen Master->Slave Clustern in dedizierten Backup-Systemen zusammenzuführen. Dort können wir Snapshots und Dumps erzeugen ohne den laufenden Betrieb zu stören (Performance und Locking-Probleme). Replikationsketten und Kaskaden machen hier einiges erst möglich...
Nehmen wir nun mal unser typisches SharedHosting Szenario für Kunden mit BasisPaket: Pro Kunde 5 Datenbanken, die Datenbanken können vom Kunden frei benannt, gelöscht oder auch angelegt werden. Schemas sind somit frei editierbar. Täglich kommen User hinzu oder werden gelöscht. Alles in allem ein relativ dynamisches Szenario für das viele Replikations-Lösungen nicht ausgelegt sind. Damals war das der Hauptgrund warum viele (von denen als "stable" / "producion-ready" deklarierte) Postgres Replikations-Lösungen rausgefallen sind. Übrig blieben... "drei Varianten"... von Third-Party Postgres Replikatoren: (1) Interessante Vorschläge mit "proof of concept" Implementierung im Alpha Status, (2) Stabile aber extrem aufwendige Lösungen die eine gewisse Infrastruktur voraussetzen, (3) Mehrere "Bastellösungen", meist von 1-2 Entwicklern gepflegt, quasi ohne Dokumentation und mit der Zusage selbiger 1-2 Entwickler, dass die Sache stabil läuft.
(Zu (2) muss man noch sagen, dass die stabilen Sachen meistens nur mit relativ uralten Postgres Versionen zu gebrauchen waren...)
Wir waren eigentlich von Anfang an pro-Postgres, allerdings muss man sich folgendes vor Augen halten: Während wir also verschiedene dieser Implementierungen unter die Lupe nahmen (und teilweise versuchten aus Code und Code-Kommentaren schlau zu werden...) released Sun MySQL 5.1 GA.
MySQL hat seit geraumer Zeit (...Jahren...) Statement-basierte Replikation integriert. Die Implementierung hat etliche QA-Cycles durchlaufen und hunderte Bugfixes erlebt. 5.1 kommt mit Row-Based- und Hybrid Replikation sowie einigen Features daher, deren Abwesenheit für einen PostgreSQL User eigentlich immer ausschlaggebend war, bei Postgres zu bleiben...
Während wir also veschiedene Postgres Server mit diversen Lösungen im Test haben (und schon einige Rückschläge erlebten was die Recovery angeht) setzte ich zwei MySQL Server (derzeit tatsächlich aus Neugierde) auf. Dank der guten Dokumentation und der guten Integration lief das Setup nach 30 Minuten.
Lange Rede kurzer Sinn... MySQL hat alle unsere Test-Szenarios überlebt. Kompliziertere Replikations-Fehler konnten alle mit den Tools rund um die Binlogs behoben werden (ohne immer wieder einen kompletten Dump neu zu laden).
Das ganze Binlog+Relaylog Design wurde immer klarer und ebenso die riesige Flexibilität die man dazu geschenkt bekommt -- Ganz im Gegensatz zu einigen von den zuvor angetesteten Postgres Lösungen.
Die Entscheidung ist eigentlich erst nach einigen Tagen MySQL Dokumentation lesen gefallen. Man darf nicht vergessen, dass die Datenbank nur ein Puzzle-Teil unseres Hostings ist, und wir müssen als kleines Startup realistisch bleiben. MySQL war mit allen Features und der unschlagbaren Dokumentation zur richtigen Zeit am richtigen Ort, und PostgreSQL war leider enttäuschend. (Dazu kommt, dass Replikation anscheinend ein Hassthema in #postgresql ist...)
Mittlerweile haben wir eine bessere Infrastruktur und könnten uns tatsächlich wieder Gedanken um ein neues Setup machen, bei dem wir auch PostgreSQL anbieten. Ausserdem gibt es ein paar Interessante Projekte und Entwicklungen (Tungsten,
http://archives.postgresql.org/pgsql-ha ... g00913.php , Lösungen in Kombination mit DRBD, etc.) die man mal wieder unter die Lupe nehmen könnte. Das wollen wir auch nicht abstreiten...
Auf der anderen Seite haben wir von 100 Kunden maximal 2, die gerne PostgreSQL hätten. Die Beweggründe sind dann meistens sehr Klischee-behaftet aus Zeiten in denen MySQL tatsächlich in einigen Aspekten... sehr fragwürdig war. Ich kann nur jedem raten aktuelle Versionen zu Vergleichen und immer an die verschiedenen Storage Engines zu denken. Sehr oft wird genau das vergessen und es werden falsche Ansprüche an eine Storage-Engine gestellt, die tatsächlich für ganz andere Zwecke optimiert is...
Realistisch gesehen bringt uns PostgreSQL momentan nur Mehraufwand ohne überzeugende Vorteile. Deshalb bieten wir kein PostgreSQL für die BasisPakete. Die geringe Anzahl der Anfragen nach PostgreSQL spricht für sich. Falls sich an dem Verhältnis was ändert sind wir als alte PostgreSQL Fans aber gerne bereit die Sache nochmal zu überdenken.
)
Andererseits muss man sich dafür das Python 2.6 selbst kompilieren...