Связаться с поддержкой

Мы отвечаем по электронной почте, обычно в течение двух дней.

Для защиты от злоупотреблений Google reCAPTCHA проверяет эту отправку; при этом данные передаются в Google. Скрипт загружается только при открытии этой формы.

← Все записи

Схема, которая живёт только в работающей базе

Всё, что делает эта служба, лежит в системе контроля версий. Код — во всяком случае. База, на которой он работает, — это 32 таблицы, и у 15 из них нигде в репозитории нет описания: ни CREATE TABLE, ни файла схемы, ничего. Если бы сервер пропал, код вернулся бы в точности, а форму данных пришлось бы восстанавливать по тому, что код случайно спрашивает.

17 таблиц описано 15 не описано нигде 21 индекс создаёт код 11 только в базе 32 таблицы, 32 вторичных индекса, 0 файлов схемы

Эти цифры получены сравнением работающей базы с 736 файлами и 5 671 710 знаками репозитория. Это не оценка.

Как теряется половина схемы

Это не небрежность, и именно поэтому стоит записать. Каждый отдельный шаг был разумным.

Таблицы, созданные до нынешнего кода, никогда не были записаны, потому что тогда они просто были. Таблицы, добавленные с тех пор, пришли через миграционные сценарии, и они лежат в репозитории — отсюда те 17 описаний. Столбцы, добавленные позже, приходили однострочным ALTER TABLE, набранным в командной строке, потому что набрать было быстрее, чем писать сценарий ради изменения длиной в секунду.

Хуже всего с индексами. Индекс добавляют, когда что-то медленно, в тот момент, когда медленно, и он чинит это сразу. После него не остаётся ничего: нечего просматривать, нечему упасть, если забыть. Одиннадцать из тридцати двух здешних вторичных индексов существуют ровно поэтому и нигде не записаны.

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

Что на самом деле ломается

Немногое — до одного определённого момента: когда базу восстанавливают из выгрузки.

Выгрузка несёт структуру с собой, так что прямое восстановление проходит нормально. Опасен любой путь, который создаёт таблицу заново вместо восстановления: переезд на другую машину, перенос отдельных таблиц, воссоздание из сценария. Данные возвращаются, а индексы молча нет. Ничего не падает. Запросы возвращают правильные ответы. Они просто идут дольше, и причина невидима, потому что единственная запись о том, чем был индекс, лежит на машине, у которой его больше нет.

Вот тот сбой, который стоит назвать: пропавший индекс не даёт ошибки, он даёт более медленный правильный ответ. Проверки на это нет, потому что тесты проходят.

Что мы делаем пока

Честная позиция такова: это не исправлено. Схемы в репозитории сегодня нет. То, что есть, меньше исправления и лучше, чем ничего:

Выгрузка перед всем разрушительным, хранимая вне веб-каталога. Восстановление, которое действительно однажды проделали, а не предположили. И короткий список, проверяемый после каждого восстановления, тех индексов, о которых известно, что они есть только в работающей базе — ведь машину можно спросить, какие у неё индексы, и сравнить ответ с прошлым разом.

Общая формулировка касается не только баз данных. Если часть системы есть только в работающей системе, у вас не копия, у вас заложник. Вопрос, который стоит задать о любом куске инфраструктуры, звучит не «есть ли резервная копия», а «если эта машина исчезнет, что нельзя будет собрать заново из репозитория». Здесь ответ — пятнадцать таблиц и одиннадцать индексов, и на выяснение ушёл день.

Реклама