--innodb

Aktiviert die InnoDB-Speicher-Engine, wenn der Server mit InnoDB-Unterstützung kompiliert wurde. Mit --skip-innodb können Sie InnoDB deaktivieren.

--innodb_status_file

Veranlasst InnoDB, eine Datei namens <datadir>/innodb_status.<pid> im MySQL Data Directory anzulegen. InnoDB schreibt in regelmäßigen Abständen die Ausgabe von SHOW ENGINE INNODB STATUS in diese Datei.

innodb_additional_mem_pool_size

Die Größe des von InnoDB zum Speichern von Data Dictionary-Informationen und anderen internen Datenstrukturen verwendeten Arbeitsspeicherpools in Bytes. Je mehr Tabellen Ihre Anwendung hat, umso mehr Arbeitsspeicher müssen Sie hier zuweisen. Wenn InnoDB in diesem Pool der Speicher ausgeht, beginnt es, Arbeitsspeicher vom Betriebssystem abzuzweigen, und gibt Warnmeldungen in das MySQL-Fehlerlog aus. Der Standardwert beträgt 1MB.

innodb_autoextend_increment

In Inkrementen dieser Größe (in MB) wächst ein selbsterweiternder Tablespace, wenn er vollläuft. Der Standardwert beträgt 8.

innodb_buffer_pool_awe_mem_mb

Die Größe des Bufferpools (in MB), wenn er im AWE-Speicher liegt. Dies gilt jedoch nur für 32-Bit Windows. Wenn Ihr 32-Bit Windows-Betriebssystem über die so genannten „Address Windowing Extensions“ mehr als 4GB Arbeitsspeichergröße unterstützt, können Sie den InnoDB-Bufferpool im physikalischen AWE-Speicher mit dieser Variablen zuweisen. Der größtmögliche Wert der Variablen beträgt 63000. Ist er größer als 0, ist innodb_buffer_pool_size das Fenster im 32-Bit-Adressraum von mysqld, wobei InnoDB diesen AWE-Arbeitsspeicher abbildet. Ein guter Wert für innodb_buffer_pool_size ist 500MB.

Um den AWE-Speicher nutzen zu können, müssen Sie MySQL neu kompilieren. Welche Projekteinstellungen derzeit dazu erforderlich sind, entnehmen Sie bitte der Quelldatei storage/innobase/os/os0proj.c.

innodb_buffer_pool_size

Die Größe des Arbeitsspeicherpuffers in Bytes, den InnoDB zum Zwischenspeichern der Daten und Indizes seiner Tabellen benutzt. Je größer Sie diesen Wert einstellen, umso weniger Festplattenzugriffe sind für den Zugriff auf die Tabellendaten erforderlich. Für einen dedizierten Datenbankserver können Sie dies auf 80% des physikalischen Arbeitsspeichers heraufsetzen. Machen Sie ihn jedoch nicht zu groß, da ein Wettlauf um den physikalischen Speicher das Betriebssystem zum Paging veranlassen kann.

innodb_checksums

InnoDB kann für alle von der Platte gelesenen Seiten eine Prüfsummenvalidierung verwenden, um eine zusätzliche Fehlertoleranz gegenüber Schäden an Hardware oder Datendateien zu gewährleisten. Diese Validierung ist standardmäßig eingeschaltet. Doch in einigen wenigen Fällen (zum Beispiel bei der Ausführung von Benchmarks) ist diese zusätzliche Sicherheitsvorkehrung überflüssig und kann mit --skip-innodb-checksums deaktiviert werden.

innodb_commit_concurrency

Die Anzahl der Threads, die gleichzeitig committen können. Der Wert 0 schaltet die Nebenläufigkeitssteuerung aus.

innodb_concurrency_tickets

Wie viele Threads gleichzeitig auf InnoDB zugreifen können, hängt von der Einstellung der innodb_thread_concurrency-Variablen ab. Ein Thread wird in eine Schlange gestellt, wenn er auf InnoDB zugreifen möchte und das Nebenläufigkeitslimit bereits erreicht ist. Wenn einem Thread der Eintritt in InnoDB erlaubt wird, bekommt eine Anzahl von „Freifahrscheine“, die der Anzahl der innodb_concurrency_tickets entspricht und kann InnoDB so lange nach Belieben betreten und verlassen, bis seine Freifahrscheine aufgebraucht sind. Danach wird der Thread wieder einer Prüfung unterzogen (und eventuell in die Schlange gestellt), wenn er das nächste Mal in InnoDB eintreten möchte.

