Beherrschen Sie den Prozess des Schreibens von Binärprotokollen in MySQL vollständig

Dieser Artikel vermittelt Ihnen relevantes Wissen über den Prozess des Schreibens von Binärprotokollen in MySQL, einschließlich Fragen im Zusammenhang mit „sync_binlog“, „binlog_cache_size“ und „max_binlog_cache_size“. Ich hoffe, dass er für alle hilfreich ist.

Binärprotokoll-Schreibprozess

Werfen wir zunächst einen Blick auf die Beschreibung der sync_binlog-Konfiguration im offiziellen Dokument.

sync_binlog

Befehlszeilenformat	--sync-binlog=#
Systemvariablen	. sync _binlog
Einflussbereich	Global
Dynamisch	Ja
SET_VAR-Eingabeaufforderung gilt	Nein
Typ	Ganzzahl
Standard.	1
Minimaler Wert	0
Maximaler Wert	2^32=4294967295

Steuern Sie, wie oft der MySQL-Server Binärprotokolle mit der Festplatte synchronisiert.

• sync_binlog=0: MySQL-Server daran hindern, Binärprotokolle mit der Festplatte zu synchronisieren. Stattdessen verlässt sich der MySQL-Server darauf, dass das Betriebssystem das Binärprotokoll von Zeit zu Zeit auf die Festplatte schreibt, so wie es auch jede andere Datei tun würde. Diese Einstellung bietet die beste Leistung, aber im Falle eines Stromausfalls oder eines Betriebssystemabsturzes verfügt der Server möglicherweise über festgeschriebene Transaktionen, die noch nicht geleert wurden.

• sync_binlog=1: Aktivieren Sie die Synchronisierung des Binärprotokolls mit der Festplatte, bevor Sie eine Transaktion festschreiben. Dies ist die sicherste Einstellung, kann sich jedoch aufgrund erhöhter Schreibvorgänge auf die Festplatte negativ auf die Leistung auswirken. Bei einem Stromausfall oder Betriebssystemabsturz liegen die im Binärlog verlorenen Transaktionen nur im vorbereiteten Zustand vor. Dies ermöglicht eine regelmäßige automatische Wiederherstellung zum Zurücksetzen von Transaktionen und stellt so sicher, dass Transaktionen nicht aus dem Binärprotokoll verloren gehen.

• sync_binlog=N, was ein anderer Wert als 0 oder 1 ist: Nachdem N Binärprotokoll-Übermittlungsgruppen gesammelt wurden, wird das Binärprotokoll mit der Festplatte synchronisiert. Im Falle eines Stromausfalls oder eines Betriebssystemabsturzes kann es sein, dass der Server Transaktionen festgeschrieben hat, die noch nicht in das Binärprotokoll geschrieben wurden. Diese Einstellung kann sich aufgrund erhöhter Festplattenschreibvorgänge negativ auf die Leistung auswirken. Höhere Werte verbessern die Leistung, erhöhen jedoch das Risiko eines Datenverlusts.

InnoDBUm die größtmögliche Haltbarkeit und Konsistenz in einem mit Transaktionen verwendeten Replikationssetup zu erreichen, verwenden Sie die folgenden Einstellungen: InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：

• sync_binlog=1.
• innodb_flush_log_at_trx_commit=1.

警告

许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新，即使它还没有发生。在这种情况下，即使使用推荐的设置也无法保证事务的持久性，在最坏的情况下，断电可能会损坏InnoDB

sync_binlog=1.

innodb_flush_log_at_trx_commit=1.

WARNUNG
• Viele Betriebssysteme und einige Festplattenhardware betrügen den Flush-to-Disk-Vorgang. Sie teilen mysqld möglicherweise mit, dass eine Aktualisierung stattgefunden hat, obwohl dies noch nicht geschehen ist. In diesem Fall ist die Haltbarkeit der Transaktion selbst mit den empfohlenen Einstellungen nicht gewährleistet und im schlimmsten Fall kann ein Stromausfall die InnoDB-Daten beschädigen. Durch die Verwendung eines batteriegepufferten Festplattencaches im SCSI-Festplattencontroller oder auf der Festplatte selbst werden Dateiaktualisierungen beschleunigt und der Betrieb sicherer. Sie können auch versuchen, das Caching von Festplattenschreibvorgängen im Hardware-Cache zu deaktivieren.
• Zusammenfassung

sync_binlog-Einstellungstyp ist eine vorzeichenlose Ganzzahl.

Im Allgemeinen ist es nicht auf 0 gesetzt. 0 hängt vom Systembetrieb und unregelmäßigem fsync ab. Gefährlicher ist es, wenn ein Stromausfall oder ein Systemabsturz auftritt – die Transaktion wird übermittelt, aber das Binärprotokoll fehlt.

