Die MySQL-Einstellung „innodb_flush_log_at_trx_commit" auf Wert 2 stellen.

Hat die Meldung den Vorgang verhindert oder war es nur ein Hinweis?

Soweit ich weiß geht es in jeder Parameter-Einstellung es ist also kein "Blocker" sondern eher ein freundlicher "Performance-Hinweis".

Hier findest Du auch noch etwas dazu: InnoDB optimieren

Grundsätzlich stimme ich dem Support-MA von Deinem Provider zu; auch ich würde den Parameter in einer "produktiven Installation" nicht von 1 weg ändern. Eine mySQL-Datenbank mit InnoDB ist nämlich nur dann vollständig "ACID"-konform und damit "Transaktionssicher", wenn der Parameter auf "1" steht.

Im schlimmsten Fall verlierst man bei einem Crash in der Einstellung "2" nämlich bis zu einer Sekunde Daten! Und die lassen sich im Zweifel auch mit einem Crash-Recovery grundsätzlich nicht wiederherstellen; weil eben die Logs zu diesen Änderungen im worst case noch nicht auf die Platte geschrieben sind.

Quote from Barungar

Soweit ich weiß geht es in jeder Parameter-Einstellung es ist also kein "Blocker" sondern eher ein freundlicher "Performance-Hinweis".

Das meine ich nämlich auch.

Zumal der Hinweis inzwischen seitens WL (zumindest auf der Import-Seite, wo dieser immer angezeigt wurde) entfernt wurde.

Quote from Auge

Zumal der Hinweis inzwischen seitens WL (zumindest auf der Import-Seite, wo dieser immer angezeigt wurde) entfernt wurde.

Bei "Anzeigen aktualisieren" wird er aber weiterhin angezeigt.

Nö, bei mir nicht.

Bei mir schon. Komisch.

Ich setz dann noch einen drauf: Der Hinweis erscheint sowohl bei Import als auch bei Anzeigen aktualisieren.

Gruß norse

Du hast „bei mir“ vergessen.

Sowohl in meiner Testumgebung als auch in meinem produktiven Forum wird dieser Hinweis nirgends angezeigt.

Vielleicht solltest Du mal prüfen, ob der Wert bei Dir möglicherweise auf "2" steht.

Gruß norse

Wie kann ich das selbst überprüfen?

In dem du in phpmyadmin gehst und dort dir die variablen anschaust.
Suche nach der variable und dann siehst du dass der bei dir auf 2 steht.
Sonst würdest du zu 100% diesen Hinweis sehen;)

Nö, bei mir steht da „0“.

0 hab ich noch nicht gesehen

Vieleicht ist das aber auch einfach nur ein "master" value?
Frag mal deinen Hoster

Weiß ich nicht, aber ist im Grunde genommen auch nicht wichtig, weil bei mir alles so funktioniert, wie es soll.

Quote from Throwholics

In dem du in phpmyadmin gehst und dort dir die variablen anschaust.
Suche nach der variable und dann siehst du dass der bei dir auf 2 steht.
Sonst würdest du zu 100% diesen Hinweis sehen;)

Bäh! Immer dieser phpmyadmin... Ich mag das Teil nicht.

Indem Du eine Session mit Deiner Datenbank etablierst und dann den Befehl SHOW VARIABLES LIKE "%trx_commit%; abschickst.

Das sieht dann so aus:
mysql> show variables like "%trx_commi%";
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)

Die Modi von innodb_flush_log_at_trx_commit

Modus 0: Es wird einmal pro Sekunden in das Log geschrieben, anschließend erfolgt ein flush to disk.
Modus 1: Es wird mit jedem COMMIT Statement in das Log geschrieben und es erfolgt sofort ein flush to disk. (Einziger "transaktionssicherer" Modus!)
Modus 2: Es wird mit jedem COMMIT Statement in das Log geschrieben, (Achtung!) der flush to disk erfolgt einmal pro Sekunde!

Modus 0 ist der denkbar schlechteste Modus (meiner Meinung), wenn einem die Konsistenz der Daten am Herzen liegt. Wenn einem die Daten egal sind, und es "nur" um Performance geht, ist der Modus 0 natürlich "unübertroffen"... Modus 2 ist sozusagen ein Kompromiss zwischen 0 und 1... wobei bei mir nur Modus 1 "in die Tüte" kommt.

Quote from Alexander Ebert

Der Hinweis wird angezeigt wenn innodb_flush_log_at_trx_commit = 1 ist, andernfalls taucht er nicht auf - Warum auch? Der Wert 0 ist im übrigen nicht so empfehlenswert, es sollte zu mindestens 2 sein um das Optimum aus Datensicherheit und Durchsatz zu erhalten. So schlimm ist der Wert 2 genau genommen auch gar nicht, wenn man ein Hardware-RAID mit BBU hat ist der Datenverlust bei einem OS-Crash/Stromauswahl gleich 0, es wäre in so einem Setup sogar unsinnig den Wert 1 zu nutzen da man dann nur ein Performace-Loch ohne Vorteil hätte.

Das ist nach meinem Verständnis so nicht ganz korrekt. Wenn ein Programm in eine Datei schreibt, aber keinen "flush to disk" erzwingt, ist nicht sicher gestellt, dass das Betriebsystem eine definitive Schreiboperation auf der HD ausgeführt hat. Das OS wird das "Schreiben in die Datei" als erfolgreich quittieren, aber ggf. aus Optimierungsgründen durchaus verzögert ausführen... somit würde mir in der aktuellen Situation selbst ein HW-RAID mit Batterie-Puffer nicht helfen, weil selbst das RAID zu diesem Zeitpunkt noch nichts von der Schreibanforderung weiß. Das RAID erfährt erst mit dem "flush to disk" von der Anforderung effektiv auf HD zu schreiben.