Upgrading from a release way in the past

(Matt Ginzton) #1

I set up a private instance of Discourse a while ago, for a project that really only matters once a year, so it got ignored since October 2013.

I went to freshen up the Discourse install so people can use it again this year and find

  • Discourse recommends I upgrade, of course: from to current
  • in the meantime, you’ve rolled out Docker and deprecated the manual install method I previously used
  • following the upgrade steps for the old method (which I have successfully followed before), I get a fatal error about database "discourse" does not exist.

Specifically, when doing the rake db:migrate step (or the succeeding rake assets:precompile step), I get ActiveRecord::NoDatabaseError: FATAL: database "discourse" does not exist. I tried just starting up the new installation anyway and unsurprisingly it doesn’t start; I rolled back to the backup of the previous version.

(See errors upgrading Discourse to · GitHub for the full error message and backtrace.)

I’m wondering if some of the databases or tables have been renamed over time, and the upgrade scripts know how to do this upgrade piecewise (so people who were following along closely with most of the interim releases didn’t have problems) but not all at once; do I need to upgrade to one or more interim versions?

Or is there manual DB surgery possible to make this work?

I’m expecting part of the answer involves moving over to the Docker based install which I’m happy to do, but the instructions there start with “upgrade to the absolute latest version of Discourse” before attempting the transition to Docker, so.

Or if there are snapshots of old known-good Docker-based versions and the Docker-based upgrades are more reliable, maybe I could upgrade the old way to the same version as one of these snapshots, then move to Docker, then upgrade to the present?

I would love to get on the current version ( and packaging method (Docker) without losing the real user posts that are already in my existing DB. Thanks for any help.

(Matt Ginzton) #2

I was able to get from the past to the current version (1.0.1) by doing it in smaller incremental steps.

Looking at the manual install guide, the steps basically break down as

  1. Stop services
  2. Make a backup
  3. Obtain newer code
  4. Upgrade database schema/tables to match newer code
  5. Regenerate assets
  6. Start services

Instead of trying to go from to (and now, since I wrote the parent post, to 1.0.1) all in one shot, I decided to break it up into much smaller chunks, but I didn’t want to follow that whole upgrade recipe for each chunk. Instead, I observed it’s really a bunch of preconditions (steps 1-2 in my list above), the meat of it is steps 3-4, and then some postconditions (steps 5-6). I figured I could do the precondition steps 1-2 once, then repeat steps 3-4 many times until I like the results, then do the postcondition steps 5-6 once.

Using this approach, I stopped the services and made a backup, then repeated just the

  • git checkout tagname
  • bundle install
  • rake exec db:migrate

steps for the following tagnames: 0.9.7,,,,, 9.9.8,, 0.9.9,, 1.0.1. Once each db:migrate task completed, I went on to check out the next version, and once all of these were done, I did the assets:precompile step and started bluepill again.

The result seems to have a working database but the CSS is screwed up – the browser gets 404 or other errors with one of the CSS files, and everything looks horrible. I’m hoping I can still follow the steps to export a backup, import it into a docker-based install, and ignore that problem.

I also had a bunch of problems with the interim versions after doing “git checkout” and “bundle install” and then when I ran the “rake exec db:migrate”, getting problems with the postgres or redis configuration in /var/www/discourse/config, including but not limited to

  • no such file or directory - /var/www/discourse/config/redis.yml
  • no such file or directory - /var/www/discourse/config/database.yml
  • fe_sendauth: no password supplied

These were all because the git checkout commands had destroyed the previously working config files. I don’t know the logic behind (some subset of) the config files getting version-controlled, and I’m probably doing something wrong, but I was surprised to find the config files getting blown away by the upgrade steps. Anyway, each time I had such problems I fixed it by copying the .sample files back to the location of the desired .yml file and editing as necessary. In particular, if things try to talk to postgres using the unix domain socket /var/run/postgresql no authentication is required, but if they try to talk to postgres using the TCP socket localhost:5432 then authentication is required. So I found myself specifying the database name and unix domain socket, often by editing db_socket and db_name in discourse_defaults.conf (but sometimes in database.yml or elsewhere).