Can you upgrade Discourse seamlessly if there is a breaking db change?

support
1

But what about migrations? Do they respect upgrades between new releases? How do you manage to solve the case when new release makes breaking changes in db?

2

Can you explain you question, keeping in mind that each rebuild will run db:migrate

3

If one of the docker container makes breaking changes in db how do they share the same db in production?

4

I still do not understand your question, slowly, can you explain clearly what you are asking for … and first read this:

https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L135-L137

5

So, one container in public and the second one is on stage. Let’s imagine that the second one goes with migration which makes breaking changes in db (for example, removes column). How do the first one will react on this?

1 Like
6

As far as I understand you, both of the containers will share the same db. Am I right?

7

breaking db changes will always cause downtime we can not magic that away

8

It’s possible by making them responsible for old code and some kind of convention, imho.

9

Otherwise, people have to observe migrations that you have done.

10

I have no idea what you are proposing here and am having extreme issues following you.

IF we decide one day to rename the table topics to amazing-topics then old web servers running our old repo will break. Only way to keep them working under such conditions is to create a writable view during the migration that keeps backwards compat in place.

In general our migrations are backwards compat. Rarely they are not, when they are not there is a minor outage.

I am happy with you to slowly explain your technical recommendations but your one-liners here are not really helping me.

1 Like
11

This is exactly what I’m talking about. And I’m happy that you follow this practice. Thank you.

12

Well… you could use a semantic versioning scheme for the schema versions:

  • If the migration updates the major version, all workers must be taken down,
  • if it updates the minor version, workers on the old version must be in read-only mode,
  • and if only the patch version changes, workers can keep running throughout the migration.

If someone wants to maintain a huge Discourse cluster, they’ll know how to perform the upgrade, assuming that they have a custom tool that orchestrates all the launchers on the machines involved…

2 Likes
14

Our current practices are to always ensure all upgrades from direct previous versions never ship breaking scheme