Bug 910748

Summary: Database restore script complains about existing entries and fails horribly
Product: Red Hat Enterprise Virtualization Manager Reporter: Petr Spacek <pspacek>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED CURRENTRELEASE QA Contact: Artyom <alukiano>
Severity: unspecified Docs Contact:
Priority: high    
Version: 3.1.2CC: acathrow, dyasny, iheim, lpeer, pspacek, pstehlik, Rhev-m-bugs, yeylon, ykaul, yzaslavs
Target Milestone: ---   
Target Release: 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
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: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 915537    
Attachments:
Description Flags
Console session
none
Output of restore.sh script none

Description Petr Spacek 2013-02-13 13:27:05 UTC 
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 13:28:34 UTC 
Created attachment 696802 [details]
Console session
Comment 2 Petr Spacek 2013-02-14 11:23:43 UTC 
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 07:50:40 UTC 
fixed in commit : befc68a
Comment 8 Artyom 2013-04-28 11:15:36 UTC 
Created attachment 741118 [details]
Output of restore.sh script
Comment 9 Artyom 2013-04-28 11:18:39 UTC 
After reproducing steps below, bug still exist, see attachment.
Comment 10 Artyom 2013-04-28 11:23:34 UTC 
Reproduced on sf13.
Comment 11 Eli Mesika 2013-04-28 14:15:49 UTC 
this commit was merged in sf13.1 , please recheck
Comment 12 Artyom 2013-04-29 05:28:38 UTC 
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 06:16:10 UTC 
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 07:44:50 UTC 
(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 09:07:23 UTC 
3.2 has been released
Comment 16 Itamar Heim 2013-06-11 09:07:25 UTC 
3.2 has been released
Comment 17 Itamar Heim 2013-06-11 09:07:29 UTC 
3.2 has been released
Comment 18 Itamar Heim 2013-06-11 09:36:05 UTC 
3.2 has been released