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


#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?


How do I manually update Discourse and Docker image to latest?
How do I manually update Discourse and Docker image to latest?
(Sam Saffron) #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?


(Sam Saffron) #4

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


#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?


#6

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


(Sam Saffron) #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.


(Sam Saffron) #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.


#11

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


(Jens Maier) #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…