Bug 910748 - Database restore script complains about existing entries and fails horribly
Database restore script complains about existing entries and fails horribly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.2
Unspecified Unspecified
high Severity unspecified
: ---
: 3.2.0
Assigned To: Eli Mesika
Artyom
infra
:
Depends On:
Blocks: 915537
  Show dependency treegraph
 
Reported: 2013-02-13 08:27 EST by Petr Spacek
Modified: 2016-02-10 14:29 EST (History)
10 users (show)

See Also:
Fixed In Version: sf8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console session (179.86 KB, text/plain)
2013-02-13 08:28 EST, Petr Spacek
no flags Details
Output of restore.sh script (131.84 KB, text/x-log)
2013-04-28 07:15 EDT, Artyom
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 12146 None None None Never

  None (edit)
Description Petr Spacek 2013-02-13 08:27:05 EST
Description of problem:
I attempted to move existing RHEV-M from old machine to newly installed machine. I used file + database backup & restore procedures described in https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/appe-Backups.html .

Version-Release number of selected component (if applicable):
rhevm-dbscripts-3.1.0-43.el6ev.noarch

How reproducible:
100 %

Steps to Reproduce:
0. Backup database from some existing RHEV-M 3.1.2 installation and transfer database backup to clean machine
1. Install clean RHEV-M 3.1.2
2. Run rhevm-setup and answer all questions
3. $ service ovirt-engine stop
4. Restore all configuration files as documented in https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Restoring_Red_Hat_Enterprise_Virtualization_Manager_configuration_files.html
4. Try to restore database:
$ /usr/share/ovirt-engine/dbscripts/restore.sh -u engine -f /home/brq/pspacek/engine-2013-02-13T12-53-58.sql -d engine -r
  
Actual results:
See attached console output. Database was not dropped and restoration process spit huge amount of errors.

Expected results:
Database is restored cleanly. (Note -r option.)

Additional info:
I dropped DB manually and tried restore script again. After that, the restore script died with "psql: FATAL:  database "engine" does not exist".

Workaround:
$ dropdb -U postgres engine
$ psql -U postgres
postgres=# CREATE DATABASE engine WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
postgres=# ALTER DATABASE engine OWNER TO engine;
ALTER DATABASE
Comment 1 Petr Spacek 2013-02-13 08:28:34 EST
Created attachment 696802 [details]
Console session
Comment 2 Petr Spacek 2013-02-14 06:23:43 EST
After manual dropping the database I noticed one other problem with restore script:

The script refused to create C functions with some permission error. I'm not sure if it is result of dropping of the database or what else went wrong, but I had to create all C functions by hand.

My first attempt failed:

$ psql -U engine
engine=> CREATE FUNCTION uuid_generate_v1() RETURNS uuid
engine->     LANGUAGE c STRICT
engine->     AS '$libdir/uuid-ossp', 'uuid_generate_v1';
ERROR:  permission denied for language c

I used procedure from:
http://stackoverflow.com/questions/7014437/error-permission-denied-for-language-c

Then I was able to create all functions after logging as "postgres" user.

$ psql -U postgres -d engine
<now copy&paste CREATE FUNCTION and ALTER FUNCTION statements from backup.sql file to postgres console>

It was my first experience with Postgres, so most probably some more straight-forward way exists.
Comment 4 Eli Mesika 2013-02-18 02:50:40 EST
fixed in commit : befc68a
Comment 8 Artyom 2013-04-28 07:15:36 EDT
Created attachment 741118 [details]
Output of restore.sh script
Comment 9 Artyom 2013-04-28 07:18:39 EDT
After reproducing steps below, bug still exist, see attachment.
Comment 10 Artyom 2013-04-28 07:23:34 EDT
Reproduced on sf13.
Comment 11 Eli Mesika 2013-04-28 10:15:49 EDT
this commit was merged in sf13.1 , please recheck
Comment 12 Artyom 2013-04-29 01:28:38 EDT
I not sure that problem in merge, because I received dropdb error: 
dropdb: database removal failed: ERROR:  database "engine" is being accessed by other users
DETAIL:  There are 1 other session(s) using the database.
Comment 13 Artyom 2013-04-29 02:16:10 EDT
After killing all postgres files with:
for i in 'lsof | grep postgres | awk {'print $2'} | uniq'; do kill -9 $i 
And start postgres:
/etc/init.d/postgresql start
restore.sh script work fine
Thanks to Haim
Comment 14 Petr Spacek 2013-04-29 03:44:50 EDT
(In reply to comment #12)
> I not sure that problem in merge, because I received dropdb error: 
> dropdb: database removal failed: ERROR:  database "engine" is being accessed
> by other users
> DETAIL:  There are 1 other session(s) using the database.

IMHO the script should detect this situation and stop and do not change anything in DB.

Also, some helpful error message like 'Stop ovirt-engine before you start with DB restoration.' or something similar would be really useful.
Comment 15 Itamar Heim 2013-06-11 05:07:23 EDT
3.2 has been released
Comment 16 Itamar Heim 2013-06-11 05:07:25 EDT
3.2 has been released
Comment 17 Itamar Heim 2013-06-11 05:07:29 EDT
3.2 has been released
Comment 18 Itamar Heim 2013-06-11 05:36:05 EDT
3.2 has been released

Note You need to log in before you can comment on or make changes to this bug.