Description of problem: In order to prevent issues with restore with unfinished tasks, engine-back will wait for a configurable amount to start backup, if async tasks are running, and will retry for configurable amount of times before failing on inability to run due to tasks running. This can be also resolved by not backing up these tasks at all.
(In reply to Yaniv Dary from comment #0) > Description of problem: > In order to prevent issues with restore with unfinished tasks, engine-back > will wait for a configurable amount to start backup, if async tasks are > running, and will retry for configurable amount of times before failing on > inability to run due to tasks running. How to check these? How to configure? > > This can be also resolved by not backing up these tasks at all. How? Please update the wiki and/or add other relevant links. Also, is the system supposed to work well with some tables not backed up at all? If we want just the schema, pg_dump of 9.2 has an option '--exclude-table-data'. Also, I do not really understand why we need this bug. Since 3.4, we require running engine-setup immediately after finishing restore, and before the engine is started. This AFAIU should be enough to clean up async tasks and similar stuff.
After a discussion with Oved: I need a list of tables that should be emptied by a backup/restore cycle. Eli - please provide this list. Current plan is to leave backup untouched, and empty these tables on restore. This will be much simpler. I think I'll add an option to not do that, something like --keep-temporary-data or something like that. Comments are welcome.
I don't think that this is the right approach to go You may backup the system anytime, removing the temporary data while engine is running is dangerous I prefer that engine-backup will expose the pg_dump -T parameter
(In reply to Eli Mesika from comment #3) > I don't think that this is the right approach to go > You may backup the system anytime, removing the temporary data while engine > is running is dangerous That's why I proposed to do this on restore > I prefer that engine-backup will expose the pg_dump -T parameter This means the tables will not be available at all after restore, instead of being empty. pg 9.2 has '--exclude-table-data' but el6 has 8.4, so we can't use that.
List of tables : async_tasks async_tasks_entities business_entity_snapshot command_entities job step
With the current pending patch in gerrit, the log says: 2015-04-19 17:17:19 14876: Cleaning up temporary tables in engine database 'engine': 2015-04-19 17:17:19 14876: - async_tasks NOTICE: truncate cascades to table "async_tasks_entities" TRUNCATE TABLE 2015-04-19 17:17:20 14876: - async_tasks_entities TRUNCATE TABLE 2015-04-19 17:17:20 14876: - business_entity_snapshot TRUNCATE TABLE 2015-04-19 17:17:20 14876: - command_entities TRUNCATE TABLE 2015-04-19 17:17:20 14876: - job NOTICE: truncate cascades to table "step" NOTICE: truncate cascades to table "job_subject_entity" TRUNCATE TABLE 2015-04-19 17:17:20 14876: - step TRUNCATE TABLE That is, in addition to the ones in comment 5, NOTICE: truncate cascades to table "job_subject_entity" Is that ok/expected?
(In reply to Yedidyah Bar David from comment #6) > With the current pending patch in gerrit, the log says: Yes, cascaded operations resulted from deleting a record which have a PK that is defined in other table as FK ON CASCADE DELETE , is OK
Created attachment 1044949 [details] engine backup db results with async tasks Verified with: ovirt-engine-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch Added a host to the engine and ran engine-backup while running task. Results from db attached. After restore, the tables async_tasks, async_tasks_entities, business_entity_snapshot, command_entities, job and step remain empty.
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.