Vor kurzem habe ich einen MySQL-Master-Slave-Datenbanksynchronisationstest durchgeführt und einige Probleme festgestellt, darunter das Problem der Master-Slave-Synchronisationsverzögerung. Der folgende Inhalt enthält einige im Internet gefundene Erklärungen, die zum eigenen Lernen aufgezeichnet wurden ;
Die Master-Slave-Synchronisation von MySQL ist eine sehr ausgereifte Architektur. Die Vorteile sind: ① Abfragearbeiten können auf dem Slave-Server ausgeführt werden (das heißt, was wir oft als Lesefunktion bezeichnen), was den Druck verringert der Master-Server; ② Die Sicherung wird auf dem Slave-Master-Server durchgeführt, um den Backup-Zeitraum zu vermeiden. ③ Wenn ein Problem mit dem Hauptserver auftritt, können Sie zum Slave-Server wechseln.
Ich glaube, dass sich jeder dieser Vorteile sehr bewusst ist und diese Lösung auch im Projekteinsatz übernehmen wird. Bei der Master-Slave-Synchronisation von MySQL gab es jedoch schon immer das Problem der Verzögerung der Slave-Datenbank. Warum tritt dieses Problem auf? Wie kann dieses Problem gelöst werden?
1. Prinzip der Master-Slave-Synchronisationsverzögerung der MySQL-Datenbank.
2. Wie kommt es zur Verzögerung der MySQL-Datenbank-Master-Slave-Synchronisierung?
3. MySQL-Datenbank-Master-Slave-Synchronisationsverzögerungslösung.
1. Prinzip der Master-Slave-Synchronisationsverzögerung der MySQL-Datenbank.
Antwort: Wenn es um das Prinzip der Master-Slave-Synchronisationsverzögerung in der MySQL-Datenbank geht, müssen wir mit dem Prinzip der Master-Slave-Replikation der MySQL-Datenbank beginnen. Die Master-Slave-Replikation von MySQL ist ein Single-Thread-Vorgang , und die Hauptdatenbank generiert das gesamte DDL- und DML-Binlog. Das Binlog wird nacheinander geschrieben, sodass es sehr effizient ist. Der Slave_IO_Running-Thread geht zur Hauptbibliothek, um das Protokoll abzurufen, was sehr effizient ist . Der Slave_SQL_Running-Thread des Slaves implementiert die DDL- und DML-Operationen der Hauptbibliothek auf dem Slave. Die E/A-Vorgänge von DML und DDL sind zufällig und nicht sequentiell, und die Kosten sind viel höher. Andere Abfragen auf dem Slave können ebenfalls zu Sperrenkonflikten führen. Da Slave_SQL_Running ebenfalls Single-Threaded ist, dauert die Ausführung eines DDL-Kartenmasters 10 Minuten. Dann warten alle nachfolgenden DDLs auf die Ausführung dieses DDLs, bevor sie fortfahren, was zu Verzögerungen führt. Einige Freunde werden fragen: „Derselbe DDL in der Hauptbibliothek muss auch 10 Minuten lang ausgeführt werden. Warum ist der Slave verzögert?“ Die Antwort ist, dass der Master gleichzeitig ausgeführt werden kann, der Slave_SQL_Running-Thread jedoch nicht.
2. Wie kommt es zur Verzögerung der MySQL-Datenbank-Master-Slave-Synchronisierung?
Antwort: Wenn die TPS-Parallelität der Hauptbibliothek hoch ist und die Anzahl der generierten DDL den Bereich überschreitet, den ein SQL-Thread des Slaves aushalten kann, kommt es zu Verzögerungen und natürlich kann es zu großen Abfrageanweisungen kommen Beim Slave kommt es zu einer Sperrwartezeit.
3. MySQL-Datenbank-Master-Slave-Synchronisationsverzögerungslösung
Antwort: Die einfachste Lösung zur Reduzierung der Slave-Synchronisationsverzögerung besteht darin, die Architektur zu optimieren und zu versuchen, die DDL der Hauptdatenbank schnell auszuführen. Es gibt auch die Tatsache, dass die Hauptbibliothek eine hohe Datensicherheit aufweist, z. B. sync_binlog = 1, innodb_flush_log_at_trx_commit = 1. Der Slave benötigt jedoch keine so hohe Datensicherheit. Sie können sync_binlog auf 0 oder setzen Binlog deaktivieren kann auch auf 0 gesetzt werden, um die SQL-Ausführungseffizienz zu verbessern. Die andere besteht darin, ein besseres Hardwaregerät als die Hauptbibliothek als Slave zu verwenden.
mysql-5.6.3 unterstützt bereits die Multithread-Master-Slave-Replikation. Das Prinzip ähnelt dem von Ding Qi und verwendet Tabellen als Multithreads, während Oracle die Datenbank (Schema) als Einheit für Multithreads verwendet. Verschiedene Bibliotheken können unterschiedliche Replikationsthreads verwenden.
sync_binlog=1
Dadurch synchronisiert MySQL den Inhalt des Binärprotokolls jedes Mal mit der Festplatte, wenn eine Transaktion festgeschrieben wird.
Standardmäßig wird nicht jedes Schreib-Binlog mit der Festplatte synchronisiert . Wenn daher das Betriebssystem oder die Maschine (nicht nur der MySQL-Server) abstürzt, ist es möglich, dass die letzte Anweisung im Binlog verloren geht. Um dies zu verhindern, können Sie die globale Variable sync_binlog (1 ist der sicherste Wert, aber auch der langsamste) verwenden, um Binlog nach jedem N Binlog-Schreibvorgang mit der Festplatte zu synchronisieren. Auch wenn sync_binlog auf 1 gesetzt ist, kann es bei einem Absturz zu Inkonsistenzen zwischen dem Tabelleninhalt und dem Binlog-Inhalt kommen. Wenn Sie eine InnoDB-Tabelle verwenden, verarbeitet der MySQL-Server die COMMIT-Anweisung, schreibt die gesamte Transaktion in das Binlog und schreibt die Transaktion an InnoDB fest. Wenn zwischen zwei Vorgängen ein Absturz auftritt, wird die Transaktion beim Neustart von InnoDB zurückgesetzt, sie ist jedoch weiterhin im Binlog vorhanden. Sie können die Option --innodb-safe-binlog verwenden, um die Konsistenz zwischen den Inhalten der InnoDB-Tabelle und dem Binlog zu erhöhen. (Hinweis: --innodb-safe-binlog ist in MySQL 5.1 nicht erforderlich; diese Option ist aufgrund der Einführung von veraltet) und (standardmäßig true) das InnoDB-Protokoll wird mit der Festplatte synchronisiert. Die Auswirkung dieser Option ist Beim Neustart nach einem Absturz schneidet der MySQL-Server nach dem Rollback der Transaktion die zurückgesetzte InnoDB-Transaktion aus dem Binlog aus. Dadurch wird sichergestellt, dass das Binlog die genauen Daten der InnoDB-Tabelle usw. zurückmeldet und den Slave-Server mit dem Master-Server synchron hält (ohne Rollback-Anweisungen zu empfangen).
innodb_flush_log_at_trx_commit (das funktioniert sehr gut)
Beschweren Sie sich, dass Innodb 100-mal langsamer ist als MyISAM? Dann haben Sie wahrscheinlich vergessen, diesen Wert anzupassen. Der Standardwert 1 bedeutet, dass jeder Transaktions-Commit oder jede Anweisung außerhalb der Transaktion das Protokoll auf die Festplatte schreiben muss (Flush), was sehr zeitaufwändig ist. Besonders wenn der batteriegepufferte Cache verwendet wird. Die Einstellung auf 2 ist für viele Anwendungen in Ordnung, insbesondere für solche, die aus MyISAM-Tabellen übertragen werden. Dies bedeutet, dass nicht auf die Festplatte, sondern in den Systemcache geschrieben wird. Die Protokolle werden weiterhin jede Sekunde auf die Festplatte geschrieben, sodass Sie im Allgemeinen nicht mehr als 1–2 Sekunden an Aktualisierungen verlieren. Die Einstellung auf 0 ist schneller, aber die Sicherheit ist schlecht. Selbst wenn MySQL hängen bleibt, können Transaktionsdaten verloren gehen. Der Wert 2 führt nur dann zu Datenverlust, wenn das gesamte Betriebssystem hängt.
Das obige ist der detaillierte Inhalt vonLösung des Problems der Verzögerung der Master-Slave-Datenbanksynchronisierung in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
