RT 3.8.0 DB migrate to 4.0.5 - Errors Please help!

OK i’ve searched all over the Internet and I can’t seem to fix the problem.
Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
box and put it on VM. At the same time upgrade to the latest RT 4.0.5.

What I have done so far:

  • Got a backup of our DB in production using mysqldump
  • Created the brand new environment. Tried two different distros. Debian
    (Squeeze) was by far the easiest using all the tutorials and aptitude.
    Kernel 2.6.32-5-amd64 with RT 4.0.5 and mysql 5.1.61-0+squeeze1. Also
    created a Centos 6.2 (kernel 2.6.32-220.el6.x86_64) environment with RT
    4.0.5 and mySQL 5.1.61.
  • In both cases, RT 4.0.5 was working without any issues after the initial
    install. Then I deleted the “sample” DB, created a new empty db (rtdb) and
    imported the mySQL dump from production:

“mysql --max_allowed_packet=512M -u root -p rtdb < rt.sql”

After the import was complete, if i had a session open from before… i can
actually browse the RT site and see all my old information… cool. Then I
did the upgrade using the RT scripts. Since I am not migrating from prior
3.8.0 and I am not moving from mySQL 4.0 to 4.1, I do not need to apply the
mySQL scripts in the README. All i did after this import was:

“rt-setup-database --prompt-for-dba-password --action upgrade”

After a couple prompts (“current version” 3.8.0", etc) it did its upgrade
process. I didn’t get any errors… however i did get some warnings.
Something about if you’re not using something then don’t worry about it.

[Sat Jun 9 20:36:36 2012] [warning]: Going to add [OLD] prefix to all
templates in approvals queue. If you have never used approvals, you can
safely delete all the templates with the [OLD] prefix. Leave the new
Approval templates because you may eventually want to start using approvals.
(./etc/upgrade/3.8.2/content:3)
[Sat Jun 9 20:37:01 2012] [warning]: IMPORTANT: We’re going to delete all
scrips in Approvals queue and save them in ‘rt-approvals-scrips-cxYO’ file.
(./etc/upgrade/3.8.2/content:165)

[Sat Jun 9 20:37:30 2012] [warning]: Couldn’t set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)
[Sat Jun 9 20:37:30 2012] [warning]: Couldn’t set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)

The upgrade finished without a hitch. Now i see 26 tables in my DB (3.8.0,
there were 21). Now again, i can browse the RT site with my imported data.

Now the error…

When i restart the box… or even restart apache (httpd in Centos and apache2
in Debian)… i get weird errors.

Debian box (Squeeze):
root@rt-migrate:~# service apache2 restart
Restarting web server: apache2RT since version 3.8 has new schema for MySQL
versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:45 2012] [warning]: (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)
… waiting RT since version 3.8 has new schema for MySQL versions after
4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:48 2012] [warning]: (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)

Debian /var/log/apache/error.log

[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_startup_error
redefined at /usr/share/request-tracker4/libexec/rt-server line 240.
(/usr/share/request-tracker4/libexec/rt-server:240)
[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_bind_error redefined
at /usr/share/request-tracker4/libexec/rt-server line 252.
(/usr/share/request-tracker4/libexec/rt-server:252)
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 07:45:15 2012] [error] [client 10.2.66.131] Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.\n

If i browse to the server: http:///rt I get a 500 Internal Server
error.

CentOS box 6.2:
Restarting the httpd service doesn’t display any errors. Httpd looks like it
started correctly.

Centos /var/log/httpd/error.log
[Sat Jun 09 13:46:41 2012] [notice] Apache/2.2.15 (Unix) DAV/2
mod_fcgid/2.3.7 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured –
resuming normal operations
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Sat Jun 09 13:46:51 2012] [warn] [client x.x.x.x] (104)Connection reset by
peer: mod_fcgid: error reading data from FastCGI server
[Sat Jun 09 13:46:51 2012] [error] [client x.x.x.x] Premature end of script
headers: rt-server.fcgi

