Hi Folks,
We have following setup in production:
Temporal Version 1.0.0
MySQL 5.7 (AWS Aurora)
Not using Cassandra and/or Elastic Search
Temporal Server, Worker and Web are running as ECS Service in AWS.
I am looking for some help in upgrading my temporal setup (production). From whatever I have learnt from the community, my upgrade path looks like:
1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → 1.4.0 → and so on until → 1.9.0
I understand that I need to follow below steps for each environment. Of course, to try it out, I first need a Staging environment:
-
export CURRENT_VERSION=1.0.0
export NEXT_VERSION=1.1.0 -
Start downtime
-
Stop Temporal Server and Web AWS ECS Services that’s running currently.
-
Run the
temporal-sql-tool
using docker image temporalio/admin-tools:${NEXT_VERSION} to upgrade my default and visibility schema. -
Run the temporalio/server:${NEXT_VERSION} and temporalio/web:${NEXT_VERSION} docker images as a service in AWS.
-
Validate if all looks good. (sounds painful as we have a lot of different workflows)
-
Repeat steps 1…6 until you reach 1.9.0 (or the latest at the time of executing)
Questions:
-
Is my upgrade path understanding correct?
-
If the above understanding is correct, this looks like a real painful process. Are there any plans to make this less painful?
-
In one of the threads, I found a suggestion that 1.0.0 can directly be upgraded to 1.3.0. If I read it correctly, then why’s that so? I can see that v1.1.0 does have some schema changes.
-
Our worker and workflow code is all bundled within a single docker image. The docker entrypoint command finds all Temporal workflows and activities and registers them with the worker using java sdk. How does this upgrade impact my worker setup?