v6.0.0 to v6.1.0 updgrade - database schema migration

[chadbillanderson]

Hello, I'm running the mattermost-enterprise-edition docker image, v6.0.0

I noticed the main release v6.1.0 notes mention a database schema change https://docs.mattermost.com/install/self-managed-changelog.html#release-v6.1-feature-release https://gist.github.com/streamer45/997b726a86b5d2a624ac2af435a66086

However, there is no mention of the change for the docker version. Do I need to apply the same migration steps mentioned in the above link, or can I proceed with my upgrade like normal with no issues?

Thanks!

[AyoubHabra]

Hello, I'm facing the same issue. I tried to perform the migration without the scheme migration, but it didn't work (the UI was not updated and users were not able to send messages anymore). The scheme migration is required. Don't try to test the upgrade without scheme migration because you will not be able to roll back and the 6.1 version won't work . (I had to restore the database from a dump in order to make it work with the previous version of mm). In addition to these steps, you may need to fix the json timezone : ALTER TABLE users ALTER COLUMN timezone DROP DEFAULT and refer to the app logs to get more information. It worked for me in the test env, but I think it's a little risky to apply this in production without the confirmation of maintainers ... Dear maintainers, I believe that there are a lot of users struggling with this issue. Please give us your feedback or a well-documented workaround.

[savinoda]

So will this repository handle those update and upgrade cases? I had the same problem. Finally I was able to solve in the same ways that @AyoubHabra suggested. My question is... the repository is stuck at 5.39 with 6.1 already available: will be there commits in which the .env gets updated and all the problems with updates/upgrades handled by an update script? The problem is that I can change the release tag and try to rebuild everything but if some steps are needed on the Db this will of course fail

[craph]

@jasonblais , @hanzei , Do you have any idea / plan about this issue ? Is it possible to have a script that is automatically run from the dedicated Docker image like for the upgrade process ? Thank you very much. Best regards,

[hanzei]

@cpanato Is that something the release team would take ownership of?

[ccoenen]

(please have common sense in place, and a good backup!)

I just threw 6.1.0 into my .env file and did a docker-compose pull and then a docker-compose up -d. It looks fine. But I'm also running a rather small server, meaning: no cluster; short downtime was expected and OK (a minute or two maybe?).

[savinoda]

(please have common sense in place, and a good backup!)

I just threw 6.1.0 into my .env file and did a docker-compose pull and then a docker-compose up -d. It looks fine. But I'm also running a rather small server, meaning: no cluster; short downtime was expected and OK (a minute or two maybe?).

This does not work if you migrate from 5.39 to 6.x. Simply changing the version of the app won't have any effect on the database schema. And the app won't start because of some errors (they were discussed in other issues). Indeed, when you fix those the first time (for example after migrating from 5.39 to 6.0) than you can easily change the version in the .env file and that will work (because from 6.0 to 6.1 they haven't changed anything in the schema). But if they do it in the future you 'll have to manually do it again. That was my question: is this repo only a starting point for a docker environment to run mattermost (and then anyways one has to take care of those cases?) or is the management of those updates somehow in the its purpose?

[ccoenen]

I did exactly that, though. And it still works. I went from 5.39 straight to 6.1.

[craph]

Hi, I tried on a sandbox to do the upgrade. I started fom MM 5.38 -> 5.39 -> 6.0 -> 6.1 and everything goes well.

I just changed the MM version in the .env file, then run docker-compose pull to download the right docker image. In version 6.1 I checked in the database for the new schema changes and all are up-to-date with the new values that we can find here

[mrckndt]

@chadbillanderson @AyoubHabra I can't say what's wrong with your instances (especially without any logs or more information) but those problems are probably unrelated to the question asked here. So to give an answer here: No, there are no manual migrations needed. Mattermost is doing the migrations itself when needed and regardless of the version you're coming from. As correctly mentioned in the "important Upgrade Notes" (https://docs.mattermost.com/upgrade/important-upgrade-notes.html) you MAY want to run the index creation query in the background IF your jobs table contains millions of rows to shorten the startup after the upgrade because database migrations are done after upgrades at the first startup. If the startup time doesn't matter and your jobs table is huge you don't need to do any manual migration too.

@savinoda this is not true.

This does not work if you migrate from 5.39 to 6.x. Simply changing the version of the app won't have any effect on the database schema.

[AyoubHabra]

@mrckndt @craph Thank you for your feedback. I need to mention that I have migrated my instances from the other version of mattermost: https://github.com/mattermost/mattermost-docker and I confirm that the migration from 5.x versions is automatically handled by mattermost when using directly the redesigned Mattermost (new installations from scratch). In fact, I had issues with instances that I have migrated from the other version. But, applying the steps mentioned above fixed the problem for me.

[savinoda]

@chadbillanderson @AyoubHabra I can't say what's wrong with your instances (especially without any logs or more information) but those problems are probably unrelated to the question asked here. So to give an answer here: No, there are no manual migrations needed. Mattermost is doing the migrations itself when needed and regardless of the version you're coming from. As correctly mentioned in the "important Upgrade Notes" (https://docs.mattermost.com/upgrade/important-upgrade-notes.html) you MAY want to run the index creation query in the background IF your jobs table contains millions of rows to shorten the startup after the upgrade because database migrations are done after upgrades at the first startup. If the startup time doesn't matter and your jobs table is huge you don't need to do any manual migration too.

@savinoda this is not true.

This does not work if you migrate from 5.39 to 6.x. Simply changing the version of the app won't have any effect on the database schema.

Well, for me it does not work automatically because I first need to run this query:

ALTER TABLE users ALTER COLUMN timezone DROP DEFAULT

Now, I may have used an incorrect expression when referring to database schema, but I was referring to cases like the one just mentioned

[AyoubHabra]

@mrckndt you asked for a log. Well, I got this log from my one of my production instances and I have been able to fix it by running the query : ALTER TABLE users ALTER COLUMN timezone DROP DEFAULT . LOG: app_1 | {"timestamp":"2021-12-20 21:06:13.055 +01:00","level":"fatal","msg":"Failed to alter column type. It is likely you have invalid JSON values in the column. Please fix the values manually and run the migration again.","caller":"sqlstore/store.go:906","error":"pq: default for column \"timezone\" cannot be cast automatically to type jsonb","tableName":"Users","columnName":"Timezone"} I hope that this will help you find out the root cause. But I think that is related to the migration. Isn't it ?

[mrckndt]

@AyoubHabra good this fixed the issue for you but it's not a Docker specific issue though. This needs to be in mattermost-server.