Eine detaillierte Analyse und Verarbeitung von MySQL-Alarmen

Vor kurzem hat ein Dienst einen Alarm ausgelöst, der mich unerträglich gemacht hat. Die Alarminformationen lauten wie folgt:

Metrik:mysql.innodb_row_lock_waits Tags:port=4306,service=xxxx diff(#1): 996>900

Die allgemeine Bedeutung ist, dass es einen Datenbanküberwachungsindikator innodb_row_lock_waits gibt, der derzeit den Schwellenwert von 900 überschreitet

Aber das Peinliche ist, dass ich jedes Mal, wenn ich nach einem Alarm die Umgebung überprüfte, nur sehr begrenzte Informationen erhielt. Das langsame Protokoll und das Fehlerprotokoll enthielten nicht genügend Informationen für eine Analyse. Nach einer Weile beruhigte ich mich und analysierte die Ursache des Problems.

Zunächst einmal scheint der Zeitpunkt dieser Alarminformationen einigermaßen regelmäßig zu sein. Ich habe die Alarmzeit der letzten Tage verglichen und festgestellt, dass sie immer noch relativ regelmäßig ist. Welche Aufgaben können also auf Systemebene ausgelöst werden? Ich habe die entsprechenden Aufgabenkonfigurationen nachgeschlagen und verglichen und festgestellt, dass es eine geplante Aufgabe gibt, die einmal pro Minute ausgeführt wird. Aber hier kommt die Frage. Wenn sie einmal pro Minute ausgeführt wird, warum gibt es dann zu einem bestimmten Zeitpunkt große Unterschiede bei den Verarbeitungsergebnissen? Natürlich ist die Erklärung dieses Phänomens nur ein Anfang.

Tatsächlich ist es ziemlich einfach, diesen Punkt zu beweisen. Heute habe ich einen abwartenden Modus eingenommen. Ich habe das allgemeine Protokoll ungefähr zum Zeitpunkt des Alarms geöffnet. Aus der Protokollausgabe geht hervor, dass die Häufigkeit der Vorgänge relativ begrenzt ist.

Bald erhielt ich regelmäßig Alarme und begann, relevante allgemeine Protokolldatensätze zu erfassen. Um 11:18 Uhr können wir beispielsweise das folgende Modell verwenden, um relevante Protokolle abzurufen. Rufen Sie zunächst eine temporäre allgemeine Protokolldatei ab, um verschiedene DML- und Ausführungsvorgänge zu erfassen.

cat general.log|grep -E "einfügen|löschen|aktualisieren|auswählen|ausführen" > general_tmp.log

Nehmen wir 11:18 als Beispiel. Wir können die Zeit vor und nach 1 oder 2 Minuten vergleichen. Die Ergebnisse sind wie folgt:

# weniger general_tmp.log |grep "11:18"|wc -l

400

# weniger general_tmp.log |grep "11:17"|wc -l

666

# weniger general_tmp.log |grep "11:16"|wc -l

15

Etwa eine Minute nach Auslösen des Alarms stellte sich heraus, dass die Zahlen übereinstimmten.

Das Datenvolumen dieser Tabelle beträgt mehr als 2 Millionen und die Tabellenstruktur ist wie folgt:

Tabelle „Task-Queue“ erstellen (
 `AccID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID automatisch inkrementieren',
 `TaskStepID` bigint(20) DEFAULT NULL COMMENT 'Task-Schritt-ID task_step_conf',
 `QOrder` int(11) DEFAULT NULL COMMENT 'Warteschlangensortierung task_step_confi.Step_ID',
 `QState` tinyint(4) DEFAULT '1' COMMENT 'Warteschlangenstatus 1: Wartet auf Ausführung 2: Wird ausgeführt 3: Erfolgreiche Ausführung 4: Ausführung fehlgeschlagen',
 `QExcCount` int(11) DEFAULT '1' COMMENT 'Anzahl der Ausführungen',
 `CrtTime` datetime DEFAULT NULL COMMENT 'Erstellungszeit',
 `ModTime` datetime DEFAULT NULL COMMENT 'Änderungszeitpunkt',
 Primärschlüssel (`AccID`),
 SCHLÜSSEL `idx_taskstepid` (`TaskStepID`),
 SCHLÜSSEL `idx_qstate` (`QState`)
) ENGINE=InnoDB AUTO_INCREMENT=3398341 DEFAULT CHARSET=utf8

Basierend auf der Analyse und dem Vergleich in den Protokollen können wir das SQL grundsätzlich als Update-Operation identifizieren. Der SQL-Ausführungsplan sieht wie folgt aus:

>>erklären Sie update task_queue set QState=1,QExcCount=QExcCount+1,modtime=now(), wobei QState=0 und taskstepid =411\G
*************************** 1. Reihe ***************************
   ID: 1
 Auswahltyp: UPDATE
  Tabelle: task_queue
 Partitionen: NULL
   Typ: index_merge
mögliche Schlüssel: idx_taskstepid,idx_qstate
   Schlüssel: idx_qstate,idx_taskstepid
  Schlüssellänge: 2,9
   Ref: NULL
   Reihen: 11
  gefiltert: 100,00
  Extra: Verwenden von intersect(idx_qstate,idx_taskstepid); Verwenden von where; Verwenden von temporary

In diesem Ausführungsergebnis beträgt key_len 2,9, was von der vorherigen ken_len-Berechnungsregel abweicht. Die Spalte Extra hat einen klaren Hinweis darauf gegeben, dass es sich um einen Intersect-Prozess handelt. Das Besondere ist, dass es sich um einen Prozess auf der sekundären Indexebene handelt. Auf der Optimiererebene gibt es einen zugehörigen Parameter index_merge_intersection.

Wir wissen, dass in MySQL der Primärschlüssel ein erstklassiger Bürger ist und der Sekundärindex schließlich zur Verarbeitung auf die Primärschlüsselebene abgebildet wird. Die Schnittmenge auf Indexebene ist eigentlich ein bisschen wie unsere linke und rechte Hand. Die linke Hand entspricht einigen Datenergebnissen, die einem Stapel Primärschlüssel-IDs zugeordnet sind, und die rechte Hand entspricht einigen Datenergebnissen, die einem anderen Stapel Primärschlüssel-IDs zugeordnet sind. Die Primärschlüssel-ID-Werte der beiden werden durch Schnittmenge berechnet. Ist die Schnittmenge auf Indexebene im aktuellen Szenario also eine gute Idee?

Hier habe ich mir drei vergleichende Analyseszenarien vorgestellt. Zunächst handelt es sich um eine Update-Anweisung. Um die Wiederholbarkeit nachfolgender Tests sicherzustellen, können wir diese in eine Select-Anweisung umwandeln.

Wählen Sie * aus der Task-Warteschlange, wobei QState = 0 und Taskstepid = 411 ist.

Daher basiert unser Vergleichstest auf Abfrageanweisungen zum Vergleich und zur Analyse.

Szenario 1: Der Optimierer behält die standardmäßige index_merge_intersection aktiviert bei und extrahiert Ausführungsdetails basierend auf dem Profil

>erklären Sie select * from task_queue, wobei QState=0 und taskstepid =411\G
*************************** 1. Reihe ***************************
   ID: 1
 select_type: EINFACH
  Tabelle: task_queue
 Partitionen: NULL
   Typ: index_merge
mögliche Schlüssel: idx_qstate,idx_taskstepid
   Schlüssel: idx_qstate,idx_taskstepid
  Schlüssellänge: 2,9
   Ref: NULL
   Reihen: 11
  gefiltert: 100,00
  Extra: Verwenden von intersect(idx_qstate,idx_taskstepid); Verwenden von where
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

Die Profilinformationen lauten:

Szenario 2: Der Optimierer deaktiviert index_merge_intersection und vergleicht auf Basis von Profilen

>Sitzungsoptimierer_schalter='index_merge_intersection=off' festlegen;


>erklären Sie select * from task_queue, wobei QState=0 und taskstepid =411\G
*************************** 1. Reihe ***************************
   ID: 1
 select_type: EINFACH
  Tabelle: task_queue
 Partitionen: NULL
   Typ: ref
mögliche Schlüssel: idx_qstate,idx_taskstepid
   Schlüssel: idx_qstate
  Schlüssellänge: 2
   Verweis: const
   Reihen: 1451
  gefiltert: 0,82
  Extra: Verwenden von „where“
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

Die Profilinformationen lauten:

Szenario 3: Index neu erstellen und vergleichende Analyse durchführen

Gemäß der Geschäftslogik kann die Größe des Ergebnissatzes erheblich reduziert werden, wenn ein zusammengesetzter Index erstellt wird, während der Index idx_qstat weiterhin beibehalten wird, sodass einige Geschäfte weiterhin normal verwendet werden können.

>Tabelle Task_Warteschlange ändern, Schlüssel idx_taskstepid löschen;
>Tabelle task_queue ändern, Schlüssel `idx_taskstepid` hinzufügen (`TaskStepID`,QState);
Erklären Sie „select * from task_queue“, wobei QState=0 und taskstepid =411\G
*************************** 1. Reihe ***************************
      ID: 1
 select_type: EINFACH
    Tabelle: task_queue
  Partitionen: NULL
     Typ: ref
mögliche Schlüssel: idx_qstate,idx_taskstepid
     Schlüssel: idx_taskstepid
   Schlüssellänge: 11
     Verweis: konstant, konstant
     Reihen: 1
   gefiltert: 100,00
    Extra: NULL
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

Die Profilinformationen lauten:

Es ist deutlich zu erkennen, dass der Teil „Senden von Daten“ durch die Indexrekonstruktion um zwei Größenordnungen reduziert wurde.

Der nächste Schritt besteht also darin, weitere Analysen und Überprüfungen mit Begründungen und Beweisen durchzuführen, und der Warteprozess ist nicht länger zögerlich. Ein Tag ist vergangen und es wurden keine weiteren Alarme empfangen, was erneut zeigt, dass wir diese Alarme bei der Arbeit nicht unterschätzen sollten.

Zusammenfassen

Dies ist das Ende dieses Artikels über MySQL-Alarmanalyse und -verarbeitung. Weitere relevante Inhalte zur MySQL-Alarmverarbeitung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!