Upgrading from v5.1 to v7.1

Hi everyone

I’ve deployed Version 5.1.1 (20700) at my workplace on digitalocean. I’m now planning to upgrade to v7.1 ESR. I’ve read the helpful documentation.

  1. Beyond what’s already mentioned, are there other points to consider?
  2. Should I upgrade to another older ESR before jumping to v7.1?
  3. What does this line in the documentation mean? “Back up your database using your organization’s standard procedures for backing up MySQL or PostgreSQL.”

Thanks for helping.

Hi pranaykotas and welcome to the Mattermost community!

ad 1)
Make sure you read the Important Upgrade Notes, this is basically the only relevant documentation for such a big upgrade. Looking at the page, you will see that starting with 5.22.0 there are quite some big schema changes introduced to the databases and depending on your deployment model, these will take some time to finish, so prepare for a longer downtime during an upgrade.
If you use systemd for starting mattermost, you could run into a timeout while starting due to the long running migrations, so it would be a good idea to not use systemd for such big upgrades but start the server manually for the first time; this also helps with watching the logs directly being printed to the console so you can see what happens in case of errors, but if you upgrade in multiple steps, this should not be necessary.

ad 2)
Personally I would do the upgrade in 3 steps, although this probably isn’t necessary, but YMMV.
I’d suggest to upgrade to 5.39.3 first and if everything worked out, upgrade to 6.3.9 and then to 7.1.2.

You can find the downloadlinks for all older versions in the version archive.

ad 3)
Let’s assume your mattermost is installed to /opt/mattermost and you’re using MySQL for the database and your database is called “mattermost”, then you would (before running the upgrades) make sure that both the mattermost folder and the database is being backed up properly just in case you need to revert when the upgrade fails.
If my assumptions are correct, then you should run the following commands to create the backups:

cd /opt
tar czf mattermost-backup.tgz mattermost
mysqldump --events --triggers --routines mattermost > mattermost-backup.sql && gzip --best mattermost-backup.sql

(Depending on your mysql client configuration, you may need to add the -u username and -p parameter for specifying a password interactively then).

If your mattermost instance is running on a virtual machine, you could also shut it down before you start with the upgrades and take a snapshot of the virtual machine, this will help you to immediately and quickly revert to the state before the updates.

Let me know if this helps you or if you require additional information, we’re here to help :slight_smile:


1 Like

Thanks @agriesser. I’ll try these and get back.

Okay, I tried and failed once. Luckily, the virtual machine snapshot got restored. I also discovered that my mattermost version is 6.3.7, not 5.1.1. The latter was the version number for the Mattermost Apple Store app!

I had installed via mattermost-docker. So I tried to upgrade using the deprecated upgrade-postgres.sh script. That led to several errors, and eventually a failed upgrade.

What should I do now? This?

cd /opt/mattermost-docker/
git stash
git pull (from master of mattermost/mattermost-docker/ in github)
git stash pop
docker-compose down
docker-compose build
docker-compose up -d

I would try to get rid of the old installation and start over wth a fresh setup with a supported environment. Do you want to stick with the docker deployment method?

You will need to start your current setup and make sure you run a backup of your docker volumes (the application files (data, config, plugins, etc.) as well as the current PostgreSQL database, but for PostgreSQL, make sure to dump it using pg_dump, so start your database container and dump the database to a file.
Once you have all your data backed up, you can deploy a new mattermost setup in parallel (in a new directory, on a new system, whatever you prefer) and make sure to use the same version you’re currently running for that, that is 6.3.7.
Once you’ve prepared the environment, restore the saved files (config, data, plugins, etc.) to the new installation (watch out for the filesystem permissions!) and import the database into the new container/database, modify the paths (if they change and if they are mentioned in config.json) and then your new setup should be running in a supported environment with your old data again. Make sure to test everything thoroughly and if you feel fine with your new setup, you can then easyily run the inplace upgrade to 7.1.2.

Let me know if I need to be more specific on certain parts of my posting, but in order to do so, I will need to know a few more details about your current and target setup.

Update: You can also use the upgrade-postgres.sh script, it will also automatically run backups, but you will stay with the current deployment model then, if that is what you prefer.

Thanks much, @agriesser. I used digitalocean and installed using this docker repository.

I want to do this using upgrade-postgres.sh because I’m a complete noob.

My issue was that the upgrade-postgres.sh uses two files $PATH-TO-DOCKER/db/Dbfile and $PATH-TO-DOCKER/app/Dbfile which aren’t present in my setup. I tried to copy the ones from the older mattermost-docker github repository, but the installation got terminated. How do I proceed?

Well, if you use mattermost/docker instead of mattermost-docker, then you do not have to go through the hassle at all. You can just change the releaes tag in your .env file and upon a restart, your new mattermost version will be up and running.

To see what we are facing here, please provide the output of docker ps. It should look like this on a mattermost/docker setup (without nginx):

# docker ps
CONTAINER ID   IMAGE                                      COMMAND                  CREATED              STATUS                        PORTS                                                                NAMES
0c6d75268337   mattermost/mattermost-team-edition:7.1.2   "/entrypoint.sh matt…"   About a minute ago   Up About a minute (healthy)   8067/tcp,>8065/tcp, :::8065->8065/tcp, 8074-8075/tcp   mm-712-mattermost-1
1a8222dff765   postgres:13-alpine                         "docker-entrypoint.s…"   About a minute ago   Up About a minute             5432/tcp                                                             mm-712-postgres-1

You can see the two container IDs for the mattermost application (first one) and the database (second one).
In order to find out what paths you’re using inside the containers, you could check the configured mountpoints for them using this command:

# docker inspect 1a8222dff765 | jq .[].Mounts
    "Type": "bind",
    "Source": "/root/mattermost/mm-7.1.2/volumes/db/var/lib/postgresql/data",
    "Destination": "/var/lib/postgresql/data",
    "Mode": "rw",
    "RW": true,
    "Propagation": "rprivate"

So you can see that my container’s PostgreSQL data directory is located at “/root/mattermost/mm-7.1.2/volumes/db/var/lib/postgresql/data” on my host system.
With regards to the upgrade-postgres.sh script, all you need to specify here is the base directory of your current docker deployment, no the database directories themselves, so most likely this is the path where your Dockerfile resides.

Oh, great. Didn’t know that it just needs a change in the .env file. It’s not mentioned in the help docs.

Here’s the docker ps output

CONTAINER ID   IMAGE                                          COMMAND                  CREATED        STATUS                  PORTS                                                                      NAMES
b4bbb2de6ee4   nginx:alpine                                   "/docker-entrypoint.…"   3 months ago   Up 18 hours   >80/tcp, :::80->80/tcp,>443/tcp, :::443->443/tcp   nginx_mattermost
8194b2b576c5   mattermost/mattermost-enterprise-edition:6.3   "/entrypoint.sh matt…"   3 months ago   Up 18 hours (healthy)   8065/tcp, 8067/tcp, 8074-8075/tcp                                          mattermost
df6ee72664e0   postgres:13-alpine                             "docker-entrypoint.s…"   3 months ago   Up 18 hours             5432/tcp                                                                   postgres_mattermost

So, if I understand it right, I should do the following?

change the .env file to reflect the new mattermost version tag. Then run:

sudo docker-compose -f docker-compose.yml -f docker-compose.nginx.yml down
sudo docker-compose -f docker-compose.yml -f docker-compose.nginx.yml restart

Or should I do the following after updating the .env file?

docker container stop nginx_mattermost mattermost
docker container restart nginx_mattermost mattermost

In other words, do I redeploy or restart in order to retain all data, channels, etc.

Since you’re already on the new, supported docker deployment model, all you need to do is:

docker-compose -f docker-compose.yml -f docker-compose.nginx.yml down
docker-compose -f docker-compose.yml -f docker-compose.nginx.yml up -d

This should bring you directly to 7.1.2.

1 Like

It worked. Can’t thank you enough @agriesser

You’re welcome, great to hear you’re up and running now :slight_smile:

1 Like