Къде всъщност живее схемата на базата данни

Всичко, което прави тази услуга, е под контрол на версиите. Поне кодът. Базата данни, на която работи, се състои от 32 таблици, а 15 от тях нямат дефиниция никъде в хранилището — нито CREATE TABLE, нито файл със схема, нищо. Един дъмп възстановява всичките 32 с непокътната структура; онова, което хранилището не съдържа, е второ, независимо копие на тази структура.

Тези стойности идват от сравнение на работещата база данни с 736 файла и 5 671 710 знака от хранилището. Те не са оценка.

Как изчезва половин схема

Това не е небрежност и точно затова си струва да се запише. Всяка отделна стъпка беше разумна.

Таблиците, създадени преди да съществува сегашният код, никога не са били записани, защото тогава просто ги имаше. Таблиците, добавени оттогава, дойдоха чрез скриптове за миграция и тези скриптове са в хранилището — оттам идват 17-те дефиниции. Колоните, добавени по-късно, бяха добавени с едноредова команда ALTER TABLE директно в командния ред, защото да я напишеш там беше по-бързо, отколкото да пишеш скрипт за промяна, която отнема секунда.

Индексите са най-лошият случай. Индекс се добавя, когато нещо е бавно, в момента, в който е бавно, и той веднага решава проблема. Не остава никаква следа, нищо за преглед, нищо, което да се провали, ако бъде забравено. Единадесет от тридесет и двата вторични индекса тук съществуват точно поради тази причина и не са записани никъде.

Таблицата, която съдържа самите броячи, 166 438 реда, е сред петнадесетте без дефиниция в хранилището.

Какво всъщност се чупи

Не много — до един конкретен момент: когато базата данни се възстановява от дъмп.

Дъмпът носи структурата, така че прякото възстановяване е наред. Опасността е във всеки път, при който таблицата се изгражда наново, вместо да се възстанови — преместване на друга машина, импорт на избрани таблици, пресъздаване на таблица от скрипт. Данните се връщат, а индексите тихо не. Нищо не се проваля. Заявките връщат правилните отговори. Просто отнемат повече време и причината е невидима, защото единственият запис за това какъв е бил индексът е машината, която вече го няма.

Това е видът грешка, който си струва да се назове: липсващият индекс не води до грешка, а до по-бавен верен отговор. За това няма тест, защото тестовете минават.

Какво правим междувременно

Днес схемата не е в хранилището и това е точното описание на положението. Онова, което е въведено, е по-тясно от пълно решение и покрива случая, който наистина струва нещо:

Дъмп преди всяка разрушителна операция, съхраняван извън основната уеб директория. Възстановяване, което наистина е извършено поне веднъж, а не само предполагано. И кратък списък, проверяван след всяко възстановяване, на индексите, за които се знае, че съществуват само в работещата база данни — защото машината може да бъде попитана какви индекси има, а отговорът може да се сравни с последния път, когато е била попитана.

Общият случай важи не само за бази данни. Ако част от една система съществува само в работещата система, няма второ нейно копие. Въпросът, който си струва да се зададе за всяка част от инфраструктурата, не е дали има резервно копие, а какво не би могло да се изгради отново от хранилището, ако машината изчезне. Тук отговорът е петнадесет таблици и единадесет индекса, установяването му отне един следобед и той е списък, а не неизвестно.

Актуализация: септември 2026 г.

Пет дни след публикуването на тази статия работната директория беше записана в хранилището: 26 файла и 4 058 реда, сред тях единадесет скрипта за миграция, написани между 28 август и 1 септември, които дотогава съществуваха само на работещата машина. Това беше лесната половина — код, който е бил написан, но никога не е бил записан.

Измерването беше повторено на 1 септември 2026 г. по същия начин: работещата база данни срещу всичко, което git проследява.

Таблици	46	30 с CREATE TABLE в хранилището, 16 без
Вторични индекси	43	32 създадени от код в хранилището, 11 само в работещата база данни
Скриптове за миграция	109	под контрол на версиите

Числото, което има значение, не помръдна. На 27 август единадесет вторични индекса съществуваха единствено в работещата база данни. На 1 септември те все още са единадесет. Междувременно бяха добавени още единадесет индекса и всеки от тях дойде със скрипт за миграция: навикът се промени, дългът — не.

Единадесетте са в пет таблици — броячите, езиците, препращащите сайтове, списъка с изключения и дневника на събитията. И петте са по-стари от сегашния код и точно затова за тях никога нищо не е било записано. Да се напише файл сега би означавало да се реконструира от работещ сървър онова, което е било въведено в командния ред преди години.

Така че позицията от август остава в сила. Схемата все още не е в хранилището и възстановяване, което изгражда таблица наново, вместо да я възстанови, все още би загубило единадесет индекса без нито дума. Промяната е по-тясна: всичко, добавено оттогава, е оставило след себе си файл.