Das Problem bei nur einem Master ist ja, dass der ganz alleine alle Writes und die Replikationen zu seinen Slaves bewältigen muss. Also einfach noch eine Zwischenschicht mit Master/Slave-Servern (im Fachjargon auch als Bastard bezeichnet ;-). Hier mal am Beispiel wie wir unsere swebflex- und Mail-Server betreiben:

* Master
* Bastard1
* Slave1
* Slave2
* Slave3
* Bastard2
* Slave4

Dabei steht der Bastard2 an einer Zweitlocation. Gelesen wird nur von den Slaves, geschrieben nur auf den Master. Dieser Aufbau

Ich vermute, der Grund warum Ihr das nicht macht, ist schlicht der hohe Schreibtraffic. In unserem Fall ist der Master eine vier Prozessorige Xeon-Kiste mit mehreren GB RAM, einem 6 Platten SCSI-RAID-5-Storage und einem vernünftigen Betriebssystem.

Ich würde euer Problem auch genau so angehen wie Leo und “Ich” es beschrieben haben. (Btw:ich bin nicht “Ich” )

1. Splitten der DB in Unterbereiche.
Z.Bsp. fiona=Chat, rachel=Bilder usw.
so kommt man zwar um eine Replikation der Daten nicht herum, kann diese aber euf ein paar wenige Tabellen minimieren. Die Usertabelle wird zum Beispiel sicher auf allen Servern benötigt. Was aber wenn der User sich ganz frisch angemeldet hat und loschatten will, die Daten aber noch nicht auf den Chat server repliziert worden sind ? Hier müsste man dann halt einen Failover programmieren, dass eine 2te Query auf den Master.user Server zurückgreift.

2. Zauberwort Caching. Und da vermute ich hat tillate noch ein riesen Potenzial.
Jede Seite wird je nach der Häufigkeit der Ändereungen die Seite erfährt in eine Kategorie eingegliedert. Seiten welche nur wenig oder gar keine Dynamik erleben, würde ich direkt als HTML ablegen. (Impressum usw.)
Seiten die zwar Änderungen erfahren, aber nicht von den Usern selber, sondern von euerem “Content-Team” bearbeitet werden, reicht es meistens wenn der Update alle 5 Minuten neu im Cache abgelegt wird. Während diesen 5 Minuten hätte die Seite zum Beispeil 5000 queries gebraucht. Da sie aber gecached ist braucht es nur 1 zum ablegen. Das verhältniss ist also 5000:1. die Anzahl der Queries wird drastisch minimiert.

Den Chat würde ich in ein dafür vorgesehenes Protokoll migrieren. Irc, Jabber usw. Mit einem Flash Frontend läuft das wunderbar und performant.

Nun könnte man sich ja fragen was die minimierung des Loads mit eurem Cluster zu tun hat. nunja, je kleiner der Load, desto kleiner der Cluster und desto weniger kompliziert wird Punkt 1

Just my 2c….

Tipp 1: Danke für den Tipp. Hier wird einfach der Code weniger schön: Der eine Teil der Daten kommt aus dem REQUEST, der Rest aus dem DB. Das ist unschöne Fallunterscheidung. Vielleicht lässt sich dies aber schlau kapseln.

Tipp 2: Du denkst an Aufteilung in 2 unabhängige Funktionsblöcke mit eigenen DB-CLuster? Wie ebay das z.B. macht. Ja, das tönt schlau. Wir müssen mal schauen, wo wir den Schnitt machen. Diese beiden Blöcke müssten eben weitgehend unabhängig sein.

@Schakko
Danke für die Tipps…

Tipp 1: Wir brauchen hauptsächlich MyISAM-Tabellen (Hier steht irgendwo warum). Somit ist dies für die meisten Tabellen leider nicht anwendbar.

