Frage zu Replikation/Stabilität/Verfügbarkeit

betrazivis
Posts: 32
Joined: 2006-06-01 11:10

Frage zu Replikation/Stabilität/Verfügbarkeit

Post by betrazivis »

Hallo zusammen,
leider ist mir keine bessere Überschrift als diese eingefallen. whistle

Ich habe eine Datenbank, die ca. 2,5 GB groß ist und in der Haupttabelle ca. 1,5 Millionen Datensätze beinhaltet. Die Tabelle wird in der Relation SELECT/INSERT 80%/20% genutzt. Da diese Daten per Volltextsuche gefunden werden müssen und teilweise sehr viel Text enthalten benutze ich hier myISAM. Nun ist das Problem, dass die Tabelle bei einem (relativ oft vorkommenden) INSERT/DELETE/UPDATE "locked" ist, zu dieser Zeit aber trotzdem viele SELECT Anfagen kommen und es dann zu sehr hohen Peaks kommt, die häufig im Absturz von mySQL enden. Der Server ist leistungstechnisch voll ausreichend(2 Ghz Quad/ 6 GB)

Ich bin nun soweit, dass ich die Datenbank replizieren möchte, d.h. alle INSERT/DELETE/UPDATE auf dem Master und alle SELECTs auf dem Slave laufen lassen möchte.

Generell muss dies aber nicht die Endlösung sein. Welche Möglichkeiten gibt es noch, dieses Problem zu lösen. Ich weiß, dass myISAM nicht unbedingt empfehlenswert ist, da sie erfahrungsgemäß nicht sehr stabil läuft, aber welche Speicher-Engine wäre für mich sinnvoll?


System
mySQL 5.0.26
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: Frage zu Replikation/Stabilität/Verfügbarkeit

Post by isotopp »

betrazivis wrote:Generell muss dies aber nicht die Endlösung sein. Welche Möglichkeiten gibt es noch, dieses Problem zu lösen. Ich weiß, dass myISAM nicht unbedingt empfehlenswert ist, da sie erfahrungsgemäß nicht sehr stabil läuft, aber welche Speicher-Engine wäre für mich sinnvoll?

System
mySQL 5.0.26


Bitte mal auf 5.0.67 updaten. Danke.

Wegen FULLTEXT bist Du auch MyISAM festgelegt, da kann man nix machen.

Ein Slave wird dieselben Updates durchführen wie der Master. Diese sind langsam, weil Updates in FULLTEXT Indices sehr teuer sind - für jedes Wort im TEXT muß der alte Indexeintrag für das Wort gelöscht werden, dann muß der neue TEXT in Worte zerlegt werden und für jedes Wort der neue Indexeintrag für dieses Wort aktualisiert werden. Die Situation wird also durch einen Slave alleine nicht besser.

Was genau machst Du dort? Wieso ändert sich Dein FULLTEXT so häufig?

Du kannst auf dem Slave low_priority_updates einstellen. Dann haben SELECT Vorrang vor Schreibzugriffen. Das wird dann zu Slave Lag führen.
Top

betrazivis
Posts: 32
Joined: 2006-06-01 11:10

Re: Frage zu Replikation/Stabilität/Verfügbarkeit

Post by betrazivis »

isotopp wrote:Bitte mal auf 5.0.67 updaten. Danke.

Ich würde sogar gerne auf 5.1 updaten, jedoch finde ich beim besten Willen kein rpm für openSUSE. Selbst kompilieren will ich auf dem System nicht, da es produktiv betrieben wird.
Weiß da jemand ne Lösung, ähnlich wie die für Debian? Würde schon immer gerne das neuste Release von mySQL nutzen.

isotopp wrote:Ein Slave wird dieselben Updates durchführen wie der Master. Diese sind langsam, weil Updates in FULLTEXT Indices sehr teuer sind - für jedes Wort im TEXT muß der alte Indexeintrag für das Wort gelöscht werden, dann muß der neue TEXT in Worte zerlegt werden und für jedes Wort der neue Indexeintrag für dieses Wort aktualisiert werden. Die Situation wird also durch einen Slave alleine nicht besser.

Was genau machst Du dort? Wieso ändert sich Dein FULLTEXT so häufig?

Du kannst auf dem Slave low_priority_updates einstellen. Dann haben SELECT Vorrang vor Schreibzugriffen. Das wird dann zu Slave Lag führen.

Das mit dem FULLTEXT-Index habe ich ja oben schon angedeutet. Das sind Daten, die über ne Volltext-Suche gefunden werden müssen. Und diese Daten enthalten teils sehr viel Text. Es handelt sich dabei um eine B2B Handelscommunity, bei der eines der Features ist, dass der User seine angebotenen Artikel updaten kann. D.h. per Knopfdruck stehen diese in der Liste wieder oben. Diese UPDATEs sperren die Tabelle und es kommt oft zu verdammt hohen Peaks weil in dieser Zeit ja ebenfalls SELECTS kommen, die nicht ausgeführt werden können. Weiter haben wir einen "Artikelimport", bei dem der User per CSV-Datei Artikel importieren kann. Während einer solchen Aktion(INSERTS) sieht es ebenfalls schwarz aus. Der Server macht dann nach "max_connections=100" dicht. Nervigerweise passiert das bis zu 5 Mal pro Tag. Das ist natürlich so nicht hinnehmbar, weil ja auch immer die Gefahr besteht, dass der Index zerschossen wird.

Das mit low_priority_update auf dem Slave ist schonmal n super Ansatz, ich denke nämlich nicht, dass es zu einem Slave-Lag kommen wird, da es ja "nur" 10% UPDATES/INSERTS sind. Das wird sich im Produktiv-Einsatz zeigen.Aber danke für den Tipp. :)
Top

betrazivis
Posts: 32
Joined: 2006-06-01 11:10

Re: Frage zu Replikation/Stabilität/Verfügbarkeit

Post by betrazivis »

Für alle, die ähnliche Probleme und Fragen haben wie ich, hier mal eine kleine Bestandsaufnahme nach 2 Tagen Replikation.
Ich habe durch die Replikation (mit low_priority_updates auf dem Slave) einen Geschwindigkeitszuwachs von ca. 20% bekommen. Der Server ist seit der Replikation nicht einmal abgestürzt(wie in Vergangenheit mehrere Male pro Tag). Auch habe ich zur Zeit noch keine Probleme mit Slave-Lags. Trotz der erhöhten Kosten (2. Server) hat sich die Replikation für mich und meine User gelohnt. whistle
Top