Noticed that when we moved into multi-container mode, restoring the DB resulted in unexpected site down time (while the backup is loaded into the DB):
So, I did some digging around in
postgres.template.yml and noticed that
app.yml and the path to the stand alone container
standalone shared space are hardcoded into this template.
I’m not by any means an expert at these files (yet) , and since the code has mostly informative “echos”, the content looks more “informative to the user” than breaking:
Examples from Template
echo Run: "./launcher stop app" echo Run: "sudo mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old" echo Run: "./launcher rebuild app" echo echo Run: "./launcher enter app" echo Run: "cd /shared/postgres_backup" echo Run: "sv stop unicorn" echo Run: "sudo -iu postgres dropdb discourse" echo Run: "sudo -iu postgres createdb discourse" echo Run: "sudo -iu postgres psql discourse < backup.db" echo Run: "exit" echo Run: "./launcher rebuild app" exit 1
if [ "$PG_MAJOR_OLD" = "9.5" ]; then echo 'In containers/app.yml: Change "templates/postgres.template.yml" TO "templates/postgres.9.5.template.yml"' echo fi
mostly all seems “informative and not breaking I assume”
It’s probably not important, but since the various tutorials on site mention this template and renaming the data container to “data” and the web container to “web-only”, for example, I thought it is worth mentioning.
FYI only, maybe for a future look way down the road …