innodb_data_file_path

Die Pfade und Größen der einzelnen Datendateien. Der vollständige Verzeichnispfad zu den Datendateien entsteht, wenn innodb_data_home_dir mit den einzelnen, hier angegebenen Pfaden verkettet wird. Die Dateigrößen werden in MB oder GB (1024MB) durch Anfügen von M oder G an den Größenwert angegeben. Die Summe der Dateigrößen muss mindestens 10MB betragen. Wenn Sie keinen innodb_data_file_path angeben, wird standardmäßig eine einzige, selbsterweiternde, 10MB große Datendatei namens ibdata1 erzeugt. Wie groß die einzelnen Dateien werden können, entscheidet Ihr Betriebssystem. Auf Systemen, die große Dateien unterstützen, können Sie die Dateigröße auf mehr als 4GB setzen. Sie können auch rohe Festplattenpartitionen als Datendateien einsetzen. Siehe Abschnitt 14.2.3.2, „Verwendung von Raw Devices für den Shared Tablespace“.

innodb_data_home_dir

Der gemeinsame Teil des Verzeichnispfads für alle InnoDB-Datendateien. Wenn Sie diesen Wert nicht einstellen, ist das MySQL Data Directory das Ziel. Geben Sie hier einen leeren String an, so können Sie in innodb_data_file_path absolute Dateipfade verwenden.

innodb_doublewrite

Nach Voreinstellung speichert InnoDB alle Daten zweimal, nämlich zuerst in den Doublewrite-Puffer und dann in die eigentlichen Datendateien. Diese Variable ist standardmäßig eingeschaltet, kann aber mit der Option --skip-innodb_doublewrite ausgeschaltet werden, wenn Sie Benchmarks ausführen oder Ihnen eine Top-Performance so wichtig ist, dass Sie sich für Datenintegrität und mögliche Systemabstürze weniger interessieren.

innodb_fast_shutdown

Wenn Sie diese Variable auf 0 setzen, führt InnoDB vor dem Herunterfahren eine vollständige Purge-Operation und Verschmelzung der Insert-Puffer durch. Diese Operationen können Minuten oder im Extremfall sogar Stunden in Anspruch nehmen. Setzen Sie diese Variable auf 1, übergeht InnoDB beim Herunterfahren diese Operationen. Der Standardwert ist 1. Wenn Sie ihn auf 2 setzen, leert InnoDB nur die Logs und fährt dann kalt herunter, wie bei einem Absturz von MySQL. Es geht zwar keine committete Transaktion verloren, aber nach dem nächsten Hochfahren wird eine Wiederherstellung gefahren. Den Wert 2 können Sie nicht auf NetWare verwenden.

innodb_file_io_threads

Die Anzahl der Dateizugriffs-Threads in InnoDB. Normalerweise kann man den Standardwert 4 beibehalten, aber auf Windows kann eine größere Zahl die Festplattenzugriffe günstig beeinflussen. Auf Unix bleibt eine Erhöhung dieses Werts ohne Wirkung, da InnoDB immer den Standardwert verwendet.

innodb_file_per_table

Wenn diese Variable eingeschaltet ist, erzeugt InnoDB jede neue Tabelle mit ihrer eigenen .ibd-Datei zum Speichern von Daten und Indizes, anstatt im Shared Tablespace. Nach Voreinstellung werden die Tabellen im Shared Tablespace angelegt. Siehe Abschnitt 14.2.3.1, „Verwendung von Tabellen-Tablespaces (ein Tablespace pro Tabelle)“.

innodb_flush_log_at_trx_commit

Hat innodb_flush_log_at_trx_commit den Wert 0, wird einmal pro Sekunde der Logpuffer in die Logdatei geschrieben und diese auf die Festplatte zurückgespeichert, doch beim Committen einer Transaktion wird nichts veranlasst. Ist der Wert 1 (der Standard), wird bei jedem Commit der Logpuffer in die Logdatei und diese auf die Festplatte geschrieben. Ist der Wert 2, wird der Puffer bei jedem Commit in die Datei übertragen, aber diese nicht beim Commit, sondern einmal pro Sekunde auf die Festplatte zurückgeschrieben. Beachten Sie jedoch, dass dieser Schreibvorgang aus Gründen der Prozessplanung in Wirklichkeit nicht unbedingt exakt einmal pro Sekunde stattfindet.

