innodb_flush_log_at_trx_commit Wert ändern

    Mein Hoster gab mir folgende Antwort auf die Frage ob man den Wert auf 2 setzen könnte:

    der Wert ist mit "1" in Ordnung. Der Server ist nicht batteriegepuffert, in
    sofern sehen wir Schreibzugriffe ohne Commit aus Gründen der Datensicherheit
    und Konsistenz als nicht relevant an.

    Unglaublich... wir sind auch bei all-inkl.com und aktuell läuft der DB-Import seit über 5 Stunden!!! Und bis jetzt ist noch keiner der 425k Forenbeiträge importiert worden!!!
    Ich finde es verdammt unverschämt von Woltlab so ein inperformantes Stück Software auszuliefern...

    Davon ab nach Auskunft der Hotline bei all-inkl.com wird aktuell noch geprüft den Wert für innodb-flush-log-at-trx-commit auf 2 zu setzen, aber das wird frühestens am 23.12. etwas.

    Quote from Scotswhisky

    Unglaublich... wir sind auch bei all-inkl.com und aktuell läuft der DB-Import seit über 5 Stunden!!! Und bis jetzt ist noch keiner der 425k Forenbeiträge importiert worden!!!

    Bin nicht bei all-inkl.com aber das hatte ich auch. Parallel in der Datenbank geschaut, ob sich da etwas bewegt. Nichts! Import blieb bei 22% stehen und nichts ging mehr. Ich habe danach noch einmal von vorne begonnen und die Importschritte einzeln gemacht. Also erst User, dann Foren, dann...

    Nur die Konversationen aus meiner vorherigen wbb4 Installation hat er nicht übernommen. Keine Ahnung warum? Antwort dazu habe ich bisher nicht erhalten.

    Quote from PatrickGER

    Ja genau, dafür kann ja WoltLab was...

    Ja können sie!
    Einfach die Import-Programme so bauen, das sie nicht abhängig sind von so einem Parameter in der DB. Beim Wechsel von 2.x auf 3.x ging es doch auch flotter.

    Und nicht jeder Betreiber eines Woltlab-Forums hat auch gleichzeitig einen eigenen Server, wo er nach belieben an den Parametern schrauben kann.

    Da war aber InnoDB keine vorraussetzung :o Nun braucht das Burning Board InnoDB unterstützung.

    Es ist ärgerlich das es so lange braucht ja, aber deshalb brauchst du noch nicht so an die Decke zu gehen :) Wenns nicht dringend ist, dann warte einfach die drei Tage ab, hast dann weniger ärger.

    Liebe Grüße

    Marc

    • Official Post

    Die Erklärung für die teilweise niedrige Geschwindigkeit liegt in der Art und Weise wie InnoDB arbeitet. MyISAM ist eine sehr schnelle Engine, allerdings ist sie sehr anfällig für Fehler (z.B. xyz is marked as crashed), unterstützt keine Transaktionen und bietet keine Möglichkeit die Integrität von Daten zwischen Tabellen mittels "Foreign Keys" zu gewährleisten.

    InnoDB im Gegensatz hat all diese Vorzüge und bietet zusätzlich eine extreme Robustheit gegenüber Störungen. Dies wird möglich durch die vollständige Umsetzung von ACID in der Standardkonfiguration, im folgenden möchte ich kurz auf die 3 Einstellungen von innodb_flush_log_at_trx_commit eingehen:

    • 0 - Alle Änderungen an der Datenbank werden in die Datei geschrieben, die Änderungen aber nur einmal pro Sekunde auf die Festplatte übertragen. Im Falle eines MySQL- oder Server-Absturzes geht diese Sekunde verloren
    • 1 - (Standardwert) Jede Änderung wird sofort auf die Festplatte geschrieben und die Bestätigung des erfolgreichen Schreibvorgangs abgewartet. Im Falle eines MySQL- oder Server-Absturzes gehen keine Daten verloren
    • 2 - Alle Änderungen an der Datenbank werden in die Datei geschrieben und nach einem COMMIT (Transaktion abgeschlossen) sofort auf die Festplatte geschrieben. Nur im Falle des kompletten Server-Absturzes geht die letzte Sekunde verloren

    Das Problem mit 1 kann ich an einem kurzen Beispiel erläutern: Nehmen wir an, es sollen nacheinander 2 Benutzer angelegt werden:

    • Benutzer A wird angelegt
    • Änderungen werden in die Datei geschrieben und auf die Festplatte übertragen
    • Es wird gewartet, bis die Festplatte den Erfolg der Schreiboperation zurückliefert
    • Die Rückmeldung an PHP erfolgt, dass nun der nächste Datensatz folgen kann
    • Benutzer B wird angelegt
    • Schritte 2-4 wiederholen sich

    Der Flaschenhals ist hier die Festplatte, je langsamer diese ist, desto länger dauert die Rückmeldung und dementsprechend erhöht sich linear die Zeit die der Import benötigt.

    Dieser Prozess lässt sich schlicht nicht beschleunigen, da auf Grund des AUTO_INCREMENT die neue User-ID abgefragt werden muss und dies setzt voraus, dass der vorherige Datensatz fertig geschrieben wurde. Ein gleichzeitiges Einfügen mehrerer Benutzer funktioniert nicht, da MySQL nur die User-ID des letzten, eingefügten Benutzers zurückliefern kann.

    Quote from PatrickGER

    aber
    deshalb brauchst du noch nicht so an die Decke zu gehen

    Sei froh, das Du noch nicht erlebt hast, wie es ist, wenn ich an die Decke gehe ;)

    Ich vergleiche das mal mit der Situation aus meinem Job (Forum ist für mich nämlich nur Nebenbeschäftigung), wenn ich da einem meiner Kunden erzählen müsste, das er mal eben so für 12 bis 18 Stunden seinen Betrieb einstellen muss, da seine DB beim Release-Wechsel Schwierigkeiten machen könnte (weil der Schalter X=1 und nicht 2 ist), dann könnte ich gleich einpacken und nach Hause gehen...

    Oder anderes Beispiel: Ich mache 'ne Probefahrt mit 'nem neuen Auto, muss aber vorher tanken. Am Tankdeckel des neuen Modells entdecke ich einen Hinweis des Herstellers: "Bitte tanken sie nicht Benzin X+ sondern X++,
    ansonsten kommt es zu einer Verlangsamung bei der Höchstgeschwindigkeit". Nur doof, das die Tankstelle bei mir am Ort möglicherweise erst nächste Woche X++ anbietet.
    Egal, ich fahre los und stelle fest, das ich für die Strecke, die ich vorher in 30 Minuten geschafft habe, plötzlich mindestens 12 Stunden brauche.

    Bin ich jetzt Schuld, das der Wagen so langsam fährt?
    Oder die Tankstelle weil sie dieses "veraltete" X+ im Angebot hat?

    Aber so, wie ich hier manche Reaktionen deute, ist auf keinen Fall der Motorenhersteller der Schuldige, obwohl er es nicht schafft seinen Motor so zu bauen, dass dieser auch reibungslos mit X+ klar kommt!

    Quote from PatrickGER

    Wenns nicht dringend ist, dann warte einfach die drei Tage ab, hast dann
    weniger ärger.

    Tja, das mag vielleicht in Deinem Zeituniversum passen ;) aber ich bin davon ausgegangen, das ich am Freitag Testrun 1 mache, am Samstag die notwendigen Anpassungen vornehme, Sonntag dann einen Testrun 2 und ab Montag können dann die Key-User testen. So aber habe ich möglicherweise erst wieder Mitte Januar 2014 Zeit das Thema erneut anzugehen.

    Quote from Alexander <br>Ebert

    Die Erklärung für die teilweise niedrige Geschwindigkeit liegt in der Art und Weise wie InnoDB arbeitet.

    OK, technisch gesehen, kann ich das nachvollziehen, aber auch andere Anwendungen setzen MySQL5.5+ ein und sind trotzdem nicht grottig langsam.

    Hinzu kommt ja, das aus irgendwelchen unerfindlichen technischen Gründen eine Migration nicht möglich war, denn das hätte die Sache enorm vereinfacht. Nein, es musste ja eine Neu-Installation mit Datenimport sein.

    Dabei kann man mit dem SQL-Befehl ALTER TABLE eine ganze Menge machen, z.B. wandelt man ruckzuck das Tabellenformat MyISAM in eine InnoDB um

    Code
    ALTER TABLE `wbb1_1_board` ENGINE = InnoDB

    Na ja, die Experten werden schon wissen warum sie es so gemacht haben, wie sie es gemacht haben.

    Und für die Statistik: der Import läuft jetzt seit 11 Stunden und wir sind seit 5 Minuten bei 43% der Beiträge. Ich geh dann jetzt mal ins Bett und hoffe, das um 8 alles fertig ist...

    • Official Post
    Quote from Scotswhisky

    OK, technisch gesehen, kann ich das nachvollziehen, aber auch andere Anwendungen setzen MySQL5.5+ ein und sind trotzdem nicht grottig langsam.


    Das hat mit MySQl herzlich wenig zu tun, MyISAM ist sehr schnell, bietet aber nicht die Funktionen von InnoDB.

    Quote from Scotswhisky

    Hinzu kommt ja, das aus irgendwelchen unerfindlichen technischen Gründen eine Migration nicht möglich war, denn das hätte die Sache enorm vereinfacht. Nein, es musste ja eine Neu-Installation mit Datenimport sein.


    WCF 2.0 (genauso wie Burning Board 4.0) ist eine Neuentwicklung und auf Grund der komplett neu entwickelten API nicht kompatible, ein Update funktioniert rein technisch nicht, da man PHP-Dateien nicht zur Laufzeit neu laden kann.

    Quote from Scotswhisky

    Dabei kann man mit dem SQL-Befehl ALTER TABLE eine ganze Menge machen, z.B. wandelt man ruckzuck das Tabellenformat MyISAM in eine InnoDB um


    Das ist nur die halbe Wahrheit, so werden beispielsweise die Foreign Keys nicht angelegt. Bei MyISAM-Tabellen werden Anweisungen zur Erzeugung von Foreign Keys einfach ignoriert und damit ist die Konsistenz nicht mehr gewährleistet.

    Quote from Scotswhisky

    Na ja, die Experten werden schon wissen warum sie es so gemacht haben, wie sie es gemacht haben.

    Dem stimme ich voll zu!

    Seit Beginn der Testphase hat Woltlab ordentlich Kritik wegen diesem einen Punkt einstecken müssen. Denkt ihr wirklich, dass sie dieses Problem nicht aus dem Weg geräumt hätten, wenn sie nicht 100% von der Notwendigkeit überzeugt wären? Schließlich verärgern sie z.Z. einen Großteil ihrer Kunden damit und welche Firma macht das schon freiwillig ohne triftigen Grund?

    Die ersten Provider reagieren ja bereits auf die "neuen" Anforderungen und so haben wir im Endeffekt alle etwas von einer modernen Software.


    Gruß Uwe

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login