Ist es sicher, die MySQL-Isolation für typische Web-Nutzung auf "Read Uncommitted" (Dirty Reads) zu setzen? Auch mit Replikation?

Question

Ich arbeite an einer Website mit typischen CRUD Web-Nutzungsmuster: ähnlich wie Blogs oder Foren, wo Benutzer Inhalte erstellen/aktualisieren und andere Benutzer den Inhalt lesen.

Es scheint, als ob es in Ordnung ist, die Isolationsstufe der Datenbank in diesem Fall auf "Read Uncommited" (Dirty Reads) zu setzen. Ich verstehe den generellen Nachteil von "Read Uncommitted", dass ein Leser nicht festgeschriebene Daten lesen kann, die später zurückgesetzt werden.

In einem CRUD Blog/Forum Nutzungsmuster, wird es jemals Rollback geben? Und selbst wenn, gibt es ein großes Problem mit dem Lesen nicht festgeschriebener Daten?

Momentan verwende ich keine Replikation, aber in Zukunft, wenn ich Replikation (zeilenbasiert, nicht statementbasiert) verwenden möchte, wird eine "Read Uncommitted" Isolationsstufe mich davon abhalten?

Was denkst du? Hat jemand versucht, "Read Uncommitted" auf seinem RDBMS zu verwenden?

Answer 1

MySQL 5.1 ist strenger bei Verwendung von read-uncommitted und binlogging (erforderlich für die Replikation) - so können Sie Fehler bei einigen einfachen update/delete-Anweisungen erhalten, die Sie nicht in der Standardisolationsstufe REPEATABLE READ erhalten würden. Ich habe einfache PK-Updates gesehen, wie zum Beispiel:

Update foo gesetzt bar = 1 wo id = 1234;

Fehler mit: mysql_real_query Fehler 1598 Nachricht: Binär Protokollierung nicht möglich. Nachricht: Transaktionslevel 'READ-UNCOMMITTED' in InnoDB ist nicht sicher für binlog-Modus 'STATEMENT'

Also müssen Sie bereit sein, damit umzugehen, indem Sie bei der Änderung von Daten auf wiederholbare Lesevorgänge umschalten oder separate Verbindungen für Lesevorgänge verwenden und schreibt mit ihren eigenen Isolationsstufen. Letzteres kann nützlich sein, wenn/wenn Ihr Projekt skaliert und die Replikation benötigt wird. Sie können also select an einen schreibgeschützten Slave senden und auf den Master schreiben.

OTOH, Lese-nicht festgeschrieben für Lesevorgänge kann ein echter Gewinn sein, wenn konsistente Lesevorgänge nicht unbedingt erforderlich sind, da Innodb weniger Sperren zu nehmen hat.

Wie für die Frage, ob Rollbacks möglich sind, denke ich, dass du die beste Person bist, uns davon zu erzählen, da du derjenige bist, der es kodiert :).

Answer 2

Diese Isolationsstufe bedeutet, dass Sie inkonsistente Daten lesen können. Es gibt keine Garantie, dass Daten, die Sie lesen, aus einer konsistenten Sicht auf die Datenbank stammen.

Ob dies ein Problem ist oder nicht, ist keine MySQL-Frage, sondern eine Anwendungsfrage, die eine Einschätzung des Risikos der Verwendung/Rückgabe inkonsistenter Daten beinhaltet.

In einer Internet-Banking-App wäre es kein No-Go. Bei einem Spiel kann es OK sein. Es kommt darauf an.

Ich habe sowohl "nicht committed" und Replikation verwendet, und hatte keine Probleme.