Files
admin/.tasks/2026-05-21-mssql-minio-migration-to-vds.md

7.9 KiB
Raw Blame History

mssql-minio-migration-to-vds

Goal

Перенести MSSQL контейнер + MinIO с ../entities/windows-recovery-host на ../entities/vds-kzntsv чтобы:

  1. Снять SPOF с windows-recovery-host (домашняя машина) для критических CMS-данных
  2. Achieve target RPO 1ч через подключение к существующему vds-backup-rsync-kreknin pipeline (tx log backups каждые 60 мин в существующий rsync→kreknin)
  3. Унифицировать DB park — MSSQL рядом с pg/maria/mongo/redis в /opt/stacks/databases/
  4. Подготовить ground для будущего IIS migration на managed Windows hosting (windows-hosting-vendor-research → impl-таска позже)

Это Фаза 2 roadmap'а CMS backup'ов. После завершения — списать cms-stopgap-backup-daily pipeline.

Key files / refs

  • Source MSSQL: docker container на windows-host, image mcr.microsoft.com/mssql/server:2019-latest, volume mssql_mssql_data, 5 production DBs (MoreThenCms, Stayer*, stostayer, TireService) — см. ../.wiki/concepts/recovery-architecture-snapshot §"Запущенные docker контейнеры"
  • Source MinIO: docker container на windows-host, image minio/minio:RELEASE.2020-07-13T18-09-56Z, volume bind ./data
  • Target MSSQL: /opt/stacks/databases/mssql/{data,certs,docker-compose.yml} на VDS — паттерн как у existing DBs, см. ../.wiki/entities/vds-kzntsv
  • Target MinIO: /opt/stacks/storage/minio/ (новый stack на VDS)
  • CMS connection strings (изменить):
    • MSSQL: Data Source=localhost,1433Data Source=mssql.vds.kzntsv.site,1433 (через traefik raw-TCP passthrough)
    • MinIO: endpoint localhost:9000minio.vds.kzntsv.site:9000
  • Existing backup pipeline для расширения: /opt/stacks/backup/scripts/run.sh на VDS (см. ../.tasks/vds-backup-rsync-kreknin🟢 done)
  • TLS pattern: self-signed certs через traefik raw-TCP passthrough, см. ../.wiki/concepts/db-tls-self-signed-via-traefik-raw-tcp + ../.wiki/concepts/traefik-tcp-passthrough-vs-starttls

Acceptance

  1. MSSQL container на VDS запущен, 5 prod DBs восстановлены (cold cutover: stop CMS app pool → backup MSSQL host-side → restore on VDS → repoint connection strings → start CMS app pool)
  2. MinIO на VDS запущен, content мигрирован (mc mirror от source к target)
  3. CMS connection strings updated в web.config (или эквиваленте), sites функциональны (smoke test 8 hosts: 200 OK + asset loading + admin/assets/getList — это известный hot-path)
  4. Pre-cutover benchmark выполнен — admin assets UI / search / catalog response times измерены до и после миграции, latency degradation <2x (target). Если worse — discussed с user перед commit'ом cutover (возможно retreat или оптимизация query patterns)
  5. Backup pipeline на VDS расширен: добавлены в run.sh:
    • mssql_dump_full ежедневно (как pg_dumpall pattern)
    • mssql_tx_log_backup ежечасно (новая нога — BACKUP LOG через docker exec mssql sqlcmd ...)
    • minio_mirror ежедневно (mc mirror либо rsync data dir)
  6. ntfy push verified для расширенного pipeline (включает MSSQL+MinIO size/duration)
  7. cms-stopgap-backup-daily cron на windows-host отключён после первого успешного VDS-pipeline run (atomic swap, не parallel-running, чтобы не оставлять confusing-state двух pipelines)
  8. Documented в ../.wiki/concepts/mssql-minio-on-vds (создать) с:
    • architecture diagram (IIS → traefik VDS → MSSQL/MinIO containers)
    • rollback recipe (если cutover failed — vernut' connection strings + reactivate stop-gap pipeline)
    • migration runbook (что делал, в каком порядке)

Decisions log

  • 2026-05-21: создана из roadmap-workshop'а (../.wiki/concepts/future-resilient-architecture-goals §Фаза 2). User-confirmed: MSSQL+MinIO мигрируют на VDS (vs alternative — оставить на managed Windows host рядом с IIS). Reasons:
    • DB park уже на VDS, unified backup operation
    • Linux containers стабильнее и дешевле в обслуживании чем Windows-side MSSQL
    • VDS уже работает, не плодим хосты
    • Подготавливает ground для IIS-migration (после неё IIS host сможет быть thin — только web layer)

Open questions

  • MSSQL Express vs Developer vs Standard на Linux container — TBD по licensing. Production size MoreThenCms — проверить, помещается ли в Express limits (10GB per DB, 1410MB RAM). Если нет — Developer (бесплатно для non-prod, формально не для прод) или Standard (). Альтернатива — migration MSSQL → PostgreSQL (упомянуто в roadmap как long-term option) — отдельный major project.
  • MinIO migration approachmc mirror overnight (zero-downtime если кратко) или maintenance window (cleaner)?
  • Cutover timing — нужен ли downtime window клиентам, или можно zero-downtime через MSSQL log shipping (source → target replay, потом final switch)?
  • CMS connection-string change — где живёт config (web.config? отдельный appsettings? hardcoded в DLL?). Если hardcoded — нужен DLL rebuild который требует build env, отложен в ../.wiki/concepts/cms-admin-assets-root-folder-seed §"Долгосрочный TODO"
  • Hermes service на windows-host? (упомянут как defer в ../.wiki/entities/vds-kzntsv Open issues) — проверить не зависит ли от MSSQL/MinIO, если да — мигрируется заодно или ломается

Risks

  • WAN latency IIS→MSSQL: теперь 10-30ms vs localhost. Большинство CMS-операций batchey, не latency-sensitive. Pre-cutover benchmark обязателен для hot-paths (admin assets UI / search / каталоги) — flag если round-trip-heavy. См. acceptance item 4.
  • MSSQL Linux compat: некоторые edge-case T-SQL features differ (CLR, FileStream, full-text search). Smoke test обязателен — EXEC sp_helpdb + проверить что нет CLR assemblies / FileStream filegroups в prod DBs.
  • TLS overhead: rawTCP through traefik adds minor latency vs direct connection. Negligible (<1ms) но проверить.
  • Cutover rollback: если CMS не работает после repoint — quick revert connection strings возможен только если MSSQL на windows-host оставлен running parallel ~24-48ч после cutover. План: stop receiving writes на windows-MSSQL (read-only), но container running, для emergency rollback. Через 48ч uptime — stop windows-MSSQL container, через неделю — docker rm + docker volume rm.

Notes

Эта таска — major (1-2 недели работы realistic). Можно разбить на sub-phases при impl: (a) MSSQL container deploy + restore from backup, (b) connection string change + smoke, (c) MinIO migration, (d) backup pipeline integration. Каждая sub-phase = свой commit с atomic revert recipe.

Atomic revert (full): revert CMS web.config → windows-host MSSQL/MinIO; восстановить cms-stopgap-backup-daily cron; на VDS — docker compose down -v для mssql + minio stacks; удалить новые ноги из run.sh.