it-swarm.com.de

Ist es sicher, innodb_flush_log_at_trx_commit = 2 zu verwenden?

Ich drehte mich innodb_flush_log_at_trx_commit = 2 und erhalten eine sehr schnelle Schreibgeschwindigkeit. Aber ist es sicher, in der Produktionswebsite verwendet zu werden?

57
Bruce Dou

Sie können Transaktionen im Wert von bis zu einer Sekunde verlieren. Der Standardwert ist 1, wodurch InnoDB ACID-konform bleibt.

Laut der MySQL-Dokumentation zu innodb_flush_log_at_trx_commit

Wenn der Wert von innodb_flush_log_at_trx_commit 0 ist, wird der Protokollpuffer einmal pro Sekunde in die Protokolldatei geschrieben, und der Vorgang zum Löschen auf die Festplatte wird für die Protokolldatei ausgeführt, bei einem Transaktions-Commit wird jedoch nichts ausgeführt. Wenn der Wert 1 ist (Standardeinstellung), wird der Protokollpuffer bei jedem Transaktions-Commit in die Protokolldatei geschrieben und der Vorgang zum Löschen auf die Festplatte für die Protokolldatei ausgeführt. Wenn der Wert 2 ist, wird der Protokollpuffer bei jedem Festschreiben in die Datei geschrieben, aber der Vorgang zum Löschen auf die Festplatte wird nicht ausgeführt. Das Leeren der Protokolldatei erfolgt jedoch einmal pro Sekunde, auch wenn der Wert 2 ist. Beachten Sie, dass das Leeren einmal pro Sekunde aufgrund von Problemen bei der Prozessplanung nicht zu 100% pro Sekunde garantiert ist.

Der Standardwert 1 ist für die vollständige ACID-Konformität erforderlich. Sie können eine bessere Leistung erzielen, indem Sie einen anderen Wert als 1 festlegen. Bei einem Absturz können Sie jedoch Transaktionen im Wert von bis zu einer Sekunde verlieren. Mit dem Wert 0 kann jeder mysqld-Prozessabsturz die letzte Sekunde der Transaktionen löschen. Bei einem Wert von 2 kann nur ein Betriebssystemabsturz oder ein Stromausfall die letzte Sekunde der Transaktionen löschen. Die Crash-Wiederherstellung von InnoDB funktioniert unabhängig vom Wert.

Verwenden Sie innodb_flush_log_at_trx_commit = 1 und sync_binlog = 1 in Ihrer my.cnf-Master-Server-Datei, um eine möglichst lange Lebensdauer und Konsistenz bei einem Replikations-Setup mit InnoDB mit Transaktionen zu erzielen.

Vorsicht

Viele Betriebssysteme und einige Festplattenhardware täuschen den Flush-to-Disk-Betrieb vor. Sie können mysqld mitteilen, dass die Spülung stattgefunden hat, obwohl dies nicht der Fall ist. Dann ist die Dauerhaftigkeit von Transaktionen selbst mit der Einstellung 1 nicht garantiert, und im schlimmsten Fall kann ein Stromausfall sogar die InnoDB-Datenbank beschädigen. Die Verwendung eines batteriegepufferten Festplatten-Caches im SCSI-Festplattencontroller oder auf der Festplatte selbst beschleunigt das Löschen von Dateien und macht den Vorgang sicherer. Sie können auch versuchen, mit dem Unix-Befehl hdparm das Caching von Festplattenschreibvorgängen in Hardware-Caches zu deaktivieren, oder einen anderen Befehl verwenden, der für den Hardwarehersteller spezifisch ist.

Auf dieser Grundlage besteht für andere Werte als 1 die Gefahr, dass InnoDB Transaktionen im Wert von 1 Sekunde oder Daten eines Transaktions-Commits verliert.

In der Dokumentation steht auch use sync_binlog=1.

Laut der MySQL-Dokumentation zu sync_binlog

