Defect #4206
closedRepeatedly running of db_migrate fails silently
0%
Description
As part of a major Redmine upgrade, I set up a new VM and did a clean install of Redmine 0.8.5, then imported DB, files and SVN repos and ran db_migrate, db_migrate_plugins and the SVN repo updates. This environment then got tested and approved, while the old environment remained in use for real.
At switch time, I re-imported the DB, files and SVN repos, and re-ran the migrate steps. No warnings were issued.
However, we then started seeing internal server errors on some (but not all) repositories and Wiki pages. I originally surmised the SVN issue to be some sort of timeout, because it seemed to work for smaller repos, and appeared to die on revision 112 of my large repo I used for verification; and turning off automatic loading of revision information in the SVN option of Redmine also mostly fixed the problems.
Googling for the wiki issue I was seeing, however, led me to http://www.redmine.org/issues/1681 and http://www.redmine.org/issues/3553 . I retried the db_migrate as suggested, but that didn't work, then modified the tables as described in the comments, and that fixed the problems I was seeing.
The conclusion I draw from this, is that db_migrate either thinks it doesn't need to do anything, or fails silently when re-run on an installation where it's been run before but the database has been re-imported from a not-updated one. Given that the implementation scenario I've used is not that unreasonable or uncommon, this may be worth looking into, I think.
The new Redmine server is on Debian 5.0.3 (Lenny), MySQL 5.0.51, Apache 2.2.9 and Perl 5.10. Output from "ruby script/about" is as follows:
About your application's environment
Ruby version 1.8.7 (x86_64-linux)
RubyGems version 1.2.0
Rails version 2.1.2
Active Record version 2.1.2
Action Pack version 2.1.2
Active Resource version 2.1.2
Action Mailer version 2.1.2
Active Support version 2.1.2
Edge Rails revision unknown
Application root /opt/redmine-0.8.5
Environment production
Database adapter mysql
Database schema version 101About your Redmine plugins
Mylyn Connector plugin 2.5.0.trunk
Scrumdashboard plugin 1.2
Charts Plugin 0.0.14
Redmine Burndown plugin 1.1.3
Redmine Task Board plugin 1.0.0
Redmine Hudson plugin 0.1.0
If you need any more information, please ask.
Files
Related issues
Updated by Johan De Meersman about 15 years ago
Bah, formatting fail. Here's the output from "ruby script/about" again:
About your application's environment Ruby version 1.8.7 (x86_64-linux) RubyGems version 1.2.0 Rails version 2.1.2 Active Record version 2.1.2 Action Pack version 2.1.2 Active Resource version 2.1.2 Action Mailer version 2.1.2 Active Support version 2.1.2 Edge Rails revision unknown Application root /opt/redmine-0.8.5 Environment production Database adapter mysql Database schema version 101 About your Redmine plugins Mylyn Connector plugin 2.5.0.trunk Scrumdashboard plugin 1.2 Charts Plugin 0.0.14 Redmine Burndown plugin 1.1.3 Redmine Task Board plugin 1.0.0 Redmine Hudson plugin 0.1.0
Updated by Jean-Philippe Lang about 15 years ago
The conclusion I draw from this, is that db_migrate either thinks it doesn't need to do anything, or fails silently when re-run on an installation where it's been run before but the database has been re-imported from a not-updated one. Given that the implementation scenario I've used is not that unreasonable or uncommon, this may be worth looking into, I think.
That's a really common scenario. I do it all the time and believe me, it works.
To see what is going wrong, I need your error stack trace.
Updated by Johan De Meersman about 15 years ago
What error stack trace ? The upgrade script gave no output. I can get you the logfile traces from before I added the database fields, but I don't see how those would help debugging what went wrong with the database upgrade ?
Updated by Jean-Philippe Lang about 15 years ago
However, we then started seeing internal server errors on some (but not all) repositories and Wiki pages.
These ones.
Updated by Johan De Meersman about 15 years ago
- File Wiki-orig.log Wiki-orig.log added
- File Repo-orig.log Repo-orig.log added
- File Wiki-new.log Wiki-new.log added
Oh, happily :-) The first two below are the ones from respectively Wiki and Repository that got solved according to the two links in the original report; the third one is a new one that popped up today when someone clicks a wiki-link to a page that doesn't exist yet (thus creating a new page).
Updated by Jean-Philippe Lang about 15 years ago
Have you (or someone else) ever added a file in db/migrate
? Eg. for a plugin or a patch (like this one: #1154 or #443).
Even if this file is no longer present, please mention it.
Updated by Johan De Meersman about 15 years ago
No, never. Funnily enough, both the issues you reference just gave me an internal error when I clicked them right now, loaded fine on refresh :-)
As I said, it's a fresh VM, with a fresh OS and Redmine install on it.
A number of plugins were installed, but none asked for files to be put in db/migrate, everything went in vendor/plugins. Here's the list:- redminy Mylin plugin from http://sourceforge.net/projects/redmin-mylyncon/
- Simple CI from http://www.redmine.org/wiki/redmine/PluginSimpleCI (later removed in favour of hudson)
- hudson from http://www.redmine.org/boards/3/topics/6650
- OpenFlashChart from http://github.com/pullmonkey/open_flash_chart (this did require some code editing in RAILS_ROOT/app/controllers/test_it_controller.rb)
- Scrumdashboard from http://www.redmine.org/boards/3/topics/5808
- Charts from http://github.com/mszczytowski/redmine_charts
- Redmine Task Board from http://github.com/scrumalliance/redmine_task_board
- Redmine Burndown from http://github.com/scrumalliance/redmine_burndown
Updated by Jean-Philippe Lang about 15 years ago
Are you able to post the dump (structure+data) of the table named schema_migrations
that you reimported in your fresh redmine install (before you ran db:migrate) ?
Updated by Johan De Meersman about 15 years ago
There is no such table, apparently. It was a Redmine 0.7, updated via SVN to revision 1518, dixit svn info.
Updated by Jean-Philippe Lang about 15 years ago
Then it must be schema_info
instead of schema_migrations
.
It's a Rails core table that was renamed in Rails 2.
Updated by Johan De Meersman about 15 years ago
Here it is. The only thing that seems to be in it, is the value '92'. The table also doesn't appear to have changed after the upgrade.
Updated by Jean-Philippe Lang about 15 years ago
This seems to be OK.
Honestly, I have no idea about what went wrong and I can't go further except trying the upgrade from your full database dump.
Updated by Johan De Meersman about 15 years ago
Not really an option at this point, I'm afraid :-) I'm gonna try the whole procedure again with a blank codebase and see where I end up. I'll keep you informed.
You wouldn't have a clue about http://www.redmine.org/boards/2/topics/2512 , would you ? :-)
Updated by Jean-Philippe Lang almost 15 years ago
- Category set to Database
Johan De Meersman wrote:
Not really an option at this point, I'm afraid :-)
I understand.
I'll try to do an upgrade from 0.7 r1518 to 0.8.5 release.
Updated by Jean-Philippe Lang almost 15 years ago
- Status changed from New to Closed
- Resolution set to Duplicate
Same as #1681.