You are here
Hi all,
Right now I am migrating my old redmine server version 3.2.0 to a new server with the lates version of redmine 4.0.3, Turnkey Iso compilance 15.2.
After restore the db backup in the new server to the new one I have connetion issues with the db (error 500), If i restore db by db i can see that the issue occurs when I restore the mysql db from the old server.
In the "mysql" db there are located users, permissions and password that not work with the latest redmine version, i can see that the new version have a new mysql user, called "adminer".
I am sure that there is a little issue with the ussers and privileges but i am not sure of what i have to modify.
Somebody have been the same issue ?
I can addes logs or more info if will be neccessary.
Many thanks.
Hi Borja
First up, it's probably worth sharing how you are attempting to migrate the data. Whilst you don't explicitly note that you are using TKLBAM in your thread, I see you've tagged it, so I assume that you are using that, but it'd be good to be sure. Also, you note that your data is coming from an old TurnKey instance, could you share the specific TurnKey version of that one? If you are unsure, try running 'turnkey-version' (on the old server).
Next up, I'd be interested to hear more about the actual errors (i.e. explicit error messages if possible) that you are encountering when trying to restore the DB.
FWIW, we do have a (somewhat dated) doc page on migrating between major versions with TKLBAM. It's a generic page explicitly for migrating to v14.x (from earlier versions) but the general use case should still apply.
So personally, I'd be inclined to download the whole backup to a directory, then restore pieces bit by bit (documenting as you go, so worst case you can easily retrace your steps). With regards to Redmine specifically, it may be worth just trying to restore the Redmine DB itself, rather than the whole database. You may still need to manually update the Redmine DB user account password (either to match the password that your Redmine instance is already using, or regenerate it, updating both the DB user password and the password stored in Redmine config).
I'm happy to assist with further specifics, but I'd like to hear a bit more about the issues you're hitting before I say too much...
Hi Jeremy,
Hi Jeremy,
Many thanks for your help, finally I restored database per database manually by coomand line, without ussing TKlBAM, but a think that TKLBAM do the same but restoring all the db at the same time.
The issue was that redmine new servers try to connect with the db redmine_production (new server) but the file /var/www/redmine/config/database.yml hade a different password for the redmine db user.
Right now the new server is working with data migrated from the old server, but I continue having a issue when try to access to the info of one issue id.
I supposse that could be a issue related with migration from Mysql 5.6.2 to Maria DB 10.2.
Maybe better option is upgrade first Mysql 5.6.2 to MAriaDb 10.2 in the old server and then create a database bakup to restore it into the new server.
Other option myabe is upgrade the old server direcly to the latest redmine version, but i can not find much info about this.
What do you think ?
Error image:
https://ibb.co/qFyyXq7
Log:
ActionView::Template::Error (missing attribute: settings):
15: <% end %>
16:
17: <% if @issue.safe_attribute? 'assigned_to_id' %>
18: <p><%= f.select :assigned_to_id, principals_options_for_select(@issue.assignable_users, @issue.assigned_to), :include_blank => true, :required => @issue.required_attribute?('assign$
19: <% end %>
20:
21: <% if @issue.safe_attribute?('category_id') && @issue.project.issue_categories.any? %>
app/models/role.rb:223:in `permissions_all_trackers'
app/models/role.rb:232:in `permissions_all_trackers?'
app/models/role.rb:238:in `permissions_tracker?'
app/models/project.rb:554:in `block in assignable_users'
app/models/project.rb:554:in `assignable_users'
app/models/issue.rb:934:in `assignable_users'
app/views/issues/_attributes.html.erb:18:in `block in _app_views_issues__attributes_html_erb__2068222923511493907_47226933925700'
app/helpers/application_helper.rb:1249:in `labelled_fields_for'
app/views/issues/_attributes.html.erb:1:in `_app_views_issues__attributes_html_erb__2068222923511493907_47226933925700'
app/views/issues/_form.html.erb:44:in `block in _app_views_issues__form_html_erb___3835740470830366646_47226932734180'
app/helpers/application_helper.rb:1249:in `labelled_fields_for'
app/views/issues/_form.html.erb:1:in `_app_views_issues__form_html_erb___3835740470830366646_47226932734180'
app/views/issues/_edit.html.erb:8:in `block in _app_views_issues__edit_html_erb___431372330396235269_47226932610960'
app/helpers/application_helper.rb:1242:in `labelled_form_for'
app/views/issues/_edit.html.erb:1:in `_app_views_issues__edit_html_erb___431372330396235269_47226932610960'
app/views/issues/_action_menu_edit.html.erb:8:in `_app_views_issues__action_menu_edit_html_erb___2117238410620154662_47226932531760'
app/views/issues/show.html.erb:139:in `_app_views_issues_show_html_erb__75297441079040767_47226928578800'
app/controllers/issues_controller.rb:107:in `block (2 levels) in show'
app/controllers/issues_controller.rb:100:in `show'
lib/redmine/sudo_mode.rb:63:in `sudo_mode'
Many thanks for your help.
Old server:
New server:
The issue is with all the
The issue is with all the issue ID info pages, not only with one.....
I'm pretty sure that you just need to upgrade the DB schema
I'm pretty sure that the issue you're hitting is that your data (in the DB) is still using the old Redmine 3.2.0 DB schema. I don't think that it's related to MySQL -> MariaDB changes at all). The DB layout has likely changed a bit between Redmine versions (which is normal) and the new version of Redmine isn't finding the data in the DB that it is expecting.
To update the DB schema to Redmine 4.0.3, try this:
After that, fingers crossed, you should be good to go.
Although it's possibly also worth clearing the cache (still in /var/www/redmine):
Hopefully that should all "just work".
If you wish to upgrade Redmine to a newer version, then please see this Redmine doc page. Currently you can skip "Step 1" (we already provide the requirements of versions 4.0.x, as well as the upcoming 4.1.x). You can also skip "Step 2" if you're using TKLBAM. In "Step 3", follow "Option 1". (Out of interest, you'll note that steps 4 & 5 are essentially what I've recommended you try above).
Good luck and hopefully that gets you going... :)
Please post back if you continue to have issues.
Hi Jeremy,
Hi Jeremy,
After updgrade the DB as you suggested, works fine. No more Issues.
Many Thanks for your help.
Best regards.
Great news! :)
Glad to hear that my guess was right and you're back up and running now. Thanks for posting back to confirm.
FWIW, you can restore a single DB from a TKLBAM backup
Re-reading this thread, it might be worth mentioning that TKLBAM isn't an "all or nothing" backup/restore. You can use TKLBAM to do a "staged" restore, including just restoring specific files and/or databases (or even just DB tables!). The way to do that is to split the restore up into stages.
First download the full backup:
Then you can restore specific files/databases from that directory via "limits". As noted on the man page, the '--limits=' switch accepts a space separated list of files/databases to include/exclude. So to just restore '/some/directory', you would use this command:
Or to restore a MySQL/MariaDB database called 'some_db':
You can also provide specific exclusions, by proceeding the limit with a minus/dash (i.e. '-'). So to restore everything except '/some/other/dir', you could do this:
You can also mix and match exclusions and inclusions to ensure that you only restore the specific files/directories/etc that you want. E.g. to restore '/some/directory' but not '/some/directory/but/not/this':
The only important thing to consider is that whilst TKLBAM has a 'restore-rollback' command, it only saves one set of rollback data. So doing a staged restore means that you can only rollback the last restore command that you've run, not the full staged process.
Add new comment