RootForum Community

Ich arbeite zur Zeit an einer Datenbank (mySQL) und einem Projekt mit PHP. Nun möchte ich die Daten auf einer zweiten Datenbank sichern, bzw evtl später mal, zurechnen ist, dass es einen großen Besucheransturm gibt, die Daten von verschiedenen SQL Servern abrufen.
Dazu muss ich allerdings mit einigen SQL Anweisungen sicherstellen dass keine Aktionen ausgeführt werden, die nicht von einem anderen auch bzw entgegen ausgeführt werden. z.b. der eine macht ein delete der andere ein Update. Bzw ich mache einen SQL Server zum Lese den anderen zum schreibe, was aber auch gegen meine Vorstellung spricht, da ich unabhänig von beiden sein will.
Nun meine Frage ist bei mySQL die Replikation Funktion gut genug. Also wie schnell arbeitet Sie. Hier meine Daten:

mySQK Abfragen pro Stunde: ca. 250 000 Abfragen pro Stunde (Schnitt); 50 pro Sekunde. Also ca. 500 000 - 750 000 Abfragen pro Stunde peak: ca. 100 pro Sekunde.
Das sind ca. 10-20 KB pro Sekunde an Peak Zeiten sogar 30-50...


Der Hauptserver hat eine 100 Mbit Leitung.
Der Server hat 3,2 GHz und 2 gb Ram;

Würde gerne eure meinung hören, in wie weit die Replikation auf den Ablauf einfluss hat. Sprich dauern scripts dadurch erheblich länger?

Oder wäre eine selbst programmierte php lösung besser. sprich, dass ich alle daten selbst per mysql_query auf beiden servern eintrag und beim abfragen scheu welcher am günstigsten ist? Aber dass denke ich geht viel merh aiuf die Performance

Wenn du nch beim schreiben bist, dann würde ich einfach die Server für lesende Zugriffe und schreibende Zugriffe trennen.
Alles inserts, updates usw. gehen an an den Master, und alle querys können von n-Replizierten Servern abgefragt werden.

Das Konzept funktioniert natürlich nur dann gut, wenn mehr lesende als schreibzugriffe vorhanden sind, wsonst hilft nur mehr Hardware.

Ich bin bei ca. 75% lese und 25% schreibe/update.
Es geht drum, was ist wenn server A (Master mit schreibe) ausfällt? Dann kann man die db nur als lese datenbank benutzen.

Und genau in diesem fall, was denke ich nicht öfter als 0,05% im jahr sind aber immerhin nicht unwahrscheinlich, möchte ich dass der betrieb der seiten weitergeht. Sprich soll ich in diesem fall auf "Insel betrieb" umschalten?
Dass problem ist auto:increment. Das umschalten via script ist einfach, aber dann kolledieren die auto_increment werte...

Gibt es eine möglichkeit die auto_increment vorzubestimmen sprich ich weiß innerhalb von einem tag werden in tabelle x 10000 neue einträge geschreiben.

Master Server A stürzt bei 1243250345 ab.

dass dann server a im inselbetrieb 1250000000 - 1260000000
server b 1260000000 -1270000000 etc.
und dann wenn master server wieder da ist dieser nur die werte hinzufügt und danach bei der nächst höheren zahl weitermacht?

DjBennyF wrote:Ich bin bei ca. 75% lese und 25% schreibe/update.
Es geht drum, was ist wenn server A (Master mit schreibe) ausfällt? Dann kann man die db nur als lese datenbank benutzen.

Wenn der eine Server ausfällt, kann man recht fix aus dem Slave den Master machen, sollte auch Problemlos automatisierbar sein (heartbeat oder so), dass der Ausfall dann deutlich unter 5Min wäre.

Und bei 3 oder 4 SQL Servern?

DjBennyF wrote:Und bei 3 oder 4 SQL Servern?

Dann wird halt das Skript etwas komplizierter.
Wenn der master ausfällt kann ja ein Slave die IP des masters übernehmen und sich zum Master erklären ...

Man muss dann natürlich die verschiedenen Szenarien (zumindest in Gedanken) durchspielen, obs immer so klapt wie gewünscht, aber im Prinzip ändert sich nicht sooo viel ob es nun 1 oder 100 Slaves sind.

In irgendeinem Tutorial wurde eine "Ring-Lösung" vorgeschlagen, d.h. Server A repliziert auf Server B, der repliziert auf Server C und dieser wieder auf Server A.

Im Normal-Betrieb erfolgt schreibender Zugriff nur auf Server A, wenn dieser ausfällt auf Server B, und wenn dieser auch ausfällt auf Server B. So ist einerseits sichergestellt, dass sich Server nicht überschneiden und gleichzeitig alle über den aktuellen Datenbestand verfügen.

Wenn dies für deine Zwecke nicht reicht, wird dir wohl nichts anderes übrigbleiben als auf eine andere Datenbank umzusteigen, die Clustering mit schreibenden Zugriff auf unterschiedliche Nodes erlaubt.

Das Tutorial hätte ich gerne mal gesehn, kannst du evtl die url auftreiben?

Mal so am Rande ... wenn Dir hochverfügbarkeit am Herzen liegt, schonmal an ein anderes Datenbanksystem gedacht?

Wenn es so wichtig ist, das man 0,5% Downtime nicht hinnehmen kann sollte auch das Geld für eine Datenbank der Kategorie Oracle da sein...

Im Open-Source-Umfeld ist sicherlich auch eine MaxDB mit Hot-Standby nicht schlecht. Wenn einem die Features von MySQL reichen, ist aber auch durchaus die ein ernstzunehmender Datenbank-Server.

Hm, also ich denke MySQL mit Replication und Transactions reicht. Nur wenn mehr als 2 Datenbank-Server benötigt werden, was ich nebenbei bemerkt für höchst unwahrscheinlich halte, ist MySQL nicht mehr erste Wahl.

øxygen wrote:Nur wenn mehr als 2 Datenbank-Server benötigt werden, was ich nebenbei bemerkt für höchst unwahrscheinlich halte, ist MySQL nicht mehr erste Wahl.

Ich hatte da eher an Features wie Stored Procedures, Triggers und Subqueries gedacht.

BTW: Weiß jemand von euch, ob MaxDB Views / Snapshots unterstützt? PostgreSQL kann das ja schon lange, unterstützt aber leider immer noch keine Replikation.

MajorTermi wrote:

øxygen wrote:Nur wenn mehr als 2 Datenbank-Server benötigt werden, was ich nebenbei bemerkt für höchst unwahrscheinlich halte, ist MySQL nicht mehr erste Wahl.

Ich hatte da eher an Features wie Stored Procedures, Triggers und Subqueries gedacht.

Subqueries okay, das ist manchmal eine hilfreiche Sache. Aber für Stored Procedures und Triggers fällt mir auf Anhieb keine Verwendung in einen "PHP-Projekt" ein. Aber vielleicht stell ich mir auch was falsches vor...