Как устроены миграции
Схема применяется самим сервисом при старте: schema.sql идемпотентен, версия хранится в schema_meta. Отдельной команды миграции нет — значит, бэкап делается до обновления, а не после. Текущая версия — 9: она добавляет таблицы комментариев.
Внимание
Схема применяется при старте сервиса. Если сделать бэкап после обновления, откатываться будет некуда.
Порядок обновления
cd /srv/remo
systemctl stop remo-sync
sudo -u remo pnpm db:backup
sudo -u remo git pull
sudo -u remo pnpm install --frozen-lockfile
sudo -u remo pnpm build
systemctl start remo-sync
- Остановите сервис: он допишет комнаты в базу.
- Сделайте бэкап и убедитесь, что файл появился в списке.
- Обновите код и зависимости.
- Соберите статику: несобранный фронтенд даст старую вкладку на новом API.
- Запустите сервис: схема применится сама.
Проверка после старта
curl -s http://127.0.0.1:1234/health
journalctl -u remo-sync -n 50 | grep -i 'schema\|error'
healthотвечаетok, версия схемы в логе совпадает с ожидаемой.- Откройте доску и сделайте правку: индикатор должен дойти до сохранено.
- Проверьте один вход и одну ссылку.
- Откройте обсуждение: старые треды на месте, новый комментарий сохраняется.
Ломающие изменения
| Что | Как пережить |
|---|---|
Переименование remiro → remo (2026-10-26) |
переменные REMO_*, cookie remo_session, база remo; все сессии разлогиниваются |
| Смена имени cookie | миграции нет: cookie — это и есть механизм |
Новый обязательный ключ (например, REMO_KEK) |
задайте до старта, иначе функции ответят «locked» |
Если что-то пошло не так
- Не запускайте старую версию поверх новой схемы.
- Остановите сервис и восстановите бэкап.
- Если база обновлена, а код старый — верните код и восстановите базу вместе, а не по отдельности.
Куда дальше
Устранение неполадок — если после старта что-то не работает.