We want to use a hosted MySQL. According to GitHub - temporalio/helm-charts: Temporal Helm charts we need to initialize the db schema manually/separately.
Why is that an extra step when having the helm chart create the db it can run this automatically?
Or did I completely mis-understand the steps?
why not managing the DB schema manually? the changes to DB schema happens rarely. plus any changes to DB schema should be considered a higher risk operation and should be monitored closely.
Thank you for the reply.
We understand that changes happens rarely, so an update will have human involved. But automation is a MUST for many many situations, like disaster recovery, setup separate infra for separated customers, audit, etc.
We love repeatability and deterministic. That’s one big reason we want to use Temporal. So back to the questions:
If we should not use helm for production, what should we use? How do you suggest we deploy to K8s?
When the service start, with proper db connections setup, can’t it automatically see that either the tables and schemas are already there and the version matches, or nothing is there and I need to do the initial setup?
A to 1: you can based the output of helm and come up your own k8s template.
A to 2: if there are more then 1 host being deployed, should additional logic be there guaranteeing only one schema update is in progress? there are other cans of warms involved.
Make sure there is only one host doing the schema initialization (or update) should not be a hard problem especially when the db you got has transactions. I’ve used many many products/services sit on top of database that need to initialize/bootstrap schema. I don’t recall them need a manual step first.