Wir hatten eine Flyway-Migration als Fehler in unserem jenkins-Job neulich kommen. Als wir uns die DB angesehen haben, haben wir festgestellt, dass das Skript angewendet wurde, aber in der Tabelle "schema_version" für das Skript wurde kein Eintrag erstellt. Wir wissen, dass die Anwendung dieses Skripts sehr lange dauerte (indem eine Tabelle mit ungefähr 70 Millionen Zeilen geändert wurde), und wir verwendeten eine SQL-Syntax, die die Änderung zumindest nicht blockierte (ALGORITHM = INPLACE auf mysql). Als das Skript jedoch fertig war, kehrte flyway mit einem Fehler zu jenkins zurück und führte nach diesem langen Skript keine Skripts mehr aus.Flyway false failure
Wir laufen über das Gradle-Plugin (Version 3.2.1) und benutzen ansible, um die Aufgabe zu starten. Jenkins ruft ansible an, der gruft ruft, der flyway anruft. Ich bin mir nicht sicher, ob dies durch eine falsche oder falsche Flugzeit verursacht wurde. Wir möchten, dass dies in der Produktion nicht wieder passiert.
Unsere Problemumgehung bestand darin, den Eintrag manuell in schema_version zu speichern, damit das Skript nicht erneut ausgeführt werden konnte. Führen Sie die Migration dann erneut aus, damit die Skripts ausgeführt werden konnten.
Wir schauten uns die db an und es gab einen zufälligen Verbindungs-Spike um die gleiche Zeit, vielleicht kam es zu einem Verbindungslimit, aber ich dachte, die Verbindung wäre bereits offen, wenn es das Skript ausführen würde.
Die hygienisiert Ausgabe von jenkins ist wie folgt:
TASK: [flyway | run flywayMigrate] ********************************************
<db.server> REMOTE_MODULE command gradle -b /opt/product/rc/flyway-17.5.32.37534.d2bac4a/extracted/flyway.gradle flywayMigrate
failed: [db.server] => {"failed": true, "parsed": false}
invalid output was: SUDO-SUCCESS-plqsdlxwlfkdsujlxdafldpasvtllis
Wird MySQL mit einer Art Protokollierung ausgeführt? Die wahrscheinlichste Art wäre binlog für die Replikation/inkrementelle Sicherung. Wenn ja, überprüfen Sie die MySQL-Protokolle (z. B. für binlog verwenden Sie das Dienstprogramm "mysqlbinlog", um es zu dumpen) und versuchen Sie, eine Vorstellung davon zu bekommen, was MySQL zu dieser Zeit tat. Beachten Sie, dass binlog nur Aktualisierungen protokolliert, die tatsächlich etwas geändert haben. Daher erhalten Sie nicht das vollständige Bild, können jedoch einige Hinweise geben. –
danke für den Tipp. Da dies nur auf unserem Produktionsserver passiert ist, habe ich keinen Zugriff darauf (aus Sicherheitsgründen gesperrt). Das Skript ist in unserer CERT-Umgebung, auf die ich Zugriff habe, erfolgreich. Das ist also nicht gut. Ich kann jemanden dazu bringen, sich in der Produktion anzumelden, aber das ist überraschend herausfordernd, haha. – gnomed