Kontakt z pomocą

Odpowiadamy e-mailem, zwykle w ciągu dwóch dni.

Google reCAPTCHA sprawdza to zgłoszenie pod kątem nadużyć; dane trafiają do Google. Skrypt ładuje się dopiero po otwarciu formularza.

← Wszystkie wpisy

Schemat, który żyje tylko w działającej bazie

Wszystko, co robi ta usługa, jest w kontroli wersji. Kod owszem. Baza, na której działa, to 32 tabele, a 15 z nich nie ma nigdzie w repozytorium definicji — żadnego CREATE TABLE, żadnego pliku schematu, niczego. Gdyby serwer przepadł, kod wróciłby dokładnie, a kształt danych trzeba by odtworzyć z tego, o co kod przypadkiem pyta.

17 tabel zdefiniowanych 15 nigdzie nie zdefiniowanych 21 indeksów tworzy kod 11 tylko w bazie 32 tabele, 32 indeksy wtórne, 0 plików schematu

Te liczby pochodzą z porównania działającej bazy z 736 plikami i 5 671 710 znakami repozytorium. Nie są szacunkiem.

Jak ginie połowa schematu

To nie jest niechlujstwo i właśnie dlatego warto to zapisać. Każdy pojedynczy krok był rozsądny.

Tabele powstałe przed obecnym kodem nigdy nie zostały spisane, bo wtedy po prostu były. Tabele dodane później przyszły przez skrypty migracyjne, a te w repozytorium — stąd owe 17 definicji. Kolumny dokładane jeszcze później przychodziły jednolinijkowym ALTER TABLE wpisanym w wierszu poleceń, bo wpisanie było szybsze niż napisanie skryptu do zmiany trwającej sekundę.

Najgorzej jest z indeksami. Indeks zakłada się, gdy coś jest wolne, w chwili gdy jest wolne, i naprawia to natychmiast. Nie zostaje po tym żaden wytwór, nic do przejrzenia, nic, co zawiedzie, jeśli się zapomni. Jedenaście z trzydziestu dwóch tutejszych indeksów wtórnych istnieje dokładnie z tego powodu i nigdzie nie jest zapisane.

Tabela, w której siedzą same liczniki, 166 438 wierszy, należy do tych piętnastu bez definicji w repozytorium.

Co naprawdę się psuje

Niewiele, aż do jednej określonej chwili: gdy bazę odtwarza się ze zrzutu.

Zrzut niesie strukturę, więc proste odtworzenie jest w porządku. Niebezpieczna jest każda droga, która buduje tabelę na nowo zamiast ją odtwarzać — przeprowadzka na inną maszynę, wgranie wybranych tabel, odtworzenie ze skryptu. Dane wracają, indeksy po cichu nie. Nic nie zawodzi. Zapytania zwracają właściwe odpowiedzi. Po prostu trwają dłużej, a przyczyna jest niewidoczna, bo jedyny zapis tego, czym był indeks, leży na maszynie, która już go nie ma.

To ten błąd, który warto nazwać: brakujący indeks nie daje błędu, daje wolniejszą poprawną odpowiedź. Nie ma na to testu, bo testy przechodzą.

Co robimy w międzyczasie

Uczciwe stanowisko jest takie, że to nie jest naprawione. Schematu dziś w repozytorium nie ma. To, co jest, jest mniejsze niż naprawa i lepsze niż nic:

Zrzut przed każdą rzeczą niszczącą, trzymany poza katalogiem sieciowym. Odtworzenie, które naprawdę raz przeprowadzono, a nie założono. I krótka lista, sprawdzana po każdym odtworzeniu, indeksów, o których wiadomo, że istnieją tylko w działającej bazie — bo maszynę można zapytać, jakie ma indeksy, a odpowiedź porównać z poprzednim razem.

Wersja ogólna dotyczy więcej niż baz danych. Jeśli część systemu jest tylko w działającym systemie, nie masz jej kopii, masz zakładnika. Pytanie warte zadania o każdy kawałek infrastruktury nie brzmi „czy jest kopia zapasowa", tylko „czego, gdyby ta maszyna zniknęła, nie dałoby się odbudować z repozytorium". Tutaj odpowiedź to piętnaście tabel i jedenaście indeksów, a ustalenie tego zajęło popołudnie.

Reklama