База данных
Заметки в Notarium — это файлы, а поисковый индекс и граф из них пересобираются. Но часть состояния из файлов не выводится: её хранит отдельная служебная (meta) БД. По умолчанию это SQLite-файл под корнем данных — <DATA_DIR>/meta.db; переменная META_DB_URL нужна только чтобы указать внешний Postgres.
Что хранит служебная БД
| Данные | Почему не из файлов |
|---|---|
| Идентификаторы заметок | Реестр notarium-id ↔ путь: переживает move/rename. |
| История версий | Журнал ревизий (снимки версий, откуда взялась правка) ведёт само приложение, а не git. |
| Пользователи и доступы | Учётки, роли, членство, токены. |
| История переименований | Алиасы старых слагов пространств и проектов — чтобы прежние адреса продолжали резолвиться. |
Восстановить это из одних .md-файлов нельзя — потому служебную БД обязательно включают в бэкап. Реестр пространств в этой БД тоже есть, но он производный: идентичность пространства живёт в файле-маркере в его корне и восстанавливается сканом (File-first). Производные индексы движка (<DATA_DIR>/engine) при потере просто пересобираются из файлов при следующем запуске.
О самих версиях и их происхождении — Концепции: версии.
Схема и миграции
Схему служебной БД ведёт само приложение: миграции применяются при старте, отдельной команды для них нет. Внутри БД лежит реестр применённых миграций — по нему сборка понимает, с чем имеет дело.
Стартом принимаются ровно три состояния:
- пустая БД — разворачивается базовая схема, запись в реестр делается той же транзакцией;
- БД, чей реестр — точный префикс ожидаемого — сверяются версии, имена и контрольные суммы, затем применяется недостающий хвост;
- непустая БД без реестра — старт падает закрыто, до любых изменений схемы и запросов приложения.
Последнее — намеренно. Сборка не угадывает версию чужой БД и не проставляет отметку сама: это молча испортило бы данные. Если у вас на руках такая база (например, инстанс старее базовой схемы), сначала обновите и проверьте его штатной процедурой его версии, и только потом переносите через эту границу.
Механизм отката данных в Notarium — проверенный архив, а не обратные SQL-миграции. Снимайте и проверяйте бэкап до обновления: Бэкап и восстановление.
SQLite (по умолчанию)
Без настройки: по умолчанию служебная БД — это sqlite:<DATA_DIR>/meta.db, то есть файл на томе /data. Отдельного сервиса не нужно, задавать ничего не надо. Этого достаточно для персонального инстанса и небольшой команды на одном контейнере.
Postgres (для команды и общего состояния)
Чтобы вынести состояние за пределы контейнера — ради общего хранилища, отказоустойчивости или обслуживания — укажите Postgres:
# .env
META_DB_URL=postgres://user:pass@db:5432/notarium
Postgres нужен, если состояние должно жить независимо от жизненного цикла контейнера. При этом сами заметки по-прежнему остаются файлами под <DATA_DIR>/spaces — в БД уходит только невыводимое из них.
password опирается на служебную БДВ режиме AUTH_MODE=password служебная БД нужна для учёток и токенов — и она уже есть по умолчанию (SQLite под корнем данных). Отдельно задавать META_DB_URL не требуется; его указывают только ради переезда на Postgres. Без служебной БД работает лишь AUTH_MODE=none. См. Аутентификация.
Вынос состояния в Postgres сам по себе не включает горизонтальное масштабирование: Notarium работает как один инстанс, несколько инстансов за балансировщиком не поддерживаются (см. Продакшн).