Project

General

Profile

Actions

Defect #4206

closed

Repeatedly running of db_migrate fails silently

Added by Johan De Meersman about 15 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Database
Target version:
-
Start date:
2009-11-12
Due date:
% Done:

0%

Estimated time:
Resolution:
Duplicate
Affected version:

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 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

If you need any more information, please ask.


Files

Wiki-orig.log (4.94 KB) Wiki-orig.log Original Wiki issue, happened as soon as clicking on the 'Wiki' tab Johan De Meersman, 2009-11-12 16:14
Repo-orig.log (9.55 KB) Repo-orig.log Repository issue, happened as soon as clicing on the 'Repository' tab, but not for all projects Johan De Meersman, 2009-11-12 16:14
Wiki-new.log (5.37 KB) Wiki-new.log New Wiki issue, happens when clicking on a wiki link to a nonexistant page Johan De Meersman, 2009-11-12 16:14
redmine.schema_info--0.7.dmp.bz2 (678 Bytes) redmine.schema_info--0.7.dmp.bz2 schema_info table from the old install, as imported into the new pre-upgradescript Johan De Meersman, 2009-11-17 16:39

Related issues

Is duplicate of Redmine - Defect #1681: NoMethodError in WikiController#indexClosed2008-07-24

Actions
Actions #1

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

Actions #2

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.

Actions #3

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 ?

Actions #4

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.

Actions #5

Updated by Johan De Meersman about 15 years ago

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).

Actions #6

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.

Actions #7

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:
Actions #8

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) ?

Actions #9

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.

Actions #10

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.

Actions #11

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.

Actions #12

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.

Actions #13

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 ? :-)

Actions #14

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.

Actions #15

Updated by Jean-Philippe Lang almost 15 years ago

  • Status changed from New to Closed
  • Resolution set to Duplicate

Same as #1681.

Actions

Also available in: Atom PDF