Analyse und Lösung eines Fehlalarmproblems bei der langsamen MySQL-Protokollüberwachung

Früher wurden manche Alarme aus verschiedenen Gründen nicht ernst genommen. Kürzlich, während des Urlaubs, schloss ich sofort einige mögliche menschliche Faktoren aus und stellte fest, dass der Alarm für das langsame Protokoll der Datenbank etwas seltsam war. Die Hauptsymptome waren, dass der Alarm für das langsame Protokoll nicht zutraf. Nachdem ich die Erinnerung an den Alarm per Instant Messaging erhalten hatte, ging ich nach einer Weile zur Datenbank, um sie zu überprüfen, und stellte fest, dass die Leistung des langsamen Protokolls nicht so schlecht zu sein schien (ich hatte einen Schwellenwert von 60 festgelegt).

Nach mehrmaliger Überprüfung der Logik auf Codeebene wurden keine offensichtlichen Probleme gefunden. Das Problem blieb jedoch nach mehreren Versuchen bestehen. Dies inspirierte mich, es zu korrigieren, und ich beschloss, die Ursache genauer zu untersuchen.

Das Backend verwendet ein ORM-basiertes Modell und die Daten werden in der Tabelle gespeichert, die dem Modell MySQL_slowlog_sql_history entspricht.

Die Codeebene hat die folgende Logik:

MySQL_slowlog_sql_history.objects.filter(Erstellungszeit__gt='2020-01-29 11:00:00',Abfragezeit_pct_95__gt=60)

Die eingegebene Zeit ist dynamisch und der Schwellenwert beträgt 60 Sekunden. Wenn ein Alarm ausgelöst wird, muss erwartungsgemäß ein Problem vorliegen.

Zur weiteren Überprüfung habe ich die Schwellenzeit auf 600 geändert, aber es wurde immer noch ein Fehler gemeldet und es wurden immer noch langsame Abfragen gemeldet, deren Ausführung 7 bis 8 Sekunden dauerte.

Ich habe Debug verwendet, um das SQL von ORM analysieren zu lassen:

AUSWÄHLEN ... `mysql_slowlog_sql_history`.`Erstellungszeit`, `mysql_slowlog_sql_history`.`Memo` 
VON `mysql_slowlog_sql_history` 
WO (`mysql_slowlog_sql_history`.`create_time` > '2020-01-29 11:00:00' UND `mysql_slowlog_sql_history`.`Query_time_pct_95` > '600') LIMIT 21; 
args=(u'2020-01-29 11:00:00', u'600')

Es gibt kein Problem beim Betrachten von SQL.

Ich habe es auf der Clientseite ausgeführt und es hat einwandfrei funktioniert, nur die Ergebnisse, die länger als 600 Sekunden dauerten, wurden herausgefiltert.

Wählen Sie IP-Adresse und Datenbankport aus mysql_slowlog_sql_history 
wobei create_time>'2020-01-29 00:00:00' und Query_time_pct_95 > 600;

Als ich dieses Ergebnis betrachtete, begann ich darüber nachzudenken, was der Grund dafür war.

Ich habe mir die Felddefinitionen des Modells angesehen und begann zu verstehen. Anschließend habe ich es schnell überprüft.

Zur Veranschaulichung habe ich eine Testtabelle test_dummy erstellt.

Tabelle erstellen test_dummy(id int primärer Schlüssel auto_increment,Query_time_pct_95 varchar(100));

Initialisieren Sie einige Daten.

in test_dummy(Query_time_pct_95) Werte einfügen('8.83736'),('7.70056'),('5.09871'),('4.32582');
+----+----------------------+
| ID | Abfragezeit_pct_95 |
+----+----------------------+
| 1 | 8,83736 |
| 4 | 7,70056 |
| 7 | 5,09871 |
| 10 | 4,32582 |
+----+----------------------+
4 Zeilen im Satz (0,00 Sek.)

Nutzen Sie dann die folgenden beiden Aussagen um einen Vergleichstest durchzuführen.

mysql> wähle * aus test_dummy, wobei Query_time_pct_95>600;
Leerer Satz (0,00 Sek.)

mysql> wähle * aus test_dummy, wobei Query_time_pct_95>'600' ist;
+----+----------------------+
| ID | Abfragezeit_pct_95 |
+----+----------------------+
| 1 | 8,837364 |
| 2 | 7,700558 |
+----+----------------------+
2 Zeilen im Satz (0,00 Sek.)

Es ist ersichtlich, dass bei Verwendung eines ganzzahligen Werts kein Ergebnis zurückgegeben wird, bei Verwendung eines Zeichentyps jedoch das Übereinstimmungsergebnis gemäß dem am weitesten links stehenden Übereinstimmungsmuster gefiltert wird, was bedeutet, dass die Verarbeitung von Gleitkommazahlen auf Datenbankebene immer noch sehr unterschiedlich ist.

Die schnelle Lösung für dieses Problem besteht darin, den Datentabellentyp auf Datenbankebene in Float zu ändern. Die Auswirkungen hierdurch auf den Genauigkeitsverlust sind vernachlässigbar.

Nach der erneuten Überprüfung trat das Problem nicht mehr auf.

Oben finden Sie eine detaillierte Analyse und Lösung für ein Problem mit einem Fehlalarm bei der langsamen Protokollüberwachung von MySQL. Weitere Informationen zu Fehlalarmen bei der langsamen Protokollüberwachung von MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!