it-swarm.com.de

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

Mit MySQL InnoDB können wir die Doublewrite-Pufferung deaktivieren, indem wir innodb_doublewrite = 0 . Andere Datenbanken scheint diese Einstellung nicht zu ändern .

Wie könnte InnoDB die Datenintegrität und ACID aufrechterhalten, wenn wir sie deaktivieren? Doublewrite-Pufferung?

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

7
Pacerier

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 Architecture

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 dasselbe 16K Seiten in ibdata1 geschrieben werden muss.

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 = 0 bis my.cnf
  • Lauf SET GLOBAL innodb_fast_shutdown = 0;
  • Starten Sie MySQL neu
  • Laden Sie mysqldump
  • Entfernen innodb_doublewrite = 0 von my.cnf
  • Lauf SET GLOBAL innodb_fast_shutdown = 0;
  • Starten Sie MySQL neu
12
RolandoMySQLDBA

Dieses Problem wurde in this Post 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.

8
Vérace

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 FS ist ext4 mit Journal oder ZFS, es einen einfachen Kill (oder OOM I) nicht überlebt verdächtig), weil das FS die teilweise geschriebenen Daten von der App-Ebene nicht ablehnt.

4
HelloSam

Meine vorläufige Liste von Situationen, in denen es in Ordnung ist, den Doublewrite-Puffer 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
0
Rick James