Re: Error on upgrade from 1.7.11 -- 2.0.12
Hi Christian, yes as we discussed this is a painful exercise, so I've decided to restore from last backup and start again. I have some what got it working, but the process was not easy at all. I had issues with mod_python still being used by apache and that reviewboard+apache+django no longer supports this made things worse for the upgrade. The way I got this working was: * upgrade from 1.7.11 to 2.12 on the restored database and put that DB to the side. * install a fresh installation of 2.12, work out the wsgi mess (disable mod_python etc) and get the default fresh install working with no errors. * point the new install to the upgraded database * reconfigure the paths in the reviewboard database using the admin module in RB to use the fresh install files and not the existing (which used mod_python) Thanks for the help, we are closer to bug free now. I have a new issue with sending emails on old reviews that I'll log as a new issue and see if anyone knows that it. Regards, Adam Driscoll On Thursday, 15 January 2015 18:17:29 UTC+11, Christian Hammond wrote: Hi Adam, Ouch, that's unfortunate. Killing the upgrade in the middle can cause real problems, as we have no way of tracking how many of the SQL statements were executed by the database at that point. It takes a good long while to sort out and to fix, depending on what changes were made and where it was interrupted. The good news is that it's unlikely anything was permanently damaged or any data was lost. Fixing this is generally doable with this type of corruption. The process looks very roughly like this: 1) Finding out exactly which changes exist in the database now that were added since 1.7.11 (on a per-SQL level). This generally means constructing 2.0.x and 1.7.11 databases on two separate installs and doing some analysis to determine the differences in schema, along with reading through the histories and sequences of all database migration files in the codebase. 2) Hand-reverting each of the SQL changes, potentially massaging the data back to a good state in the original schema. 3) Fixing the stored version number, so that the upgrade process is back to thinking it's upgrading a 1.7.11 instance. 4) Potentially lots of trial and error and repeated attempts as you work your way through, ensuring you have a backup at every single point. Hopefully the changes made weren't too substantial. Otherwise, additional surgery may be needed. We offer database interruption/corruption repair as part of support contracts, if your company would be interested in talking about one. Christian -- Christian Hammond - chri...@beanbaginc.com javascript: Review Board - https://www.reviewboard.org Beanbag, Inc. - https://www.beanbaginc.com -Original Message- From: Adam Driscoll adam.d...@gmail.com javascript: Reply: revie...@googlegroups.com javascript: revie...@googlegroups.com javascript: Date: January 14, 2015 at 11:03:56 PM To: revie...@googlegroups.com javascript: revie...@googlegroups.com javascript: Subject: Error on upgrade from 1.7.11 -- 2.0.12 Hi, I'm in the same position as this former post and need some advice. https://groups.google.com/forum/#!topic/reviewboard/9-v3mHJz0Ek My upgrade stalled halfway through the upgrade because of an invalid installation of a dependency. As I found that out by killing the upgrade and then using: rb-site manage /path/to/site list-evolutions I fixed the dependency issue, but now the database is corrupted. *upgrade command log:* * rb-site upgrade /var/www/reviews Rebuilding directory structure Updating database. This may take a while. The log output below, including warnings and errors, can be ignored unless upgrade fails. -- -- Creating tables ... There are unapplied evolutions for auth. There are unapplied evolutions for contenttypes. There are unapplied evolutions for accounts. There are unapplied evolutions for attachments. There are unapplied evolutions for changedescs. There are unapplied evolutions for diffviewer. There are unapplied evolutions for hostingsvcs. There are unapplied evolutions for reviews. There are unapplied evolutions for scmtools. There are unapplied evolutions for site. Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) CommandError: Error applying evolution: (1060, Duplicate column name 'permissions') ** Unfortunately I didn't backup the mysql database correctly before the upgrade and now have to move forward with the database in its current state. My other option is a restore from a backup 2 weeks ago however I lose all of the reviews
Error on upgrade from 1.7.11 -- 2.0.12
Hi,
I'm in the same position as this former post and need some advice.
https://groups.google.com/forum/#!topic/reviewboard/9-v3mHJz0Ek
My upgrade stalled halfway through the upgrade because of an invalid
installation of a dependency. As I found that out by killing the upgrade
and then using: rb-site manage /path/to/site list-evolutions
I fixed the dependency issue, but now the database is corrupted.
*upgrade command log:*
*
rb-site upgrade /var/www/reviews
Rebuilding directory structure
Updating database. This may take a while.
The log output below, including warnings and errors,
can be ignored unless upgrade fails.
-- begin log output --
Creating tables ...
There are unapplied evolutions for auth.
There are unapplied evolutions for contenttypes.
There are unapplied evolutions for accounts.
There are unapplied evolutions for attachments.
There are unapplied evolutions for changedescs.
There are unapplied evolutions for diffviewer.
There are unapplied evolutions for hostingsvcs.
There are unapplied evolutions for reviews.
There are unapplied evolutions for scmtools.
There are unapplied evolutions for site.
Project signature has changed - an evolution is required
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
CommandError: Error applying evolution: (1060, Duplicate column name
'permissions')
**
Unfortunately I didn't backup the mysql database correctly before the
upgrade and now have to move forward with the database in its current
state. My other option is a restore from a backup 2 weeks ago however I
lose all of the reviews that occurred since. I'm fingers crossed that the
database is salvageable as the upgrade stalled early in the process.
*More logs:Evolve --hints:*
rb-site manage /var/www/reviews evolve -- --hint
#- Evolution for auth
from django_evolution.mutations import ChangeMeta
MUTATIONS = [
ChangeMeta('Permission', 'unique_together', ((u'content_type',
u'codename'),))
]
#--
#- Evolution for contenttypes
from django_evolution.mutations import ChangeMeta
MUTATIONS = [
ChangeMeta('ContentType', 'unique_together', (('app_label', 'model'),))
]
#--
#- Evolution for accounts
from django_evolution.mutations import AddField, ChangeMeta, DeleteField
from django.db import models
from djblets.db.fields import JSONField
MUTATIONS = [
AddField('Profile', 'default_use_rich_text', models.NullBooleanField,
null=True),
AddField('Profile', 'should_send_email', models.BooleanField,
initial=True),
AddField('Profile', 'show_closed', models.BooleanField, initial=True),
AddField('Profile', 'should_send_own_updates', models.BooleanField,
initial=True),
DeleteField('Profile', 'show_submitted'),
ChangeMeta('ReviewRequestVisit', 'unique_together', ((u'user',
u'review_request'),)),
AddField('LocalSiteProfile', 'permissions', JSONField, null=True),
ChangeMeta('LocalSiteProfile', 'unique_together', ((u'user',
u'local_site'), (u'profile', u'local_site')))
]
#--
#- Evolution for attachments
from django_evolution.mutations import AddField, ChangeField
from django.db import models
MUTATIONS = [
AddField('FileAttachment', 'orig_filename', models.CharField,
max_length=256, null=True),
AddField('FileAttachment', 'added_in_filediff', models.ForeignKey,
null=True, related_model='diffviewer.FileDiff'),
AddField('FileAttachment', 'repository', models.ForeignKey, null=True,
related_model='scmtools.Repository'),
AddField('FileAttachment', 'repo_revision', models.CharField,
max_length=64, null=True, db_index=True),
AddField('FileAttachment', 'repo_path', models.CharField,
max_length=1024, null=True),
ChangeField('FileAttachment', 'file', initial=None, max_length=512)
]
#--
#- Evolution for changedescs
from django_evolution.mutations import AddField
from django.db import models
MUTATIONS = [
AddField('ChangeDescription', 'rich_text', models.BooleanField,
initial=False)
]
#--
#- Evolution for diffviewer
from django_evolution.mutations import AddField
from django.db import models
from djblets.db.fields import JSONField
MUTATIONS = [
AddField('DiffSet', 'base_commit_id', models.CharField, max_length=64,
null=True, db_index=True),
AddField('DiffSet', 'extra_data', JSONField, null=True),
AddField('FileDiffData', 'extra_data', JSONField, null=True),
AddField('DiffSetHistory', 'extra_data', JSONField, null=True),
AddField('FileDiff', 'extra_data', JSONField, null=True)
]
#--
#- Evolution for hostingsvcs
from django_evolution.mutations import ChangeMeta
MUTATIONS = [
ChangeMeta('HostingServiceAccount', 'unique_together', [])
]
#--
#- Evolution for reviews
from django_evolution.mutations import AddField, ChangeField,
Re: Error on upgrade from 1.7.11 -- 2.0.12
Hi Adam,
Ouch, that's unfortunate. Killing the upgrade in the middle can cause real
problems, as we have no way of tracking how many of the SQL statements were
executed by the database at that point. It takes a good long while to sort out
and to fix, depending on what changes were made and where it was interrupted.
The good news is that it's unlikely anything was permanently damaged or any
data was lost. Fixing this is generally doable with this type of corruption.
The process looks very roughly like this:
1) Finding out exactly which changes exist in the database now that were added
since 1.7.11 (on a per-SQL level). This generally means constructing 2.0.x and
1.7.11 databases on two separate installs and doing some analysis to determine
the differences in schema, along with reading through the histories and
sequences of all database migration files in the codebase.
2) Hand-reverting each of the SQL changes, potentially massaging the data back
to a good state in the original schema.
3) Fixing the stored version number, so that the upgrade process is back to
thinking it's upgrading a 1.7.11 instance.
4) Potentially lots of trial and error and repeated attempts as you work your
way through, ensuring you have a backup at every single point.
Hopefully the changes made weren't too substantial. Otherwise, additional
surgery may be needed.
We offer database interruption/corruption repair as part of support contracts,
if your company would be interested in talking about one.
Christian
--
Christian Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
-Original Message-
From: Adam Driscoll adam.drisc...@gmail.com
Reply: reviewboard@googlegroups.com reviewboard@googlegroups.com
Date: January 14, 2015 at 11:03:56 PM
To: reviewboard@googlegroups.com reviewboard@googlegroups.com
Subject: Error on upgrade from 1.7.11 -- 2.0.12
Hi,
I'm in the same position as this former post and need some advice.
https://groups.google.com/forum/#!topic/reviewboard/9-v3mHJz0Ek
My upgrade stalled halfway through the upgrade because of an invalid
installation of a dependency. As I found that out by killing the upgrade
and then using: rb-site manage /path/to/site list-evolutions
I fixed the dependency issue, but now the database is corrupted.
*upgrade command log:*
*
rb-site upgrade /var/www/reviews
Rebuilding directory structure
Updating database. This may take a while.
The log output below, including warnings and errors,
can be ignored unless upgrade fails.
-- --
Creating tables ...
There are unapplied evolutions for auth.
There are unapplied evolutions for contenttypes.
There are unapplied evolutions for accounts.
There are unapplied evolutions for attachments.
There are unapplied evolutions for changedescs.
There are unapplied evolutions for diffviewer.
There are unapplied evolutions for hostingsvcs.
There are unapplied evolutions for reviews.
There are unapplied evolutions for scmtools.
There are unapplied evolutions for site.
Project signature has changed - an evolution is required
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
CommandError: Error applying evolution: (1060, Duplicate column name
'permissions')
**
Unfortunately I didn't backup the mysql database correctly before the
upgrade and now have to move forward with the database in its current
state. My other option is a restore from a backup 2 weeks ago however I
lose all of the reviews that occurred since. I'm fingers crossed that the
database is salvageable as the upgrade stalled early in the process.
*More logs:Evolve --hints:*
rb-site manage /var/www/reviews evolve -- --hint
#- Evolution for auth
from django_evolution.mutations import ChangeMeta
MUTATIONS = [
ChangeMeta('Permission', 'unique_together', ((u'content_type',
u'codename'),))
]
#--
#- Evolution for contenttypes
from django_evolution.mutations import ChangeMeta
MUTATIONS = [
ChangeMeta('ContentType', 'unique_together', (('app_label', 'model'),))
]
#--
#- Evolution for accounts
from django_evolution.mutations import AddField, ChangeMeta, DeleteField
from django.db import models
from djblets.db.fields import JSONField
MUTATIONS = [
AddField('Profile', 'default_use_rich_text', models.NullBooleanField,
null=True),
AddField('Profile', 'should_send_email', models.BooleanField,
initial=True),
AddField('Profile', 'show_closed', models.BooleanField, initial=True),
AddField('Profile', 'should_send_own_updates', models.BooleanField,
initial=True),
DeleteField('Profile', 'show_submitted'),
ChangeMeta('ReviewRequestVisit', 'unique_together', ((u'user',
u'review_request'),)),
AddField('LocalSiteProfile', 'permissions
