Mattermost v8.0+ and PostgreSQL
-
I am running Cloudron for 10+ paying customers and counting. One of the reasons how I convince them to use Cloudron is the maintenance of their open source software. All of them use mostly Mattermost. Obviously I’m not too happy that you don’t offer a migration path and make us do the work manually.
-
@mtd-sales you have to ask Mattermost team to provide a proper a migration path, this is not something we (cloudron team) can do. We just package the app.
https://github.com/mattermost/mattermost/issues/18351 is the upstream issue.
-
@mtd-sales you have to ask Mattermost team to provide a proper a migration path, this is not something we (cloudron team) can do. We just package the app.
https://github.com/mattermost/mattermost/issues/18351 is the upstream issue.
-
@girish looks like that issue https://github.com/mattermost/mattermost/issues/18351 is officially closed as the migration path is documented and successful at this point.
@ericdrgn thanks. https://github.com/mattermost/docs/blob/master/source/deploy/postgres-migration.rst are the instructions it seems.
I am thinking of the below:
- pgLoader, morph and dbcmp tools can be preinstalled into the package.
- New installations will use postgres automatically
- Existing package will be converted to contain access to both a postgres and mysql database. Users have to follow the upstream docs to migrate.
Thoughts?
-
That's probably the best way to do it, if anyone doesn't necessarily care about the data in mattermost they can just archive the mysql version and spin up a new one that automatically uses postgres, otherwise the migration steps aren't crazy if maintaining the data is important.
-
@ericdrgn thanks. https://github.com/mattermost/docs/blob/master/source/deploy/postgres-migration.rst are the instructions it seems.
I am thinking of the below:
- pgLoader, morph and dbcmp tools can be preinstalled into the package.
- New installations will use postgres automatically
- Existing package will be converted to contain access to both a postgres and mysql database. Users have to follow the upstream docs to migrate.
Thoughts?
-
@girish said in Mattermost v8.0+ and PostgreSQL:
New installations will use postgres automatically
Was this implemented? We ran into the same problem but noticed new installations are still not using Postgres.
-
@joestarrd not yet. Currently, the postgresql is going through some updates related to immich and discourse. We have to sort out the issues there before we attempt to move mattermost to postgres and test how compatible it is.
-
I checked their docs and the forum and afaict MySQL is not deprecated. I found nothing in their docs atleast. https://docs.mattermost.com/deploy/postgres-migration.html is quite complicated but it does say PostgreSQL is preferred. We have many users using Mattermost and it would be too much work to make them migrate, especially since it is still supported upstream. Do you know any timeline of deprecation? Upstream docs don't mention anything about deprecation from what I tried to find.
-
This is the original reference:
Basically the AI plugin will only be available on postgresql.
Furthermore, others plugins are dropping mysql support accordingly, ie:
I don't think anyone expects a smooth migration of their existing instance but it would great if we can get a supported postgresql package.
-
G girish referenced this topic on
-
@girish what about having a new Mattermost package, with the same name as the current one and shipping with postgresql.
The current package (with MySQL) would have
mysqlsomewhere in it's name, and then allow users to install whichever version they wish.Other than that, it looks like they are (or will be) abandoning MySQL support slowly
-
-
@chymian we have not made this move yet. It requires obsoleting the old package and moving to postgres. And yet, there is no easy way on mattermost side to switch databases. Essentially, we will have to abandon all our existing mattermost installation base. It's a difficult decision to make. Maintaining two separate packages while possible is just additional work for a single app. We have to make separate tests and packages for every mm release.
-
ok, thanks @girish,
Yes, the change will certainly not be easy and will require a lot of work on both sides.
This has been discussed for about a year now and there is still no solution in sight - not even for new installations.
The non acceptable burden here is, the additional effort to "new install" an outdated solution, which causes a additional work/data loss in switching systems whenever you (have to) change to postrgresql. -
@chymian we have not made this move yet. It requires obsoleting the old package and moving to postgres. And yet, there is no easy way on mattermost side to switch databases. Essentially, we will have to abandon all our existing mattermost installation base. It's a difficult decision to make. Maintaining two separate packages while possible is just additional work for a single app. We have to make separate tests and packages for every mm release.
@girish said in Mattermost v8.0+ and PostgreSQL:
And yet, there is no easy way on Mattermost side to switch databases.
I don't understand your remark as there is a whole page dedicated to the migration from MySQL to PostgreSQL : https://docs.mattermost.com/deploy/postgres-migration.html
I understand it is a decision which can be hard to take as it will make some users unhappy, but at some point you will have to make it because Mattermost is slowly but surely deprecating MySQL.
So the real question is not if you have to do the move or not but when you make it.
And IMHO the sooner the better :- The more you wait, the more installations will be made on Cloudron using MySQL which will have to be migrated and therefore more users/customers will be impacted/annoyed
- People will move to something else than Cloudron for their install as PostgreSQL is required by more and more features.
-
@cvachery I am totally with you. I find the migration guide quite complex. In many apps, one can just export and import using some portable format but instead in this guide we have to resort to become a db admin. Most Cloudron users have no experience with level of database administration and this is the source of issue.
I guess we have to just bite the bullet and migrate away and hope for the best
