Hacker News Reader

I'm curious how you manage upgrades. I am in the process of rolling Keycloak out to production now and the only thing I don't quite grok is how to do zero-downtime upgrades. It seems like the upgrade may make backwards-incompatible changes the DB schema. Do you replicate the entire database for the upgraded environment?

View on HN

When using a K8s cluster with the helm chart [1], it's actually the stateful set that takes care to the update.

When the first replica restart, Keycloak makes the updates to the database itself. Sometimes rolling back to a previous version can break. They do not hold the reverse of the database version [2].

I believe the reason behind the STS (StatefulSet) is so the cache have the time to spread among the replicas as it get upgraded.

[1]: https://github.com/codecentric/helm-charts/tree/master/chart... [2]: https://www.keycloak.org/docs/9.0/upgrading/

We schedule a downtime window during upgrade, but typically see no frontend impact to the core service, SSO for end users. We snapshot the DB for rollback if needed as the migrations are not reversible.

Our actual DB size is pretty small so these are very non-intensive tasks.

May I know how many replicas and CACHE_OWNERS do you have?

Reply on news.ycombinator.com