Wann ist es sicher, die InnoDB-Doublewrite-Pufferung zu deaktivieren?

7

Mit MySQL InnoDB können wir die Doublewrite-Pufferung durch Festlegen deaktivieren innodb_doublewrite = 0. In anderen Datenbanken scheint es nicht möglich zu sein, diese Einstellung zu optimieren .

Wie könnte InnoDB die Datenintegrität und ACID weiterhin aufrechterhalten, wenn wir die Doppelschreibpufferung deaktivieren?

In welchen Situationen ist es sicher , den InnoDB-Doppelschreibpuffer auszuschalten?

— Pacerier
quelle

12

Die einzige Situation, an die ich denken kann, ist das Nachladen eines großen Mysqldump. Warum ?

Schauen Sie sich diese bildliche Darstellung von InnoDB an (Percona CTO Vadim Tkachenko)

InnoDB-Architektur

Auf dem Bild sehen Sie, dass der InnoDB-Pufferpool schmutzige Seiten in schreibt

Protokollpuffer
Puffer in ibdata1 einfügen
Doppelter Schreibpuffer in ibdata1
.ibd Datei für jede InnoDB-Tabelle

Durch das Ausschalten des Double Write Buffer kann ein mysqldump Daten und Indexseiten in die Tabellen schneller schreiben, da nicht dieselben 16K-Seiten in ibdata1 geschrieben werden müssen.

Auf Produktionsservern sollte der doppelte Schreibpuffer niemals deaktiviert sein. Wenn Sie dies tun, um Daten schneller zu laden (natürlich während der Wartung), aktivieren Sie sie sofort nach dem erneuten Laden des DB-Servers.

Mit anderen Worten,

Hinzufügen innodb_doublewrite = 0zumy.cnf
Lauf SET GLOBAL innodb_fast_shutdown = 0;
Starten Sie MySQL neu
Laden Sie mysqldump
Entfernen innodb_doublewrite = 0vonmy.cnf
Lauf SET GLOBAL innodb_fast_shutdown = 0;
Starten Sie MySQL neu

— RolandoMySQLDBA
quelle

Wollten Sie SET GLOBAL innodb_fast_shutdown = 0;im vorletzten Punkt sagen ? Sollte das nicht bedeuten, dass es wieder auf 1 gesetzt wird?

— Tyler Christian

1

@ TylerChristian Nein, es muss 0zweimal sein. Wenn mysqld wieder hochfährt, wird es wieder den Standardwert 1 haben (es sei denn, es innodb_fast_shutdown=0ist in my.cnf)

— RolandoMySQLDBA

8

Dieses Problem wurde in diesem Beitrag von Yves Trudeau gut behandelt, der anscheinend darauf hinweist, dass es sicher ist - seine Schlussfolgerung lautet:

Fazit

Wie ZFS kann ext4 transaktional sein, und das Ersetzen des InnoDB-Doppelschreibpuffers durch das Transaktionsjournal des Dateisystems führt zu einer Leistungssteigerung von 55% bei schreibintensiver Arbeitslast. Leistungssteigerungen werden auch für SSD- und Mixed Spinning / SSD-Konfigurationen erwartet

Er sagt im Grunde, wenn Sie ein geeignetes Dateisystem haben, dann kann es sicher sein.

Perconas Leute kennen sich wirklich gut aus.

— Vérace
quelle

3

Nachdem dies veröffentlicht wurde, fügte Trudeau seinem Beitrag ein Update hinzu: Tun Sie dies nicht, es wurde nachgewiesen, dass dies Daten beschädigt!

— Carla

Trudeau aktualisiert und sagt, dass es mit ZFS in Ordnung ist : percona.com/blog/2015/06/17/… Eine andere Quelle: assets.en.oreilly.com/1/event/21/…

— ItalyPaleAle

@Qualcuno - Die Meldung, die ich erhalte, lautet, dass Journalling-Dateisysteme in Ordnung sind, um den doppelten Schreibpuffer zu deaktivieren - lassen Sie das FS / OS die Dinge erledigen - mit batteriegepuffertem Cache.

— Vérace

4

Aktualisierungen im Yves Trudeau-Blog: https://www.percona.com/blog/2015/06/17/update-on-the-innodb-double-write-buffer-and-ext4-transactions/

Kurz gesagt, es ist wahrscheinlich nicht sicher.

Die Kommentare scheinen darauf hinzuweisen, dass - während es einen Pull-the-Plug-Test überlebt, wenn der FS ext4 mit Journal oder ZFS ist, es einen einfachen Kill (oder OOM, wie ich vermute) nicht überlebt, weil der FS nicht ablehnt die teilweise geschriebenen Daten aus der App-Schicht.

— Hallo Sam
quelle

Ich bin mir nicht sicher, ob ich alles verstanden habe, aber aus den Kommentaren (gegen Ende) geht hervor, dass eine Festschreibungsgröße von 16 KB oder weniger zuverlässig erscheint (Suche nach dem Kommentar "32K append16kb.txt" von Yves Trudeau. Für größere Größe festschreibt, es scheint unzuverlässig (siehe Kommentar mit Zeile "Ich sehe jetzt eine Verteilung" - aber da InnoDBs Seitengröße 16 KB beträgt, scheint es kein Risiko zu sein. Yves Trudeau sagte, er würde das überprüfen, hat aber nichts gepostet seit. Scheint, dass der Punkt noch offen ist? :-)

— Vérace

Nachdem dies veröffentlicht wurde, fügte Trudeau seinem Beitrag ein Update hinzu: WICHTIG: VERSUCHEN SIE DAS NICHT IN DER PRODUKTION. Wie von Marko gezeigt (siehe Kommentare), können Ihre Daten beschädigt werden.

— Carla

1

Laut percona.com/blog/2015/06/17/… ist es sicher, dies mit ZFS zu tun, nicht mit EXT4

— ItalyPaleAle

1

Der Kommentar von Trudeau am Ende lautet: "ZFS ist völlig anders als ext4. Die ZIL fungiert als Doublewrite-Puffer, sodass ZFS den Double-Write-Puffer sicher deaktivieren kann." - Für einige Dateisysteme ist dies in Ordnung.

— Vérace

0

Meine vorläufige Liste von Situationen, in denen es in Ordnung ist, den Doppelschreibpuffer auszuschalten:

FusionIO (oder wie auch immer es heißt) - Das Laufwerk verarbeitet es
Galera - Erstellen Sie den Knoten neu, wenn er abstürzt
Slaves - Erstellen Sie den Slave neu, wenn er abstürzt
ZFS - Der Treiber kümmert sich darum

— Rick James
quelle