Upgrading Temporal service with helm

Community Support
,
1

Hello,
this is a bit of a continuation of this thread which ended with “TBD”.

I’d like to describe our current deployment and ask if we pieced the documentation together in a working upgrade solution, with some additional questions.

We have workflows implemented using java sdk version 1.0.0.
We have temporal service version 1.0.0 deployed from helm charts, the store is MySQL.

  1. We upgrade our java sdk to 1.5.1. (as I understand, this is not required and it could stay on 1.0.0 and would work either way)

  2. We perform database schema update. This is a bit tricky to me as a manual step but as I see it we have two options:

  • Build the binary with make sql-temporal-tool from the go source.
    The readme claims we should just make but is that necessary for the sql-temporal-tool only?
    After that, we would need to copy the contents of /schema/mysql/v57 and run the individual v1.1, v1.2 and v1.3 temporal and v1.1 visibility updates.
  • The tamporal-sql-tool binary is already available locally in admin-tools, but since we don’t know if it is the latest version, we would probably still need to somehow first upgrade admin-tools first and mount the /schema/mysql/v57 there.
    Or is it safe to assume that the binary has not changed incompatibly and only mounting the sql schema updates into admin-tools and using what is in there for 1.0.0 is OK?
  1. At this point our database schema is updated and backwards compatible, meaning it does not break our 1.0.0 temporal service deployments. Is that correct?
    And what remains is the rolling helm upgrade itself.

Considering the questions, have I described the upgrade procedure correctly? And also, is this the recommended way to do it? Or is there a more “straightforward” way, something like the admin-tools performing the backwards compatible database schema upgrades when they are upgraded themselves?

1 Like
2

about server upgrade:

  1. we currently only support 1.n.x to 1.n+1.x, since server side is going through lots of migrations.

  2. when upgrading the schema, you can either pull the image temporalio/admin-tools/<1.m.n>, or checkout github tag https://github.com/temporalio/temporal/tree/v<1.m.n>

    2.1 the above docker image already comes with the binary and necessary schema files
    2.2 after checking out the github tag, do make bins to compile the binary for schema upgrade
    2.3 please do not use github master branch since this can contains unreleased changes

1 Like
3

Thank you for the reply.

we currently only support 1.n.x to 1.n+1.x, since server side is going through lots of migrations.

Just to make sure I understand this correctly, it is not possible to upgrade directly and the the steps to go from 1.0.0 to 1.5.1 would then need to be 5 deployments:

  1. db schema update to v1.1, temporal helm with server.image.tag=1.1.1 (and other images…)
  2. db schema update to v1.2, temporal helm upgrade to server.image.tag=1.2.2
  3. db schema update to v1.3, temporal helm upgrade to server.image.tag=1.3.2
  4. temporal helm upgrade to server.image.tag=1.4.2
  5. temporal helm upgrade to server.image.tag=1.5.1

?

4

There is nothing prevent you from upgrading directly from 1.0 to 1.5 right now.
HOWEVER, lots of features and migrations are done to the server (e.g. support of infinite timeout)
To guarantee there is no weird behavior during server upgrade, we currently only support 1.n.x to 1.n+1.x upgrade path.

We are working on a long term server upgrade strategy.

For your situation, I believe you can directly upgrade from 1.0 to 1.3, then 1.4 and 1.5

1 Like