Tipp 2: Diese Verfahren kenne ich. Aber die Folge sind Table Locks -> hängende Apache-Prozesse -> Alle Slots belegt -> “Seite kann nicht angezeigt werden”. Den Slave aus dem Load Balancing zu nehmen, finde ich eine bessere Alternative.

@Ich:
Welche Erfahrung kannst Du denn vorweisen, dass Du die Probleme in unserem Code und unserer Firma so eindeutig siehst?

Und bitte gib mir bitte beim nächsten Kommentar Deine E-Mail an. In diesem Blog kommentieren wir ehrlich und offen. Wir sind ja nicht feige und können zu unseren Kommentaren stehen. Wir haben ja nichts zu verbergen.

Mein Tipp wär der Folgende: Nehmt euch einen Diplominformatiker ins Team der etwas von Algorithmen und Datenstrukturen versteht, und die Seite etwas umkrempeln kann, und versucht nicht selbst mit reinzureden ;).

Zwei Sachen aus der MySQL-Doku:
1.:
—
Note: For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1, sync_binlog=1, and, before MySQL 5.0.3, innodb_safe_binlog, in the master my.cnf file. (innodb_safe_binlog is not needed from 5.0.3 on.)
—
Werdet ihr wahrscheinlich bereits konfiguriert haben?

2.:
—
How do I force the master to block updates until the slave catches up?

A: Use the following procedure:

1.

On the master, execute these statements:

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

Record the replication coordinates (the log filename and offset) from the output of the SHOW statement.
2.

On the slave, issue the following statement, where the arguments to the MASTER_POS_WAIT() function are the replication coordinate values obtained in the previous step:

mysql> SELECT MASTER_POS_WAIT(’log_name’, log_offset);

The SELECT statement blocks until the slave reaches the specified log file and offset. At that point, the slave is in synchrony with the master and the statement returns.
3.

On the master, issue the following statement to allow the master to begin processing updates again:

mysql> UNLOCK TABLES;
—
Ist bei eurer Serverfarm wahrscheinlich eher nicht möglich

Grüße,
Schakko - http://wap.ecw.de

Zwei kleine Ideen für Workarounds:
1) Die Anzeige der aktuellsten Änderung nicht aus der Datenbank beziehen! Zeig bei der Änderung dem aktuellen Benutzer die Änderung einfach ohne DB Zugriff an. Natürlich nützt das nichts wenn der Lag gross ist, bei kleine Lags verhindert das aber frustrierte User und verhindert wait-Hacks.
2) Aufsplitten der Tabellen. Es könnte unter Umständen möglich sein das es möglich ist verschiedene Einheiten von Tabellen auf verschiedene Server (Server-Cluster) zu legen und dann die Replikation-Architektur zu vereinfachen.

Und ein weiter Tipp wäre die wirklichen Experten zu Fragen. Die Jungs von MySQL müssen ja auch was verdienen ;-). Wenn sie euer Problem lösen können wäre das sicher eine lohnende Investition.
Gruss aus Down Under
leo

Da muss ich dir leider widersprechen.
Einen mehrfachen Filesystem-Zugriff auf eine physische Datenbank bringt nur Probleme und führt unausweichlich zu korrupten Files, dann kannst du deine DB in den Müll werfen. Soweit ich weis, lässt MySQL den mehrfachen Zugriff auf die Frames gar nicht zu.

@Silvan: Wenn du willst, kann ich mal bei unserem DB-Team ein bisschen reinhören was sie dazu meinen. Ich meine dass wir ebenso würdige Datenbanken betreiben Kontaktier mich doch mal per E-Mail…

Wie wäre es mit einer SAN, auf welcher die DB abgelegt wird und über verschiedene Server die Updates, rsp. Selects geleitet werden?
Theoretisch wäre das möglich und so entfällt das ewige Replizieren. Und die Performance wird auch nicht gross darunter leiden (vorallem weil die Server auch nicht mehr andauernd mit replizieren beschäftigt sind…)

Gruss
sigma