Lösung für das Problem des MySQL-Datenverzögerungssprungs

Heute haben wir ein weiteres typisches Problem im Zusammenhang mit Datenbankverzögerungssprüngen analysiert. Dabei haben wir auch einige Methoden und Techniken zur Analyse des Problems als Referenz bereitgestellt.

Erstens gibt es beim Hochverfügbarkeitstest eine Reihe von Umgebungserkennungsfehlern. Nach der Untersuchung wird festgestellt, dass die Datenbank eine Verzögerung aufweist. Beim Anmelden bei der Slave-Bibliothek, um den Show-Slave-Status zu überprüfen, wird festgestellt, dass der Wert von Seconds_behind_master ständig springt, das heißt, er springt mit einer Häufigkeit von 0~39~0~39, was die Leute sehr verärgert.

Nachdem ich die relevanten Protokolle der Datenbank überprüft hatte, stellte ich fest, dass keine Protokolldatensätze als Referenz vorhanden waren. Wie kann ich dieses Problem analysieren? Lassen Sie uns es zunächst reproduzieren. Ich habe die Protokolle des Problems dreimal im Rhythmus erfasst, d. h. ich habe die Protokolle des Problems kontinuierlich über „Show Slave Status“ überwacht, die Ausgabeergebnisse von „Show Slave Status“ erfasst und gespeichert. Auf diese Weise können wir die Offsetänderung während des Auftretens eines Problems erhalten. Diese Änderung ist das Problem, das während des Wiedergabevorgangs durch SQLThread verursacht wurde.

In der folgenden Ausgabe habe ich beispielsweise das Relay-Protokoll der Slave-Seite zur Analyse abgefangen. Das entsprechende Feld ist Relay_Log_Pos

Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: xxxx
         Master_Benutzer: dba_repl
         Master_Port: 4306
        Verbindungswiederholung: 60
       Master_Log_File:mysqlbin.000044
     Read_Master_Log_Pos: 386125369
        Relay_Log_Datei: slave-relay-bin.000066
        Relay_Log_Pos: 386125580
    Relay_Master_Log_File: mysqlbin.000044

So erhalten wir schnell die Änderung des Offsets: 385983806, 386062813, 386125580

Dann habe ich mit mysqlbinlog begonnen, die Details dieser Protokollprozesse zu analysieren. Mit dem folgenden Befehl kann ich schnell drei verwandte Tabellen in den ausgegebenen Protokollen abrufen.

# grep INSERT relaylog_xxxx.dump |awk '{print $3 " " $4}'|sed ‚s/INTO//g‘|sort|uniq
 act_action_exec_info
 act_join_desc
 dic_subsidy_marketing_querylog_202008

Ich habe die Datenoperationen jeder Tabelle nach und nach analysiert, aber die erhaltenen Informationen waren immer noch begrenzt. Ich habe weitere Analysen durchgeführt. Analysieren wir beispielsweise das Transaktionsvolumen im gesamten Protokoll:

# mysqlbinlog slave-relay-bin.000066 | grep "GTID$(printf '\t')last_committed" -B 1 \
> | grep -E '^# bei' | awk '{print $3}' \
> | awk 'NR==1 {tmp=$1} NR>1 {print ($1-tmp);tmp=$1}' \
> | sortieren -n -r | Kopf -n 100
mysqlbinlog: [Warnung] unbekannte Variable „loose-default-character-set=utf8“
5278
5268
5268
5268
5253
5253
5253
5253
5253

Es ist ersichtlich, dass es ungefähr 5 KB sind, was relativ groß ist. Woher kommen diese zusätzlichen Informationen? Ich habe general_log in der Hauptdatenbank aktiviert, damit ich detailliertere Betriebsprotokolle erhalten kann.

Weitere Analysen ergaben, dass das gesamte Unternehmen die explizite Transaktionsmethode verwendete: SET autocommit=0. Die gesamte Transaktion enthielt mehrere große SQL-Anweisungen, die viele Operationsprotokolldetails speicherten. Darüber hinaus wurden während der Transaktionsoperation mehrere select count(1) from xxx-Operationen basierend auf dem Mybatis-Framework aufgerufen.

Nach der Kommunikation mit dem Unternehmen konnten die oben genannten Probleme grundsätzlich geklärt werden.

Oben finden Sie eine detaillierte Lösung für das Problem der MySQL-Datenverzögerung und des MySQL-Datensprungs. Weitere Informationen zu MySQL-Datenverzögerung und -sprung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!