Операции, выполняемые при инициализации Celesta

1. Общая последовательность операций

Инициализация Celesta происходит в несколько этапов, о чём сообщает вывод в лог:

Celesta ver. 7.2.4
Celesta pre-initialization: system settings reading...
done.
Celesta initialization: score parsing...
done.
Celesta initialization: database upgrade...
done.
  1. В процессе чтения системных настроек Celesta анализирует состояние параметров конфигурации, проверяет тот факт, что все обязательные параметры заданы, и что все параметры заданы корректно. При обнаружении ошибки в настройках запуск системы не будет продолжен.

  2. При разборе метаданных происходит чтение всех доступных файлов *.sql, их синтаксический анализ и построение внутренней объектной модели базы данных (метаданных). Система собирает из скриптов CelestaSQL информацию о гранулах, таблицах и полях. Вычисляются их контрольные суммы, находятся версии. При возникновении ошибок синтаксиса или несогласованности CelestaSQL-скриптов на данном этапе запуск системы прерывается.

  3. Процедура авто-миграции базы данных.

2. Автоматическая миграция базы данных

На этом этапе сервер приложений соединяется с базой данных и проверяет наличие в ней системной таблицы celesta.grains. Если таблица не найдена, она автоматически создаётся (CREATE-командой), однако это происходит лишь в следующих случаях: 1) база данных совершенно пустая 2) в параметрах конфигурации выставлено свойство force.dbinitialize (это защищает от «порчи» существующих, непустых баз данных при ошибочном присоединении к ним системы Celesta). Если в процессе проверки наличия/создания таблицы celesta.grains возникла ошибка, то генерируется фатальная ошибка и система не запускается.

2.1. Определение необходимости миграции гранулы (схемы)

Далее идёт цикл по всем доступным в метаданных гранулам (схемам) и всем доступным в celesta.grains гранулам. (При этом из процесса миграции исключаются гранулы, объявленные с опцией WITH NO AUTOUPDATE в CelestaSQL-скрипте).

  1. Если гранула есть в метаданных, но её нет в таблице celesta.grains — выполняется апдейт по CelestaSQL-скрипту (т. е. предполагается, что соответствующие таблицы в базе данных могут и присутствовать).

  2. Если гранула есть в celesta.grains, но её нет в метаданных — ничего не происходит. Автоматически гранулы из базы данных не удаляются, т. к. их таблицы могут содержать важную информацию. Просто для этих таблиц не будут сформированы классы доступа к данным.

  3. Если гранула есть и там, и там: сервер приложений находит в таблице celesta.grains запись про состояние, версию и контрольную сумму метаданных, которые были «накатаны» на базу данных при последнем запуске и сравнивает с версией метаданных, которыми сервер располагает. Записанное в таблице celesta.grains состояние может принимать одно из этих значений:

    • recover (3) — действуем аналогично отсутствию записи (см. п. 1).

    • lock (4) — структура не обновляется, переходим к следующей грануле.

    • upgrading (1) или error (2) — останов процесса с ошибкой “Cannot proceed with database upgrade: there are grains not in 'ready', 'recover' or 'lock' state”.

    • ready (0) — продолжение процесса.

      1. Если версия и контрольная сумма совпадают — ничего не происходит. Система полагает, что структура соответствующей гранулы базы данных уже соответствует CelestaSQL-скрипту и экономит время на анализе существующей структуры.

      2. Если версия различна: если версия изменилась в сторону увеличения — апгрейд вне зависимости от контрольной суммы. Если в сторону уменьшения либо если версия несовместима (см. описание логики работы с version tags) — вне зависимости от контрольной суммы останов с ошибкой: “Grain '…​' version '…​' is lower than / is inconsistent with database grain version '…​'. Will not proceed with auto-upgrade.”

      3. Если версия совпадает, а контрольная сумма различна – апгрейд.

2.2. Процедура миграции гранулы (схемы).

Если на основании описанного выше алгоритма система решает, что апгрейд гранулы необходим — начинается процесс синхронизации структуры БД и структуры данных, описанных в CelestaSQL-скрипте. Все недостающие объекты — таблицы, поля, ключи, индексы, представления и т. п. — создаются. Объекты, требующие модификации (например, типы данных полей, состав полей в индексе, SQL-запросы представлений) — модифицируются. При этом система прикладывает максимальные усилия для того, чтобы модификация прошла автоматически и без ошибок. Если в ряде случаев этого можно достичь всегда (например, в случае замены SQL-запроса в представлении на другой корректный, или при изменении состава полей в индексе), иногда без ручного вмешательства в процесс и выполнения ad hoc скрипта автоматически мигрировать схему невозможно (см. на эту тему пост об идемпотентных миграциях). Ошибки на данном этапе приводят к переводу гранулы в состояние error и требуют ручного вмешательства администратора базы данных.

Если объект был удалён из CelestaSQL-скрипта, во избежание потери данных автоматический мигратор удаляет из БД лишь те объекты, которые не содержат данных (т. е. таблицы и поля автоматически не удаляются и могут быть удалены вручную в ad hoc-миграционном скрипте, с удалённых полей удаляются внешние ключи).

3. Полное или частичное отключение автоматической миграции

В Celesta имеется несколько способов отключить процесс автомиграции: