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.
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 
Best,
Alex
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, 0.0.0.0:8065->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 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->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
sed -i -e 's/^MATTERMOST_IMAGE_TAG.*/MATTERMOST_IMAGE_TAG=7.1.2/' .env
docker-compose -f docker-compose.yml -f docker-compose.nginx.yml up -d
This should bring you directly to 7.1.2.
It worked. Can’t thank you enough @agriesser
You’re welcome, great to hear you’re up and running now