Restoring backup from 2.0.0.beta5 disables Discourse

bug
1

I’m trying to restore a backup from a hosted site running "Discourse 2.0.0.beta5 - https://github.com/discourse/discourse version 6f32de186aa1d9e0814183f354bb01f5b66d1c0e.

When I restore on a clean build, or one that’s gone through the setup wizard, it fails and leaves the database in such a state that Discourse doesn’t run anymore.

This is (PostgreSQL) 9.5.10 in the container.

Starting restore: discourse-2018-04-03-183844-v20180328180317.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2018-04-03-222730 exists...
Copying archive to tmp directory...
Unzipping archive, this may take a while...
tar: meta.json: Not found in archive
tar: Exiting with failure status due to previous errors
No metadata file to extract.
Validating metadata...
  Current version: 20180328180317
  Restored version: 20180328180317
tar: dump.sql: Not found in archive
tar: Exiting with failure status due to previous errors
Extracting dump file...
Cannot restore into different schema, restoring in-place
Enabling readonly mode...
Pausing sidekiq...
Waiting for sidekiq to finish running jobs...
Restoring dump file... (can be quite long)

Here’s the whole log: https://gist.github.com/pfaffman/af61e1ae43b3e193232cdeb9b477ab13

And then, when it’s done, Discourse says:

2

Update:

I upgraded the target site to the latest postgres with a couple ./launcher rebuild apps (great job, @tgxworld!), downloaded a new backup from the Discourse hosted site, and it restored without a hiccup.

2 Likes
3

So you were experiencing this except for the fact that your database dump wasn’t actually broken, the 10.3 dump just appeared broken to your 9.5.10 psql.

2 Likes
4

I don’t pretend that I completely understand everything that’s going on here, but that seems right to me.

5

What is happening is this:

  • You have a dump created by pg_dump version 10.3
  • You are attempting to restore it on Postgresql 9.5.
  • The restore script moves all tables to a different scheme called ‘backup’. The purpose of this is to move them out of the way, so the restore will have an empty database to restore to. They are moved to a different scheme instead of being deleted, so when the restore fails, they can be moved back where they came from.
  • psql bails out because it isn’t able to handle a dump made by a newer version of Postgres. (“old versions of pg_restore will therefore refuse to process files made with new versions of pg_dump.”)
  • the restore script usually moves the files back from the backup scheme to the public scheme when the restore fails, but it does not, leaving you with an empty scheme.
4 Likes
6

Well, I don’t know what the problem is today. I swear that I got it to restore yesterday, but now that I’ve rebuilt, neither yesterday’s nor today’s backup will restore.

I’m trying to restore to a standard install that I just rebuilt.

Dump file from Discourse 2.0.0.beta5 - https://github.com/discourse/discourse version b1cc368da8ce1715ddaa6bc640b361505b22f1be" states:

-- Dumped from database version 10.2 (Ubuntu 10.2-1.pgdg16.04+1)
-- Dumped by pg_dump version 10.3 (Ubuntu 10.3-1.pgdg16.04+1)

Restore does this:

[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2018-04-06-172529 exists...
Copying archive to tmp directory...
Unzipping archive, this may take a while...
tar: meta.json: Not found in archive
tar: Exiting with failure status due to previous errors
No metadata file to extract.
Validating metadata...
  Current version: 20180328180317
  Restored version: 20180328180317
tar: dump.sql: Not found in archive
tar: Exiting with failure status due to previous errors
Extracting dump file...
Cannot restore into different schema, restoring in-place
Enabling readonly mode...
Pausing sidekiq...
Waiting for sidekiq to finish running jobs...
Restoring dump file... (can be quite long)
SET
SET
SET
SET
SET
set_config
------------
(1 row)
SET
SET
SET
ERROR:  function "raise_topic_status_updates_read_only" already exists with same argument types
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
7

Does @tgxworld’s fix (https://github.com/discourse/discourse/commit/5da7c2a4ad6c9eae5cb80887433d4a20fb50a221) resolve this?

1 Like
8

Something worked. (I’m not sure exactly what.)

It’s working now!

3 Likes
9

This topic was automatically closed after 28 hours. New replies are no longer allowed.