RT-Users Digest, Vol 53, Issue 18

Date: Thu, 07 Aug 2008 16:50:47 +0200
From: Jean-Michel Barbet Jean-Michel.Barbet@subatech.in2p3.fr
Subject: Re: [rt-users] Rt at Glance and upgrade from 3.2.1 to 3.8.0
To: d tbsky tbskyd@gmail.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 489B0BC7.4060605@subatech.in2p3.fr
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

d tbsky wrote:

hi:
your upgrade procedure is like what i did, which is wrong.
if you use mysql, you should run the mysql upgrade script first,
then run the rt upgrade script. or you will get empty “RT at glance” page.

Thanks very much,

So, trying to follow directions posted in thread :
“RT at a Glance HASH ref error during upgrade from 3.4 to 3.8”,
I am reloading my RT 3.2.1/mysql 4.0.20 database in the new
RT 3.8.0/mysql 5.0.45. to do again the upgrade procedure.

If I understood well, steps are :

a) save DB on old server :

mysqldump -u rt_user -p xxx --single-transaction --databases rt3 > dump

b) reload DB on new server :

mysql -u root -p < dump

c) launch mysql upgrade script : etc/upgrade/schema.mysql-4.0-4.1.pl

d) update the schema (I suppose the best is with the following) :

/opt/rt3/sbin/rt-setup-database --dba root
–prompt-for-dba-password --action upgrade

Unfortunately the mysql upgrade script fails :

[root]# perl rt-3.8.0/etc/upgrade/schema.mysql-4.0-4.1.pl rt3 rt_user xxxxx
DBD::mysql::db column_info failed: column_info doesn’t support column
selection at rt-3.8.0/etc/upgrade/schema.mysql-4.0-4.1.pl line 227.
DBD::mysql::db column_info failed: column_info doesn’t support column
selection at rt-3.8.0/etc/upgrade/schema.mysql-4.0-4.1.pl line 227.

Also, I am not sure if I have to run this mysql update script …

I do not know what is the default Mysql character set in 4.0 and
I do not know how to set it in the new Mysql 5.0… The systems both
have locale set to en_US.UTF-8…

Thanks for advices.

JM

Like a previous reply mentioned, it has to do with the DBD::mysql 3.x
not supporting that method… the 4.x does work. I believe this issue is
addressed in the newer release candidates.

Also I would be cautious with 4.007, it apparently introduced a bug that
happens to a few people where the db connections timeout causing
mod_perl/fastcgi etc to seg fault on each dead connection until it
reconnects them. The cause of the bug i don’t know the details 100% (I
think broken keep-alive or something), but I basically downgraded back
to the Debian packaged 3.x for stability. I heard 4.006 doesn’t have the
issue though.

Curtis