What does this error mean? I was doing some research and all i could find is
it was a permissions issue. I chmod 777 to this file… and also gave the
whole folder permission to apache:apache (user used to start httpd). Still i
get the same error. Also i was reading about Collation and character set.
Could this be the problem?

Please help! i’ve been banging my head trying to get this to work… and
possible it’s a simple fix… hopefully. I don’t care what distro we get
RT4.0.6 running on… just need to make sure i can successfully migrate the
old data over. Please help!!

Thanks!
-Frank
View this message in context: http://old.nabble.com/RT-3.8.0-DB-migrate-to-4.0.5---Errors-Please-help!-tp34001658p34001658.html

OK i’ve searched all over the Internet and I can’t seem to fix the problem.
Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
box and put it on VM. At the same time upgrade to the latest RT 4.0.5.

I’m about to go on holiday so I can’t respond fully but I went through
a similar process recently and had similar issues.

I treated the DB and the code separate. Upgraded the database but the
code I installed new and migrated everything to make sure it all
worked.

With the DB I did some test with just the schema so 3.8.0 (mysqldump
-d mydb) to 3.8.11 then 3.8.11 to 4.0.0, then each step
(4.0.1/4.0.2/4.0.3/4.0.4/4.0.5), I was being quite careful :slight_smile: I
then ran a tests with data. I also ran at stage 4.0.0
etc/upgrade/upgrade-articles, etc/upgrade/vulnerable-passwords --fix,
etc/upgrade/shrink_transactions_table.pl,
etc/upgrade/shrink_cgm_table.pl, at 4.0.1 sbin/rt-validator --fix,
4.0.2 sbin/rt-validator --resolve

Sorry for the dump, but that seemed to work for me on our 11GB DB.

-Kristian

Did the same thing, i used this guide as a base

but it didn’t dump and restore the DB, it was big and slow, so i just copy
the DB files
from Debian 5 server to a new (Virtual) Debian 6 server and fixed the DB
(you’ll get ERROR 1577 for MySQL)

ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by

Event Scheduler were found damaged at server start

You’ll need to run this command to fixit

sudo mysql_upgrade -u root -h localhost -p --verbose --force

then I created the ALTER SQL-Queries && Upgrade the DB schema

perl /opt/rt/rt-4.0.5/etc/upgrade/upgrade-mysql-schema.pl rt3-database

dbuser dbpassword > /opt/rt/queries.sql
mysql -u root -p rt3-database < /opt/rt/queries.sql

Rabin Yasharzadehe*On Tue, Jun 12, 2012 at 9:23 PM, FrankOh frank.oh@red.com wrote:

OK i’ve searched all over the Internet and I can’t seem to fix the problem.
Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
box and put it on VM. At the same time upgrade to the latest RT 4.0.5.

What I have done so far:

  • Got a backup of our DB in production using mysqldump
  • Created the brand new environment. Tried two different distros. Debian
    (Squeeze) was by far the easiest using all the tutorials and aptitude.
    Kernel 2.6.32-5-amd64 with RT 4.0.5 and mysql 5.1.61-0+squeeze1. Also
    created a Centos 6.2 (kernel 2.6.32-220.el6.x86_64) environment with RT
    4.0.5 and mySQL 5.1.61.
  • In both cases, RT 4.0.5 was working without any issues after the initial
    install. Then I deleted the “sample” DB, created a new empty db (rtdb) and
    imported the mySQL dump from production:

“mysql --max_allowed_packet=512M -u root -p rtdb < rt.sql”

After the import was complete, if i had a session open from before… i can
actually browse the RT site and see all my old information… cool. Then I
did the upgrade using the RT scripts. Since I am not migrating from prior
3.8.0 and I am not moving from mySQL 4.0 to 4.1, I do not need to apply the
mySQL scripts in the README. All i did after this import was:

“rt-setup-database --prompt-for-dba-password --action upgrade”

After a couple prompts (“current version” 3.8.0", etc) it did its upgrade
process. I didn’t get any errors… however i did get some warnings.
Something about if you’re not using something then don’t worry about it.

[Sat Jun 9 20:36:36 2012] [warning]: Going to add [OLD] prefix to all
templates in approvals queue. If you have never used approvals, you can
safely delete all the templates with the [OLD] prefix. Leave the new
Approval templates because you may eventually want to start using
approvals.
(./etc/upgrade/3.8.2/content:3)
[Sat Jun 9 20:37:01 2012] [warning]: IMPORTANT: We’re going to delete all
scrips in Approvals queue and save them in ‘rt-approvals-scrips-cxYO’ file.
(./etc/upgrade/3.8.2/content:165)

[Sat Jun 9 20:37:30 2012] [warning]: Couldn’t set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)
[Sat Jun 9 20:37:30 2012] [warning]: Couldn’t set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)

The upgrade finished without a hitch. Now i see 26 tables in my DB (3.8.0,
there were 21). Now again, i can browse the RT site with my imported data.

Now the error…

When i restart the box… or even restart apache (httpd in Centos and
apache2
in Debian)… i get weird errors.

Debian box (Squeeze):
root@rt-migrate:~# service apache2 restart
Restarting web server: apache2RT since version 3.8 has new schema for MySQL
versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:45 2012] [warning]: (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit:
(120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135
at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)
… waiting RT since version 3.8 has new schema for MySQL versions after
4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:48 2012] [warning]: (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit:
(120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135
at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)

Debian /var/log/apache/error.log

[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_startup_error
redefined at /usr/share/request-tracker4/libexec/rt-server line 240.
(/usr/share/request-tracker4/libexec/rt-server:240)
[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_bind_error
redefined
at /usr/share/request-tracker4/libexec/rt-server line 252.
(/usr/share/request-tracker4/libexec/rt-server:252)
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 07:45:15 2012] [error] [client 10.2.66.131] Error while
loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit:
(120000)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135
at
/usr/share/perl5/Plack/Util.pm line 156.\n

If i browse to the server: http:///rt I get a 500 Internal
Server
error.

CentOS box 6.2:
Restarting the httpd service doesn’t display any errors. Httpd looks like
it
started correctly.

Centos /var/log/httpd/error.log
[Sat Jun 09 13:46:41 2012] [notice] Apache/2.2.15 (Unix) DAV/2
mod_fcgid/2.3.7 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured –
resuming normal operations
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Sat Jun 09 13:46:51 2012] [warn] [client x.x.x.x] (104)Connection reset
by
peer: mod_fcgid: error reading data from FastCGI server
[Sat Jun 09 13:46:51 2012] [error] [client x.x.x.x] Premature end of
script
headers: rt-server.fcgi

What does this error mean? I was doing some research and all i could find
is
it was a permissions issue. I chmod 777 to this file… and also gave the
whole folder permission to apache:apache (user used to start httpd). Still
i
get the same error. Also i was reading about Collation and character set.
Could this be the problem?

Please help! i’ve been banging my head trying to get this to work… and
possible it’s a simple fix… hopefully. I don’t care what distro we get
RT4.0.6 running on… just need to make sure i can successfully migrate the
old data over. Please help!!

Thanks!
-Frank

View this message in context:
http://old.nabble.com/RT-3.8.0-DB-migrate-to-4.0.5---Errors-Please-help!-tp34001658p34001658.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.

Did the same thing, i used this guide as a base
Theresa Arzadon-Labajo

but it didn’t dump and restore the DB, it was big and slow, so i just copy
the DB files
from Debian 5 server to a new (Virtual) Debian 6 server and fixed the DB
(you’ll get ERROR 1577 for MySQL)

ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by

Event Scheduler were found damaged at server start

You’ll need to run this command to fixit

sudo mysql_upgrade -u root -h localhost -p --verbose --force

then I created the ALTER SQL-Queries && Upgrade the DB schema

perl /opt/rt/rt-4.0.5/etc/upgrade/upgrade-mysql-schema.pl rt3-database

dbuser dbpassword > /opt/rt/queries.sql
mysql -u root -p rt3-database < /opt/rt/queries.sql

This skips the really important ‘make upgrade-database’ command.
Without it, you will not have a correct RT4 database.

If the UPGRADING documentation that ships with RT is not sufficient,
we’ve also written up some of the common issues in a blog post a while
back:

-kevin