Es ist sicherer, den Wert auf 1 zu setzen, um die maximal mögliche Haltbarkeit und Konsistenz zu erreichen und die anschließende Master-Slave-Replikation und -Wiederherstellung sicherzustellen. Dies wirkt sich jedoch nachteilig auf die Leistung aus und kann eingestellt werden, wenn die vom Unternehmen benötigten IOPS nicht hoch sind.

Der Zweck des Festlegens eines Werts größer als 1 besteht darin, die Leistung zu verbessern. Dies ist nicht nur eine intelligente Methode zum Festschreiben einer Transaktion, sondern auch bei einem Stromausfall oder einem Systemabsturz. das Binärprotokoll wird mehr fehlen. Es wäre sicherer, wenn die Festplatte selbst einen batteriegepufferten Festplatten-Cache verwenden würde. Daher kann es eingestellt werden, wenn die vom Unternehmen benötigten IOPS relativ hoch sind, aber im Allgemeinen wird es nicht zu groß eingestellt und kann im Bereich [100, 1000] liegen. Sehen wir uns weiterhin die Cache-bezogene Konfiguration des Binärprotokolls an, wenn die Transaktion ausgeführt wird. Befehlsformat--binlog-cache-size=#Systemvariable. binlog_cache_sizerangeGolbalDynamischJaSET_VAR-Eingabeaufforderung giltNeinTypGanzzahlStandardwert32768Minimaler Wert4096Maximaler Wert ( 64 -Bit-Plattform)2^64=18446744073709547520max (32-Bit-Plattform)2^32=4294967295

Darüber hinaus können wir durch die Beschreibung von sync_binlog = 0 auch ungefähr das Gefühl haben, dass die Transaktion beim Senden zwar nicht sofort fsync ist, aber tatsächlich in den Seitencache des Dateisystems geschrieben wurde. MySQL befindet sich in der Transaktion. Beim Ausführen gibt es auch einen Cache, der das in der Transaktion generierte Binärprotokoll zwischenspeichert.	binlog_cache_size

🎜🎜🎜Blockgröße🎜🎜4096🎜 🎜🎜🎜

Die Größe des Speicherpuffers zur Speicherung binärer Protokolländerungen während einer Transaktion. Der Wert muss ein Vielfaches von 4096 sein.

Wenn die binäre Protokollierung auf einem Server aktiviert ist (die Systemvariable log_bin ist auf ON gesetzt), wird jedem Client ein binärer Protokollcache zugewiesen, wenn der Server eine Transaktionsspeicher-Engine unterstützt. Wenn die Daten einer Transaktion den Platz im Speicherpuffer überschreiten, werden die überschüssigen Daten in einer temporären Datei gespeichert. Wenn die binäre Protokollverschlüsselung auf dem Server aktiv ist, wird der Speicherpuffer nicht verschlüsselt, aber (ab MySQL 8.0.17) werden alle temporären Dateien, die zum Speichern des binären Protokollcaches verwendet werden, verschlüsselt. Nachdem jede Transaktion festgeschrieben wurde, wird der Binärprotokoll-Cache zurückgesetzt, indem der Speicherpuffer gelöscht und die temporäre Datei (falls verwendet) abgeschnitten wird.

Wenn Sie häufig große Transaktionen verwenden, können Sie diese Cachegröße für eine bessere Leistung erhöhen, indem Sie das Schreiben temporärer Dateien reduzieren oder ganz überflüssig machen. Binlog_cache_use (Dienststatusvariable – die Anzahl der Transaktionen, die den Binärprotokoll-Cache verwenden) und Binlog_cache_disk_use (Dienststatusvariable – die Anzahl der Transaktionen, die den temporären Binärprotokoll-Cache verwenden, aber den binlog_cache_size-Wert überschreiten und temporäre Dateien zum Speichern von Transaktionsanweisungen verwenden.) Statusvariablen kann verwendet werden, um diese variable Größe anzupassen. Siehe Abschnitt 5.4.4, „Binärprotokolle“.

binlog_cache_sizeLegt nur die Größe des Transaktionscache fest; die Größe des Anweisungscache wird durch die Systemvariable binlog_stmt_cache_size gesteuert.

Zusammenfassung