Der Standardwert dieser Variablen, nämlich 1, ist für die ACID-Fähigkeit erforderlich. Ein anderer Wert als 1 kann zwar die Performance steigern, aber um den Preis, dass Sie bei einem Systemabsturz eine Sekunde an Transaktionen verlieren. Ist der Wert 0, kann jeder Absturz des mysqld-Prozesses die Transaktionen der letzten Sekunde ausradieren. Ist der Wert 2, würde dieser Datenverlust bei einem Betriebssystemabsturz oder Stromausfall eintreten. Da allerdings die Wiederherstellungsfunktion von InnoDB nicht beeinträchtigt wird, würde die Crash-Recovery unabhängig vom Wert dieser Variablen funktionieren. Beachten Sie jedoch, dass viele Betriebssysteme und einige Festplatten die Flush-to-Disk-Operation irreführen, indem sie mysqld weismachen, dass die Daten bereits auf die Festplatte geschrieben wurden, auch wenn das nicht der Fall ist. Die Dauerhaftigkeit von Transaktionen ist also selbst mit der Einstellung 1 nicht gewährleistet, und im schlimmsten Falle kann ein Stromausfall sogar die InnoDB-Datenbank beschädigen. Ein batteriegestützter Festplatten-Cache im SCSI-Festplattencontroller oder in der Festplatte selbst kann das Zurückschreiben von Dateien auf die Festplatte beschleunigen und die Operation sicherer machen. Außerdem können Sie mit dem Unix-Befehl hdparm das Caching von Festplatten-Schreibvorgängen in Hardware-Caches deaktivieren oder einen anderen Hardware-spezifischen Befehl verwenden.

innodb_flush_method

Die Standardeinstellung fdatasync sorgt dafür, dass InnoDB Daten- und Logdateien mit fsync() auf die Festplatte schreibt. Die Einstellung O_DSYNC lässt InnoDB Logdateien mit O_SYNC öffnen und auf die Festplatte schreiben, aber für Datendateien fsync() verwenden. Die (auf einigen GNU/Linux-Versionen mögliche) Einstellung O_DIRECT veranlasst InnoDB, Datendateien mit O_DIRECT zu öffnen und Daten- und Logdateien mit fsync() auf die Festplatte schreiben. Beachten Sie, dass InnoDB die Funktion fsync() anstelle von fdatasync() benutzt und O_DSYNC nicht standardmäßig einsetzt, weil dies mit vielen Unix-Varianten bereits zu Problemen geführt hat. Diese Variable ist nur für Unix relevant. Auf Windows wird immer und unabänderlich async_unbuffered zum Zurückschreiben von Daten auf die Festplatte verwendet.

innodb_force_recovery

Der Crash-Recovery-Modus. Diese Variable sollte nur im Notfall auf einen Wert größer 0 gesetzt werden, nämlich dann, wenn Tabellen aus einer beschädigten Datenbank gesichert werden sollen! Mögliche Werte liegen zwischen 1 und 6. Die Bedeutung dieser Werte ist in Abschnitt 14.2.8.1, „Erzwingen einer InnoDB-Wiederherstellung (Recovery)“ erläutert. Aus Sicherheitsgründen verhindert InnoDB jegliche Datenänderungen, wenn diese Variable auf einen größeren Wert als 0 gesetzt ist.

innodb_lock_wait_timeout

Gibt an, wie viele Sekunden eine InnoDB-Transaktion auf eine Sperre wartet, ehe sie zurückgerollt wird. InnoDB entdeckt automatisch Transaktions-Deadlocks in seiner eigenen Sperrentabelle und macht dann die Transaktion rückgängig. InnoDB erkennt Sperren, die mit der LOCK TABLES-Anweisung gesetzt wurden. Die Standardeinstellung beträgt 50 Sekunden.

Hinweis: Die größtmögliche Dauerhaftigkeit und Konsistenz in einer Replikationsumgebung mit InnoDB und Transaktionen erzielen Sie, wenn Sie in der my.cnf-Datei Ihres Masterservers innodb_flush_log_at_trx_commit=1 und sync_binlog=1 einstellen.

innodb_locks_unsafe_for_binlog

