Documentation to upgrade very old version (3.1) to newest

[metal3d]

I didn't found the discussion section, so I ask it as an issue. Sorry if it's not the right place.

I deployed mastodon (techlover.eu) a long time ago with the helm chart.

helm -n mastodon list
NAME     	NAMESPACE	REVISION	UPDATED                                 	STATUS  	CHART          	APP VERSION
mastodon 	mastodon 	10      	2021-07-12 14:18:44.565497611 +0200 CEST	deployed	mastodon-0.1.0 	3.1.5      

I want to migrate version to the latest (even if I need to pass to 4.x then 5.x...)

There are many risks, even if I did database backups, I really don't know the procedure excepting getting the chart and try to upgrade.

Old helm charts points on removed dependencies, so it could be very difficult to fix a failed upgrade.

• is there something to do to "dump" the current instance and "import" if something goes wrong (I mean, if I need to completely remove the instance to install the last one)
• is there any chance to find out the 4.X version and to do the update?
• Something weird: I remember that I did a PR, years ago, to fix something ([HelmChart] Fix postrgres secret name for cronjob mastodon#15072). So the helm chart I used is not those on this repository. :(

A solution that I wanted to do is to install a new version in another namespace, and to have a data transfer from the old instance... any way to do this?

I'm afraid to lose everything.

(Yes, I should have updated more often, but I've had a busy life with a baby, an illness, and a lot of work...)

[renchap]

Hi,

In the general case, if you want to upgrade from a very old version, I would encourage you to read the release notes for every major version since then. I would encourage you to upgrade to Mastodon 3.5.19 (the latest version in the 3.5 train), then the latest 4.1 version, then to 4.3.0.

For each update, you need to follow the docker instructions, basically it will be:

• run the pre-update migrations in a pod using the "new" version"
• restart the services using the new version container image
• run the post-update migrations
• some versions might have specific instructions, for example to rebuild ES indexes if you use them, or some new environment variables to configure

If you want to start from scratch, or move outside of Kubernetes because the complexity is not worth it, you should be able to stop all the services, dump the postgres database, import it elsewhere, migrate all your configuration environment variables (keeping the secrets the same), and restart them (keeping the same version is recommended). This assumes you are using an S3 storage for your assets, if this is not the case, you will also need to migrate the public/system directory that contains your assets.

I hope this helps!