• Der Einstellungstyp „binlog_cache_size“ ist eine vorzeichenlose Ganzzahl.
• wird verwendet, um die Größe anzugeben, die während jeder Transaktion zum Zwischenspeichern des Binärprotokolls verwendet wird. Der Standardwert ist 32 KB und muss ein Vielfaches von 4096 sein. Wenn dieser Wert überschritten wird, wird ein temporärer Dateispeicher verwendet.
• Versuchen Sie, im Geschäftsleben keine großen Transaktionen durchzuführen. Wenn die Transaktion zu groß ist, müssen Sie überlegen, ob sie angemessen ist. Im Allgemeinen besteht keine Notwendigkeit, binlog_cache_size zu ändern, 32 KB reichen aus.
• Wenn binlog_cache_size nicht ausreicht, werden temporäre Dateien zur Speicherung verwendet, die Leistung ist jedoch geringer. Wir können max_binlog_cache_size=binlog_cache_size festlegen, sodass keine temporären Dateien verwendet werden, was weiter unten erläutert wird.

max_binlog_cache_size

Befehlsformat	--max-binlog-cache-size=#
Systemvariablen	max_binlog_cache_size
range	Golbal
Dynamisch	Ja
SET_VAR-Eingabeaufforderung gilt	Nein
Typ	Ganzzahl
Standardwert	2^64 =18 446744073709547520
Minimum	4096
maximal	2^64=18446744073709547520
Blockgröße	4096

Wenn eine Transaktion mehr als diese Anzahl an Bytes Speicher benötigt, generiert der Server eine Transaktion mit mehreren Anweisungen, die mehr als „max_binlog_cache_size“ Bytes an Speicherfehler erfordert. Der Mindestwert ist 4096. Der maximal mögliche Wert beträgt 16EiB (Exbibyte). Der empfohlene Höchstwert liegt bei 4 GB. Dies liegt daran, dass MySQL derzeit keine binären Protokollspeicherorte verarbeiten kann, die größer als 4 GB sind. Der Wert muss ein Vielfaches von 4096 sein.

max_binlog_cache_size legt nur die Größe des Transaktionscache fest; die Obergrenze des Anweisungscache wird durch die Systemvariable max_binlog_stmt_cache_size gesteuert. max_binlog_cache_size仅设置事务缓存的大小；语句缓存的上限由 max_binlog_stmt_cache_size 系统变量控制。

会话的可见性 max_binlog_cache_size

Die Sichtbarkeit der Sitzung max_binlog_cache_size entspricht der Sichtbarkeit der Systemvariablen binlog_cache_size. Mit anderen Worten: Eine Änderung ihres Werts wirkt sich nur auf neue Sitzungen aus, die nach der Änderung des Werts gestartet werden.

Zusammenfassung

• max_binlog_cache_size ist ein sicherer Wert, der im Allgemeinen entsprechend dem Speicher festgelegt wird, der vom Server zugewiesen werden kann.

Übersicht

Aus der obigen Konfiguration können wir den allgemeinen Schreibprozess des Binärprotokolls zeichnen:

1. Transaktionen werden in den Binärprotokoll-Cache jeder Transaktion geändert, wenn sie ausgeführt werden.
2. Nachdem die Transaktion übermittelt wurde, wird sie gemäß der Konfiguration ausgeführt. Wenn sync_binlog=1 ist, wird der Cache jedes Mal freigegeben, wenn fsync ausgeführt wird. Wenn sync_binlog = 0, wird es direkt in den Seitencache der Systemdatei geschrieben, wobei das Betriebssystem das Binärprotokoll von Zeit zu Zeit leert. Wenn sync_binlog=N (N>1) ist, entspricht dies einer Stapellöschung. Natürlich wird der von jeder Transaktion gehaltene Binlog-Cache freigegeben.

Der allgemeine Prozess ist also wie folgt:

Zusammenfassung

Bisher haben wir ein grobes Verständnis des Prozesses des Schreibens von MySQL in Binär, der Folgendes durchlaufen muss: Binlog-Cache, der von jeder Transaktion gehalten wird -> Seitencache des Dateisystems -> Die spezifische Ausführungsstrategie kann über sync_binlog gesteuert werden.

Verwenden Sie

• sync_binlog: Wenn Sie maximale Haltbarkeit und Konsistenz benötigen, setzen Sie es auf 1. Bei Leistungsproblemen können Sie die Hardware und andere Methoden anpassen; wenn das Binärprotokoll durch andere Methoden verloren gehen darf Methoden, die Sie basierend auf der aktuellen Situation steuern möchten, werden optimiert und im Intervall [100,1000] festgelegt.
• binlog_cahe_size: Wie bereits erwähnt, muss im tatsächlichen Geschäft auf die Kontrolle der Transaktionsgranularität geachtet werden. In den meisten Fällen ist der Standardwert von 32 KB ausreichend.

Empfohlenes Lernen: MySQL-Video-Tutorial

🎜

Das obige ist der detaillierte Inhalt vonBeherrschen Sie den Prozess des Schreibens von Binärprotokollen in MySQL vollständig. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!