Diese Variable steuert Next-Key-Locking in InnoDB-Suchoperationen und Index-Scans. Standardmäßig ist diese Variable 0 (deaktiviert) und das Next-Key-Locking somit eingeschaltet.

Normalerweise benutzt InnoDB einen Algorithmus namens Next-Key-Locking. Zeilensperren funktionieren in InnoDB folgendermaßen: Wenn ein Tabellenindex durchsucht oder gescannt wird, errichtet InnoDB Shared oder exklusive Sperren auf allen gefundenen Indexeinträgen. Somit sind die Zeilensperren in Wirklichkeit Sperren auf Indexeinträgen. Diese Sperren betreffen auch die „Lücke“, die den Indexeinträgen vorausgeht. Wenn ein Benutzer eine Shared oder exklusive Sperre auf Eintrag R eines Index hat, können andere Benutzer keine neuen Indexeinträge unmittelbar vor R in diesen Index einfügen. Ist diese Variable eingeschaltet, wird Next-Key-Locking von InnoDB nicht nicht in Suchoperationen oder Index-Scans verwendet, wohl aber zur Sicherung von Fremdschlüssel-Constraints und Prüfung auf Schlüsselduplikate. Das Einschalten dieser Variablen kann Phantomprobleme verursachen: Angenommen, Sie möchten alle Kinder der child-Tabelle, die einen Identifier-Wert größer 100 haben, lesen und sperren, da Sie vorhaben, in den ausgewählten Zeilen später eine Spalte zu ändern:

SELECT * FROM child WHERE id > 100 FOR UPDATE;

Nehmen wir weiterhin an, auf der Spalte id ist ein Index definiert. Die Anfrage scannt diesen Index ab dem ersten Eintrag, in dem id größer als 100 ist. Wenn die auf den Indexeinträgen errichteten Sperren Einfügungen in den Lücken nicht ausschließen, kann ein anderer Client eine neue Zeile in die Tabelle einfügen. Wenn Sie dasselbe SELECT in derselben Transaktion ausführen, sehen Sie in der Ergebnismenge eine neue Zeile. Das führt auch dazu, dass InnoDB bei Einfügung neuer Elemente in die Datenbank keine Serialisierbarkeit garantieren kann. Folglich gewährleistet InnoDB bei Einschaltung dieser Variablen maximal die Isolationsebene READ COMMITTED. (Die Konfliktserialisierbarkeit ist aber nach wie vor garantiert.)

Die Einschaltung dieser Variablen hat noch einen Zusatzeffekt: InnoDB sperrt in einem UPDATE oder DELETE nur die Zeilen, die aktualisiert bzw. gelöscht werden. Dadurch werden Deadlocks zwar sehr unwahrscheinlich, können aber immer noch auftreten. Beachten Sie, dass das Einschalten dieser Variablen nach wie vor nicht erlaubt, dass UPDATE andere, ähnliche Operationen (wie etwa ein anderes UPDATE) übernimmt, selbst dann nicht, wenn die beiden Operationen unterschiedliche Zeilen betreffen. Betrachten Sie das nächste Beispiel, das mit folgender Tabelle beginnt:

CREATE TABLE A(A INT NOT NULL, B INT) ENGINE = InnoDB;
INSERT INTO A VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

Angenommen, ein Client führt folgende Anweisungen aus:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 5 WHERE B = 3;

Nehmen wir weiterhin an, dass danach ein anderer Client diese Anweisungen ausführt:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 4 WHERE B = 2;

In diesem Fall muss das zweite UPDATE auf ein Commit oder Rollback des ersten warten. Das erste UPDATE besitzt eine exklusive Sperre auf Zeile (2,3) und das zweite UPDATE versucht, während es die Zeilen scannt, für dieselbe Zeile ebenfalls eine Sperre zu erwerben, die es jedoch nicht bekommt. Das liegt daran, dass das zweite UPDATE zuerst eine exklusive Sperre auf einer Zeile erwirbt und dann feststellt ob diese Zeile zur Ergebnismenge gehört. Wenn nicht, gibt es die überflüssige Sperre wieder frei, sofern die Variable innodb_locks_unsafe_for_binlog eingeschaltet ist.

Also führt InnoDB das UPDATE Nummer eins folgendermaßen aus:

x-lock(1,2)
unlock(1,2)
x-lock(2,3)
update(2,3) to (2,5)
x-lock(3,2)
unlock(3,2)
x-lock(4,3)
update(4,3) to (4,5)
x-lock(5,2)
unlock(5,2)

Das zweite UPDATE führt InnoDB so aus:

x-lock(1,2)
update(1,2) to (1,4)
x-lock(2,3) - wait for query one to commit or rollback

innodb_log_arch_dir

Das Verzeichnis, in dem vollgeschriebene Logdateien archiviert werden, sofern die Archivierung von Logs eingeschaltet ist. Wenn ja, so sollte diese Variable auf denselben Wert wie innodb_log_group_home_dir gesetzt werden. Das ist jedoch nicht obligatorisch.

innodb_log_archive

Gibt an, ob InnoDB-Archivdateien protokolliert werden sollen. Diese Variable ist nur aus historischen Gründen noch vorhanden, wird aber nicht benutzt. Da MySQL die Backup-Recovery anhand seiner eigenen Logdateien durchführt, gibt es keinen Anlass, InnoDB-Logdateien zu archivieren. Die Variable hat den Standardwert 0.

innodb_log_buffer_size

Gibt in Bytes die Größe des Puffers an, den InnoDB benutzt, um Logdateien auf die Platte zu schreiben. Werte von 1MB bis 8MB sind hier annehmbar. Der Standardwert ist 1MB. Wenn Sie einen großen Logpuffer haben, können umfangreiche Transaktionen zuende laufen, ohne dass das Log vor dem Committen auf die Festplatte zurückgeschrieben werden muss. In einer Umgebung mit großen Transaktionen können Sie also Festplattenzugriffe reduzieren, indem Sie den Logpuffer vergrößern.

innodb_log_file_size

Die Größe jeder Logdatei einer Loggruppe in Bytes. Die kombinierte Größe der Logdateien muss auf 32-Bit-Rechnren weniger als 4GB sein. Der Standard ist 5MB. Annehmbar sind Werte zwischen 1MB und 1/N-tel der Größe des Bufferpools, wobei N die Anzahl der Dateien in einer Loggruppe ist. Je größer der Wert, umso weniger Checkpoint-Flushing ist im Bufferpool erforderlich, was wiederum Plattenzugriffe spart. Allerdings haben große Logdateien auch zur Folge, dass die Recovery nach einem Absturz langsamer läuft.

innodb_log_files_in_group

Die Anzahl der Logdateien in der Loggruppe. InnoDB benutzt die Dateien in zirkulärer Weise. Der (empfehlenswerte) Standardwert ist 2.

innodb_log_group_home_dir

Der Verzeichnispfad zu den InnoDB-Logdateien. Er muss denselben Wert haben wie innodb_log_arch_dir. Wenn Sie keine InnoDB-Logvariablen angeben, werden nach Voreinstellung zwei 5MB große Dateien namens ib_logfile0 und ib_logfile1 im MySQL Data Directory angelegt.

innodb_max_dirty_pages_pct

Ein Integer von 0 bis 100. Der Standardwert ist 90. Der Haupt-Thread in InnoDB versucht, Seiten aus dem Bufferpool derart zu schreiben, dass der Prozentsatz von noch nicht geschriebenen Seiten diesen Wert nicht übersteigt.

innodb_max_purge_lag

Diese Variable gibt an, wie lange INSERT-, UPDATE- und DELETE-Operationen aufgeschoben werden, wenn die Purge-Operationen hinterher hinken (siehe Abschnitt 14.2.12, „Implementierung der Multiversionierung“). Der Standardwert ist 0 (keine Verzögerungen).

Das Transaktionssystem von InnoDB pflegt eine Liste von Transaktionen, die Indexeinträge anhand von UPDATE- oder DELETE-Operationen zum Löschen vorgemerkt haben. Die Länge dieser Liste sei purge_lag. Wenn purge_lag den Wert innodb_max_purge_lag überschreitet, wird jede INSERT-, UPDATE- und DELETE-Operation um ((purge_lag/innodb_max_purge_lag)×10)–5 Millisekunden aufgeschoben. Diese Verzögerung wird alle zehn Sekunden am Anfang eines Purge-Batch berechnet. Die Operationen werden nicht aufgeschoben, wenn Purge nicht laufen kann, weil eine alte Consistent Read View die zu bereinigenden Zeilen sehen könnte.