Der Wert 1 ist die sicherste Wahl, da Sie im Falle eines Absturzes höchstens eine Anweisung oder Transaktion aus dem Binärprotokoll verlieren. Dies ist jedoch auch die langsamste Wahl (es sei denn, die Festplatte verfügt über einen batteriegepufferten Cache, wodurch die Synchronisation sehr schnell erfolgt).

Ihre sicherste Wahl ist

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Wenn Ihnen ein möglicher Datenverlust (bis zu 1 Sekunde) nichts ausmacht, können Sie auf eigenes Risiko entweder 0 oder 2 verwenden, wenn sich die Belohnungen (schnellere Schreibgeschwindigkeit) lohnen.

59
RolandoMySQLDBA

Das innodb_flush_log_at_trx_commit wird mit dem Zweck verwendet als ..

Wenn der Wert von innodb_flush_log_at_trx_commit ist 0, der Protokollpuffer wird einmal pro Sekunde in die Protokolldatei geschrieben und der Vorgang zum Löschen auf die Festplatte wird für die Protokolldatei ausgeführt, aber bei einem Transaktions-Commit wird nichts ausgeführt.

Wenn der Wert 1 ist (Standardeinstellung), wird der Protokollpuffer bei jedem Transaktions-Commit in die Protokolldatei geschrieben und der Vorgang zum Löschen auf die Festplatte für die Protokolldatei ausgeführt.

Wenn der Wert 2 ist, wird der Protokollpuffer bei jedem Festschreiben in die Datei geschrieben, aber der Vorgang zum Löschen auf die Festplatte wird nicht ausgeführt. Das Leeren der Protokolldatei erfolgt jedoch einmal pro Sekunde, auch wenn der Wert 2 ist. Beachten Sie, dass das Leeren einmal pro Sekunde aufgrund von Problemen bei der Prozessplanung nicht zu 100% pro Sekunde garantiert ist.

Der Standardwert 1 ist für die vollständige ACID-Konformität erforderlich. Sie können eine bessere Leistung erzielen, indem Sie einen anderen Wert als 1 festlegen. Bei einem Absturz können Sie jedoch Transaktionen im Wert von bis zu einer Sekunde verlieren. Mit dem Wert 0 kann jeder mysqld-Prozessabsturz die letzte Sekunde der Transaktionen löschen. Bei einem Wert von 2 kann nur ein Betriebssystemabsturz oder ein Stromausfall die letzte Sekunde der Transaktionen löschen. Die Crash-Wiederherstellung von InnoDB funktioniert unabhängig vom Wert.

Meiner Meinung nach mit innodb_flush_log_at_trx_commit bis 2 sollte kein Problem sein. Die Verwendung von 1 ist jedoch am sichersten.

26
Abdul Manaf

Meine Meinung unterscheidet sich von anderen. innodb_flush_log_at_trx_commit = 0 if: Es ist mein Entwicklungscomputer oder meine Home-Mini-Datenbank, in der keine vertraulichen Daten vorhanden sind.

innodb_flush_log_at_trx_commit = 2 if: Es handelt sich um Blog/Statistik/E-Commerce (mit ~ 100x Shop pro Tag) usw.

innodb_flush_log_at_trx_commit = 1 wenn: Sie viele Kunden haben oder mit Geldtransaktionen wie einer Bank arbeiten müssen. Daher sollten Sie diesmal Ihren Datenfluss auf mehrere Server aufteilen, um Geschwindigkeit und Sicherheit zu gewährleisten.

Ich bevorzuge 2, weil es ~ 75x schnellere Schreibgeschwindigkeit hat und es NUR ausfällt, wenn Hardware ausfällt.

Wie auch immer, Sie sollten wissen, was Sie brauchen, viel mehr Schreibgeschwindigkeit oder bis zu 1 Sekunde Informationen?

25
Sertekmedia

Ich versuche zu antworten, was ist der Zweck von innodb_flush_log_at_trx_commit?

InnoDB führt die meisten seiner Operationen im Speicher aus (InnoDB Buffer Pool). Alle geänderten Daten werden in InnoDB transaction log file Geschrieben und dann auf einen dauerhaften Speicher (Festplatte) übertragen (geschrieben).

