Der Grund für die Recherche zu diesem Inhalt besteht hauptsächlich darin, zwei bisher aufgetretene unbeantwortete Zweifel auszuräumen:
a. Es gibt ein System, das häufig von halbsynchron zu asynchron wechselt und dann sofort wieder zu halbsynchron wechselt. Der genaue Grund ist mir jedoch nicht bekannt.
b. Vor einiger Zeit haben wir aufgrund der Anforderungen des Geschäftsszenarios einen maschinenraumübergreifenden asynchronen Replikationstest durchgeführt. Wenn die MySQL-Schreib-QPS sehr hoch ist, wurde festgestellt, dass viele Protokolle keine Zeit hatten, an die Slave-Bibliothek gesendet zu werden. Das heißt, die Geschwindigkeit der Binlog-Protokollgenerierung in der Hauptbibliothek ist höher als die Geschwindigkeit der Übertragung an die Slave-Bibliothek Dieser Geschwindigkeitsunterschied besteht immer. Wenn also die Hauptbibliothek weiterhin hoch ist. Wenn das Binlog unter Druck generiert wurde, wurden immer mehr Binlogs nicht an die Slave-Bibliothek übertragen, aber der Netzwerkverkehr betrug zu diesem Zeitpunkt nur etwa 18 M/S ( Ein Master, ein Slave. Nach herkömmlichem Wissen kann die Geschwindigkeit der Gigabit-Netzwerkübertragung 100 MB erreichen, aber die aktuelle Binlog-Übertragungsgeschwindigkeit zwischen Master und Slave erreicht nur etwa 18 MB. Handelt es sich um ein Netzwerkproblem? Oder aus anderen Gründen.
Master-Slave-Replikationsprinzip Dump-Thread und io-ThreadWenn die Master-Slave-Replikationsbeziehung hergestellt ist, gibt es in der Master-Bibliothek einen Dump-Thread, der zum Übertragen des in der Master-Bibliothek generierten Binlog-Protokolls verwendet wird, und der IO-Thread in der Slave-Bibliothek wird zum Empfangen der gesendeten Daten verwendet vom Dump-Thread über das Netzwerk-Binlog-Protokoll an die Slave-Bibliothek gesendet und ist für das Schreiben in das Relay-Protokoll verantwortlich. Dies ist der Mechanismus der Master-Slave-Replikation. Da es sich um eine asynchrone Replikation handelt, ist für den Übertragungsprozess keine Bestätigung erforderlich.
Die Frage stellt sich auch hier: Da es sich um eine asynchrone Übertragung handelt, sollte die Geschwindigkeit, wenn man sie einfach als direkte Netzwerkübertragung von Binlog-Dateien versteht, sehr hoch sein, aber die tatsächliche Situation: In unserer Testumgebung beträgt die Übertragungsgeschwindigkeit von Binlog-Protokollen nur 18 M/s, was weniger ist als die vom Protokoll erzeugte Geschwindigkeit von etwa 22 M/s. Warum läuft es nur mit dieser Geschwindigkeit und nutzt die Netzwerkbandbreite nicht vollständig aus? was ist der Grund?
Lieferdetails protokollierenIn der Master-Slave-Replikationsstruktur gibt es einen Dump-Thread in der Master-Bibliothek und einen IO-Thread in der Slave-Bibliothek, sodass nicht mehrere Threads gleichzeitig gesendet und empfangen werden. Sie müssen nur den Arbeitsmechanismus des Binlogs verstehen Dump-Thread, um alle Details zu verstehen.
Durch das Parsen der Binlog-Datei können wir erkennen, dass eine Transaktion mehrere Ereignisse enthalten kann. Die folgenden Informationen sind im Binlog der einfachsten Sache aufgezeichnet:
# at 33580 #170531 17:22:53 server id 153443358 end_log_pos 33645 CRC32 0x4ea17869 GTID last_committed=125 sequence_number=126 SET @@SESSION.GTID_NEXT= ‘e1028e43-4123-11e7-a3c2-005056aa17e6:198’/*!*/; # at 33645 #170531 17:22:53 server id 153443358 end_log_pos 33717 CRC32 0x66820e00 Query thread_id=4 exec_time=0 error_code=0 SET TIMESTAMP=1496222573/*!*/; BEGIN /*!*/; # at 33717 #170531 17:22:53 server id 153443358 end_log_pos 33770 CRC32 0x22ddf25e Table_map: `test`.`xcytest` mapped to number 222 # at 33770 #170531 17:22:53 server id 153443358 end_log_pos 33817 CRC32 0x61051ea0 Write_rows: table id 222 flags: STMT_END_F BINLOG ‘ bYsuWRMeXCUJNQAAAOqDAAAAAN4AAAAAAAEABHRlc3QAB3hjeXRlc3QAAgMPAlgCAl7y3SI= bYsuWR4eXCUJLwAAABmEAAAAAN4AAAAAAAEAAgAC//x9AAAABQBzZGZhc6AeBWE= ‘/*!*/; ### INSERT INTO `test`.`xcytest` ### SET ### @1=125 /* INT meta=0 nullable=0 is_null=0 */ ### @2=’sdfas’ /* VARSTRING(600) meta=600 nullable=1 is_null=0 */ # at 33817 #170531 17:22:53 server id 153443358 end_log_pos 33848 CRC32 0x630805b4 Xid = 303 COMMIT/*!*/;
Jedes Segment bei xxxxx ist ein Ereignis.
Die Funktion Binlog_sender::send_events ist die Funktion, die Ereignisereignisse in binlog:
sendet Funktionsparameter:end_pos, die Endposition der aktuell gelesenen Binlog-Datei.
log_cache, der Datensatz enthält die Informationen des aktuell übertragenen Protokolls, einschließlich des Speicherorts des übertragenen Binlog-Protokolls und der Binlog-Protokolldatei.
Funktionslogikanalyse:Wenn die aktuell gesendete Position log_pos kleiner als die Endposition end_pos der erhaltenen Datei ist, bedeutet dies, dass noch nicht gesendete Binlog-Protokolle vorhanden sind und die Schleife eingegeben wird.
Durchblutung im Körper:
a. Rufen Sie zuerst die Funktion read_event auf, um ein Ereignisereignis zu erhalten.
b. Log_event_type event_type= (Log_event_type)event_ptr[EVENT_TYPE_OFFSET];
Diese Anweisung wird verwendet, um den Ereignistyp zu ermitteln und dann eine Typprüfung durchzuführen
check_event_type(event_type, log_file, log_pos), wenn die Prüfung nicht bestanden wird, wird 1 direkt an die obere Funktion zurückgegeben.
c. log_pos= my_b_tell(log_cache); Aktualisieren Sie die log_pos-Position, dh bewegen Sie den Cursor, der die Binlog-Position liest, an die aktuelle Position.
d. Rufen Sie dann die Funktion send_packet() auf, um binlog zu senden.
Es stellt sich heraus, dass unabhängig davon, wie viele Binlogs derzeit nicht mit der Slave-Bibliothek synchronisiert sind, die Granularität der Master-Bibliothek, die Binlogs sendet, immer noch Ereignisse einzeln sendet. Vor dem Senden muss der Typ des Ereignisses überprüft werden. Da es in kleinen Paketen gesendet wird, ist der Netzwerkverkehr nicht groß.
Aber wir müssen die Voraussetzungen für dieses Phänomen erklären: In unserer Testumgebung erreichte die Schreib-QPS der Datenbank zu diesem Zeitpunkt mehr als 50.000, sodass viele Ereignisse gesendet werden mussten, selbst wenn es asynchron war. Der Single-Thread-Dump-Thread hatte keine Zeit, das aktuell generierte Ereignisprotokoll zu senden.
Wenn die geschriebenen QPS sehr groß sind, kann es vorkommen, dass es zu spät ist, das Protokoll zu senden.
ZusammenfassungLassen Sie uns nun auf die online aufgetretenen Probleme zurückblicken: „Der Synchronisierungsstatus ändert sich häufig von einem halbsynchronen Zustand in einen asynchronen Zustand und wird dann mit der Zeit wieder in einen halbsynchronen Zustand versetzt.“ ein Analysesystem und führt manchmal Batch-Updates und Batch-Importe durch. Gleichzeitig ist das von der Datenbank festgelegte Binlog-Format der Zeilenmodus. Für eine Transaktion, die mehrere Zeilen aktualisiert, enthält sie viele Ereignisse (eine Zeile ist ein Ereignis), sodass das Senden des Binlogs dieser Transaktion lange dauert und nicht möglich ist innerhalb von 1 Sekunde gesendet werden (das Semi-Sync-Timeout ist auf 1 gesetzt), sodass der Semi-Sync-Status asynchron wird.
Das obige ist der detaillierte Inhalt vonAnalysieren Sie die Nutzungsszenarien der MySQL-Master-Slave-Synchronisation und der Asynchronität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
