Content
Our old OpenProject 7.1 server failed, but I did have a recent database dump using the "openproject run backup" command. I created a new VM with Ubuntu 18.04 and successfully installed the latest OpenProject 11 according to the documentation. This also installed Postgresql 10.14. I managed to get the old OpenProject 7.1 MySQL database converted to Postgres using the migrate-from-pre-8.sh script available in the site documentation. I stopped the openproject service and attempted to use the pg_restore command according to the online documentation, but the converted backup file is a .sql file and it gave an error. I used the psql command instead to perform the restore, and it starts working OK but gives a syntax error.
The migrated.sql file itself looks like this at that point where the error occurred (copying the work package data):
It looks OK to me. Is there something wrong with the format, or is there perhaps a record that already exists with this index ID of 1? Should I do something else, like drop the openproject database before performing the psql restore? I see the migrated file was dumped from Postgresql 9.6.19 with the docker images from the migration script. I am not an expert in Postgresql, but I assume this file is compatible for importing into Postgres 10.14 - I have not found anything that would suggest otherwise. Any help is appreciated.
Replies (4)
I checked the contents of the public.work_package_journals table, and it did have data that would have a duplicate id. I dropped the table and ran the import again since it has code to recreate it and populate it. It continued importing until the end without the encountering that error. There were lots of other warnings and errors, which I understand is to be expected. I started the openproject service and opened it in the web browser. I see none of our projects. It still just looks like the default installation. Perhaps dropping the openproject database and then importing is the way to go?
I renamed the old database instead of dropping it, and imported from the migrated database. It does have this message, which is causing some issues. I performed the openproject reconfigure, started the services and was able to login and see some things, but it gives the message that it still has some migration tasks that need to be performed.
I recently did move to OpenProject 12, but not an in place upgrade. I first upgraded the database on the existing server the newer Postgres as required, then backed up OpenProject. I created a new server VM with the latest Ubuntu LTS and installed the OpenProject 12 per the installation instructions. I restored the backup file from the old server to the new server and ran a reconfigure. It failed on importing the database, but it was easy to correct the problem. The logs showed it was missing 1 field in one of the tables, so I manually added the field just likeI had done before. It imported fine after that and I am running the latest version on a new server today.
Again today doing an update to the latest 12.5.2 and running
openproject configurefails due to a missing column work_package_journals.schedule_manually. Why does this seem to happen every time there is a minor update? I checked, and sure enough there was no field in that table with that name. I took a guess at the datatype based on the name and added the field to the table as type boolean. I ranopenproject configureand again and it worked.