I’m upgrading from 3.6.1 and although I could swear I got further than
this on a previous attempt, I am getting :
[Thu Mar 13 19:16:40 2014] [critical]: DBD::mysql::st execute failed:
Duplicate key name ‘CachedGroupMembers3’ at
/usr/share/request-tracker4/lib/RT/Handle.pm line 515.
(/usr/share/request-tracker4/lib/RT.pm:351)
DBD::mysql::st execute failed: Duplicate key name 'CachedGroupMembers3’
at /usr/share/request-tracker4/lib/RT/Handle.pm line 515.
during the setup-database --action upgrade
I am migrating from an old server to a new one running debian wheezy, rt
installed from packages.
I created an rt3 database on my new server with the latin character set,
dumped from the old to the new using the --default-character-set=binary
option, then when running the setup to get from 3.6.1 to 3.7.87 as
described in the documentation, I get the above error. This is an old
db, but I don’t think we ever set up a customer CachedGroupMembers3 as
described in some other posts. So I appear to bailing before getting to
the mysql db upgrade required.
The weirdest thing is that I got all the way to end of an upgrade on a
previous trial by doing the mysql upgrade first, fixing some errors via
mysql as supplied by Kevin, then running the setup-database from 3.6.1
to 4.0.7. However I am consistantly getting the Duplicate key error no
matter which way I try the upgrade.
I’m upgrading from 3.6.1 and although I could swear I got further than
this on a previous attempt, I am getting :
[Thu Mar 13 19:16:40 2014] [critical]: DBD::mysql::st execute failed:
Duplicate key name ‘CachedGroupMembers3’ at
/usr/share/request-tracker4/lib/RT/Handle.pm line 515.
(/usr/share/request-tracker4/lib/RT.pm:351)
DBD::mysql::st execute failed: Duplicate key name ‘CachedGroupMembers3’
at /usr/share/request-tracker4/lib/RT/Handle.pm line 515.
during the setup-database --action upgrade
I am migrating from an old server to a new one running debian wheezy, rt
installed from packages.
I created an rt3 database on my new server with the latin character set,
dumped from the old to the new using the --default-character-set=binary
option, then when running the setup to get from 3.6.1 to 3.7.87 as
described in the documentation, I get the above error. This is an old
db, but I don’t think we ever set up a customer CachedGroupMembers3 as
described in some other posts. So I appear to bailing before getting to
the mysql db upgrade required.
You can easily confirm that.
Drop the rt3 database on your new server.
Re-create it empty with rt-setup-database --action create,acl
Restore your backup.
Run ‘show indexes from CachedGroupMembers’ or ‘show create table
CachedGroupMembers’ and see if that index exists.
My assumption is that your backup doesn’t have DROP TABLE and you were
left with a corrupt restore.
-kevin