Eine typische Einstellung für eine problematische Arbeitslast wäre 1 Million, wenn die Transaktionen nur etwa 100 Bytes klein sind und wir 100MB unbereinigte Zeilen in unseren Tabellen gestatten können.

innodb_mirrored_log_groups

Gibt an, wie viele identische Kopien von Loggruppen wir für die Datenbank bewahren. Zurzeit sollte dies auf 1 gesetzt werden.

innodb_open_files

Diese Variable ist nur dann von Belang, wenn Sie Multi-Tablespaces in InnoDB benutzen. Sie gibt an, wie viele .ibd-Dateien InnoDB höchstens gleichzeitig offen halten kann. Der Mindestwert ist 10 und der Standardwert 300.

Die für .ibd-Dateien verwendeten Dateideskriptoren sind ausschließlich für InnoDB da. Sie haben nichts mit der Serveroption --open-files-limit zu tun und beeinflussen nicht die Arbeit des Tabellen-Caches.

innodb_support_xa

Die Einstellung ON oder 1 (der Standard) schaltet die InnoDB-Unterstützung für zweiphasigen Commit in XA-Transaktionen ein. Die Aktivierung von innodb_support_xa verursacht eine zusätzliche Schreiboperation auf der Platte zur Vorbereitung der Transaktion. Wenn Sie sich für XA nicht interessieren, können Sie diese Variable mit der Einstellung OFF oder 0 deaktivieren, was die Schreibvorgänge auf der Festplatte reduziert und die InnoDB-Performance erhöht.

innodb_sync_spin_loops

Gibt an, wie oft ein Thread auf die Freigabe eines InnoDB-Mutex wartet, ehe er suspendiert wird.

innodb_table_locks

InnoDB beachtet LOCK TABLES; MySQL kehrt von LOCK TABLE .. WRITE erst zurück, wenn alle anderen Threads alle ihre Sperren auf der Tabelle freigegeben haben. Der Standardwert 1 bedeutet, dass LOCK TABLES InnoDB veranlasst, eine Tabelle intern zu sperren. In Anwendungen mit AUTOCOMMIT=1 können die internen Tabellensperren von InnoDB Deadlocks verursachen. Sie können innodb_table_locks=0 in der Datei der Serveroptionen einstellen, um dieses Problem zu beheben.

innodb_thread_concurrency

InnoDB versucht, die Anzahl der nebenläufigen Betriebssystem-Threads innerhalb von InnoDB kleiner oder gleich dem in dieser Variablen festgelegten Höchstwert zu halten. Wenn Sie Performance-Probleme haben und SHOW ENGINE INNODB STATUS zeigt, dass viele Threads auf Semaphoren warten, haben Sie es vielleicht mit Thread-„Überlastung“ zu tun. In diesem Fall setzen sie diese Variable herunter oder herauf. Wenn Ihr Computer über viele Prozessoren und Festplatten verfügt, können Sie diesen Wert heraufsetzen, um Ihre Ressourcen besser auszunutzen. Ein empfehlenswerter Wert ist die Summe der Prozessoren und Festplatten, über die Ihr System verfügt. Beträgt der Wert 500 oder mehr, wird die Nebenläufigkeitsprüfung deaktiviert. Der Standardwert ist 20 und die Nebenläufigkeitsprüfung wird deaktiviert, wenn er auf größer oder gleich 20 eingestellt wird.

innodb_thread_sleep_delay

Gibt in Mikrosekunden an, wie lange InnoDB-Threads schlafen, bevor sie in die InnoDB-Schlange eintreten. Der Standardwert ist 10.000. Der Wert 0 schaltet den Schlaf aus.

sync_binlog

Hat diese Variable einen positiven Wert, synchronisiert der MySQL-Server sein Binärlog nach jedem sync_binlogten Schreibvorgang mittels fdatasync() auf die Festplatte. Im Autocommit-Modus entsteht pro Anweisung und ansonsten pro Transaktion ein Eintrag ins Binärlog. Der Standardwert 0 veranlasst keine Festplatten-Synchronisierung. Der Wert 1 ist am sichersten, da bei einem Absturz nur maximal eine Anweisung/Transaktion aus dem Binärlog verloren geht. Er ist aber auch am langsamsten (sofern nicht die Festplatte einen batteriegestützten Cache hat; dies würde die Synchronisierung sehr schnell machen).