Нужно выкатывать ломающее изменение схемы БД для микросервиса в Kubernetes без простоя. Деплой — RollingUpdate, трафик критичный. Как спланировать и выполнить релиз, чтобы избежать даунтайма и иметь безопасный откат?
Применить стратегию expand → migrate → contract:
Expand: сначала деплой приложения, совместимого со старой и новой схемой (feature-flag, двусторонняя совместимость чтения/записи).
Migrate: выполнить онлайн-миграцию как Kubernetes Job (идемпотентная, с контролем lock timeout), порционно/батчами, с мониторингом SLO. Для MySQL — gh-ost/pt-online-schema-change, для Postgres — pg_repack.
Contract: после валидации и прогрева трафика — удалить устаревшие поля/индексы.
Параллельно — canary/blue-green, readinessProbe по версии схемы, бэкап/снэпшот, план отката (down-миграции/флаг отката), и блокировка релиза при нарушении error budget.
Библиотека собеса по DevOps
Post #791
710