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?

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

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

I still do not understand your question, slowly, can you explain clearly what you are asking for … and first read this: templates/web.template.yml master filename: "/etc/nginx/conf.d/discourse.conf" from: /client_max_body_size.+$/ to: client_max_body_size $upload_size ;

[imagem]Manually update Discourse and Docker image to latest If you want zero downtime, you must run 2 web containers and cycle them in and out using haproxy 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?

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

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

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

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.

[imagem] sam: 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. This is exactly what I’m talking about. And I’m happy that you follow this practice. Thank you.

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

Product Support

sam (Sam Saffron) 3 Abril , 2015 21:25 7

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

Tópico		Respostas	Vistas
How do I upgrade Discourse in a multiple container configuration? Self-hosting	2	980	8 Outubro , 2020
Upgrade without rebuilding having a good/ready image? Product Support	5	237	13 Dezembro , 2025
Zero Downtime Upgrades Development	1	2190	11 Setembro , 2019
Is it by design that updates via web UI can provoke breaking changes? Product Support	3	250	3 Janeiro , 2025
Help with "zero downtime" setup Self-hosting hosting	7	2442	10 Setembro , 2020

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

Related topics