perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Kathy Benninger writes:

I ran into the postgresql 8.4/9.5 error on backup, which resolved with removal of the 8.4 rpms…

 

That problem is CentOS 6-specific and will go away once you’re at CentOS 7.  I don’t have plans to correct it since support for CentOS 6 is being dropped in the next release.

 

…and the following error when I did the restore:

[root@rumba tmp]# /usr/lib/perfsonar/scripts/ps-migrate-restore.sh --data rumba-ps-backup_30Mar18.tgz
…
Restoring pScheduler from backup:
  Unpacking backup... Done.
  Restoring configuration... Done.
  Restoring database...

Database restore failed:
ERROR:  syntax error at or near "%"
LINE 1: DROP DATABASE IF EXISTS %{_pscheduler_database_name}_save;
                                ^

Restoring prior database... FAILED.ERROR:  syntax error at or near "%"
LINE 1: DROP DATABASE IF EXISTS %{_pscheduler_database_name};

 

That is a bug that slipped through because of a chicken-and-egg problem in my development environment.  The RPM spec that builds the package made use of a macro that wouldn’t have been available on a pristine system like the one where the production builds are done.  It was available on my development system because it had been installed during a previous build and wasn’t wiped out.  I’ve corrected that (and will adjust my dev and testing procedures) and will see about getting another bugfix release out after one cycle of the nightly build gets through our test bed.

 

A quick post-mortem of what will have happened on your system:  The usual process is to rename the existing database, do the restore and then get rid of the renamed database if the restore was a success or put it back as it was if the restore fails.  With this bug, the initial rename failed and the whole process stopped there, leaving the existing database intact.  All of the configuration files on your system are what was in the backup.  (We don’t have a way to make the whole thing transactional so we can roll it back.)

Can I rely on the backup/restore in spite of the error message?

 

The backup is fine and will be restorable once the bug is corrected in the production release.

 

If you want to hand-patch the system and do a restore before we get the bug fix out, edit /usr/libexec/pscheduler/commands/restore and change the string %{_pscheduler_database_name} at line 155 to pscheduler.  A restore following that should succeed.

 

--Mark