Aus Gründen der Datensicherheit (Durability from ACID) Muss InnoDB geänderte Daten jeder Transaktion in einem permanenten Speicher speichern. Gleichzeitig ist das Festschreiben auf die Festplatte für jede Transaktion ein kostspieliger Prozess.

Festplatten-E/A ist ein Blockierungsprozess und sehr langsam. Es handelt sich um eine langsame Festplatte. Außerdem wird die Anzahl von InnoDB transaction per seconds (Festplattendurchsatz) verringert.

InnoDB bietet die Variable innodb_flush_log_at_trx_commit, Um die Häufigkeit dieses Spülvorgangs zu steuern. Basierend auf dem Wert verhält sich der InnoDB-Spülvorgang anders.

(Bereits in anderen Antworten erklärt)

0 - In jede Sekunde in die Protokolldatei schreiben und auf die Festplatte leeren (Daten im Pufferpool werden nicht in die Protokolldatei geschrieben - zur Leistungssteigerung). 1 - Auf Festplatte leeren, wenn eine Transaktion festgeschrieben wird - Standard (Aus Gründen der Datensicherheit - ACID-Konformität) 2 - Für jede Transaktion in die Protokolldatei schreiben und jede Sekunde auf die Festplatte leeren. (Für Leistungssteigerung)

Abhängig von der Anwendungsanforderung (Performance Vs data safety) Können Sie diese Variable festlegen. Der Unterschied zwischen 0 und 2 - beide erhöhen die Leistung, Wert 2 speichert die Daten in der Transaktionsdatei und kann im Falle eines Absturzes oder Fehlers wiederhergestellt werden, jedoch nicht in 0.

In vielen Fällen bedeutet "Flush to Disk", dass die Daten von InnoDB buffer pool (memory) to Operating systems cache geschrieben werden, die nicht tatsächlich auf die Speicherplatte geschrieben wurden (permanenter Speicher). Im schlimmsten Fall können Sie im schlimmsten Fall Daten bis zu einer Sekunde verlieren.

Der Leistungsgewinn hängt von der Umgebung ab und Sie können ihn bewerten und identifizieren. Setzen Sie in einer Replikationsumgebung aus Gründen der Datensicherheit und -konsistenz innodb_flush_log_trx_commit = 1 Und sync_binlog=1.

Wenn die Leistung das Hauptziel der Anwendung ist, bietet InnoDB eine Variable zur Steuerung der Häufigkeit des Protokollspülens - innodb_flush_log_at_timeout - mit der Sie den Frequenzbereich für das Protokollspülen von 1 to 2700 seconds Festlegen können. Standardmäßig ist dies 1.

Beachten Sie, dass beim Erhöhen des Spülintervalls auf N Sekunden eine Leistungssteigerung mit einer Beeinträchtigung der Datensicherheit von bis zu N Sekunden verbunden ist. Wenn Sie beispielsweise festlegen, dass alle 5 Sekunden eine Spülung erfolgt, ist die Durchsatzverstärkung sehr hoch. Bei einem Stromausfall oder einem Systemabsturz gehen jedoch Daten im Wert von 5 Sekunden verloren.

Dieser Artikel beschreibt InnoDB-Leeren und Transaktions-Commit Operationen.

Sie können ändern, nachdem Sie Modus 2 auf aws rds ausgeführt haben:

(can change after you do mode 2 on aws

(previewchanges

In einigen Fällen nicht änderbar, z. B. wenn Sie über eine Replikation von mehreren A bis Z verfügen:

(FYI unmodifiable in some cases

3
Rathish

Wenn Ihre Hardware ausfällt, können Sie alle Ihre Daten verlieren, sodass ich param = 2 ohne Sorgen verwende. Auf jeden Fall können Sie Ihre sensiblen (Bestellung, virtuelles Geld, ...) und regulären (Statistiken, Warenkorb, ...) Daten auf 2-DB-Server aufteilen und diese sicher und schnell aufbewahren. Für Transaktionen zwischen Datenbanken können Sie http://dev.mysql.com/doc/refman/5.7/en/xa.html verwenden

1