Upgrade RT

What switches did you use to dump the mysql? I see few gotcha’s about

using binary characters
and separate dump for attachment table and stuff

OK, yes, I’ve just looked at an attachment to one of our tickets, and
yes, it’s corrupted. Bugger. So I’ve obviously missed something. I
thought that all one needed to do was to apply the mysql 4.0->4.1
patches at the appropriate point, but clearly something is wrong. Or
is it what you allude to above, and we need to do something smarter
when dumping the Attachment table? Can you give me some references to
where you’ve seen the gotchas?

OK, I’m now getting a bit concerned, because I’ve re-done my upgrade
procedure based on dumping with --default-charset=binary, but I’ve still got
a problem with corrupted attachments. I imagine there’s a huge amount of
past material on this list about this problem - are there any good summary
documents somewhere? The procedure I’m trying to follow is:

  1. mysqldump my RT 3.4.2 instance, which is running on a MySQL 4.1.11
    database (maybe this is my problem? Maybe I don’t need the 4.0->4.1 update
    at all?)

  2. Load that dump into a new MySQL 5.0 database on my new system

  3. Apply the 3.4.2 → 3.8.0 update

  4. Apply the MySQL 4.0->4.1 patch, if necessary (I’m now wondering whether
    it is, or whether applying it is actually causing the problem)

It completes after 918 mins with this error message

time mysql -u root -p rt3 < sql.queries

Enter password:
ERROR 1062 (23000) at line 210: Duplicate entry ‘’ for key 2

real 918m45.115s
user 0m0.088s
sys 0m0.072s

  1. Apply the 3.8.0 → 3.8.1 update

Any ideas?

Tim


The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited,
a charity registered in England with number 1021457 and acompany registered
in England with number 2742969, whose registeredoffice is 215 Euston Road,
London, NW1 2BE.

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Do I upgrade from RT 3.4.5 to RT 3.8.1 directly? Or there is a roadmap

somewhere?

You can do this in almost one go, yes. It’s almost exactly what I’m doing
with my production RT, where I’m going from 3.4.2 to 3.8.1

Do I upgrade the mysql 4.0.24 to 4.1 first before upgrading the RT?

Yes. Or at least, here’s what I’ve tested, and seems to work quite well:

  1. Set up a new RT box for your new server, so that you can always back
    out if this goes wrong. On this server, install the new version of MySQL
    you want to use, and install RT 3.8.1

  2. Make a dump of your production MySQL instance, and load it into the new
    MySQL database.

  3. Run the /opt/rt3/sbin/rt-setup-database --action upgrade command as
    detailed in the RT 3.8.1 README file, but only as far as version 3.8.0

  4. Run the MySQL upgrade script, as detailed in UPGRADING.mysql, and apply
    the SQL statements it wants you to make. This can take a long time; the
    alter table statements are pretty slow-running.

  5. Run the /opt/rt3/sbin/rt-setup-database --action upgrade thing again
    for the last small changes from 3.8.0 to 3.8.1

On my new server (not production yet) the upgrade is failing. I don’t want
to change the ACL on
the database unless that is harmless, to successfully upgrade

/opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-password
–action upgrade
In order to create or update your RT database, this script needs to connect
to your mysql instance on localhost as root
Please specify that user’s database password below. If the user has no
database
password, just press return.

Password:
Working with:
Type: mysql
Host: localhost
Name: rt3
User: rt_user
DBA: root
Enter RT version you’re upgrading from: 3.4.5

Going to apply following upgrades:

  • 3.5.1
  • 3.7.1
  • 3.7.3
  • 3.7.10
  • 3.7.15
  • 3.7.19
  • 3.7.81
  • 3.7.82
  • 3.7.85
  • 3.7.86
  • 3.7.87
  • 3.8.0
  • 3.8.1
  • 3.8.2

Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:

IT’S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 3.5.1
DBI connect(‘dbname=rt3;host=localhost’,‘rt_user’,…) failed: Access denied
for user ‘rt_user’@‘localhost’ (using password: YES) at
/opt/csw/share/perl/site_perl/DBIx/SearchBuilder/Handle.pm line 106
Connect Failed Access denied for user ‘rt_user’@‘localhost’ (using password:
YES)
at /opt/rt3/sbin/…/lib/RT.pm line 204

I can login OK with mysql -u root -p rt3' I failed to login with mysql -u rt_user -p rt3’ using the password I
have in RT_*Config.pm files (same) for rt_user

The same login attempt works on the original instance of RT (3.4.5)

After that, it all seemed to work pretty well.

Tim


The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited,
a charity registered in England with number 1021457 and acompany registered
in England with number 2742969, whose registeredoffice is 215 Euston Road,
London, NW1 2BE.

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Do I upgrade from RT 3.4.5 to RT 3.8.1 directly? Or there is a roadmap

somewhere?

You can do this in almost one go, yes. It’s almost exactly what I’m doing
with my production RT, where I’m going from 3.4.2 to 3.8.1

Do I upgrade the mysql 4.0.24 to 4.1 first before upgrading the RT?

Yes. Or at least, here’s what I’ve tested, and seems to work quite well:

  1. Set up a new RT box for your new server, so that you can always back
    out if this goes wrong. On this server, install the new version of MySQL
    you want to use, and install RT 3.8.1

  2. Make a dump of your production MySQL instance, and load it into the
    new MySQL database.

  3. Run the /opt/rt3/sbin/rt-setup-database --action upgrade command as
    detailed in the RT 3.8.1 README file, but only as far as version 3.8.0

  4. Run the MySQL upgrade script, as detailed in UPGRADING.mysql, and
    apply the SQL statements it wants you to make. This can take a long time;
    the alter table statements are pretty slow-running.

  5. Run the /opt/rt3/sbin/rt-setup-database --action upgrade thing again
    for the last small changes from 3.8.0 to 3.8.1

On my new server (not production yet) the upgrade is failing. I don’t want
to change the ACL on
the database unless that is harmless, to successfully upgrade

/opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-password
–action upgrade
In order to create or update your RT database, this script needs to connect
to your mysql instance on localhost as root
Please specify that user’s database password below. If the user has no
database
password, just press return.

Password:
Working with:
Type: mysql
Host: localhost
Name: rt3
User: rt_user
DBA: root
Enter RT version you’re upgrading from: 3.4.5

Going to apply following upgrades:

  • 3.5.1
  • 3.7.1
  • 3.7.3
  • 3.7.10
  • 3.7.15
  • 3.7.19
  • 3.7.81
  • 3.7.82
  • 3.7.85
  • 3.7.86
  • 3.7.87
  • 3.8.0
  • 3.8.1
  • 3.8.2

Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:

IT’S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 3.5.1
DBI connect(‘dbname=rt3;host=localhost’,‘rt_user’,…) failed: Access
denied for user ‘rt_user’@‘localhost’ (using password: YES) at
/opt/csw/share/perl/site_perl/DBIx/SearchBuilder/Handle.pm line 106
Connect Failed Access denied for user ‘rt_user’@‘localhost’ (using
password: YES)
at /opt/rt3/sbin/…/lib/RT.pm line 204

I can login OK with mysql -u root -p rt3' I failed to login with mysql -u rt_user -p rt3’ using the password I
have in RT_*Config.pm files (same) for rt_user

The same login attempt works on the original instance of RT (3.4.5)

I was experiencing this mysql priv table missing bug

http://bugs.mysql.com/bug.php?id=9934

I needed to run ‘mysql_fix_privilege_tables’ to fix it and then upgrade is
moving forward again

After that, it all seemed to work pretty well.

Tim


The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited,
a charity registered in England with number 1021457 and acompany registered
in England with number 2742969, whose registeredoffice is 215 Euston Road,
London, NW1 2BE.


Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Asif Iqbal wrote:

Going to apply following upgrades:

  • 3.5.1
  • 3.7.1
  • 3.7.3
  • 3.7.10
  • 3.7.15
  • 3.7.19
  • 3.7.81
  • 3.7.82
  • 3.7.85
  • 3.7.86
  • 3.7.87
  • 3.8.0
  • 3.8.1
  • 3.8.2

Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:

IT’S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 3.5.1
DBI connect(‘dbname=rt3;host=localhost’,‘rt_user’,…) failed: Access
denied for user ‘rt_user’@‘localhost’ (using password: YES) at
/opt/csw/share/perl/site_perl/DBIx/SearchBuilder/Handle.pm line 106
Connect Failed Access denied for user ‘rt_user’@‘localhost’ (using
password: YES)
at /opt/rt3/sbin/…/lib/RT.pm line 204

I can login OK with mysql -u root -p rt3' I failed to login with mysql -u rt_user -p rt3’ using the
password I have in RT_*Config.pm files (same) for rt_user

The same login attempt works on the original instance of RT (3.4.5)
If you are on mysql, you only want to upgrade to 3.8.0 on the first run
through, according to UPGRADING.mysql. The directions are pretty good
there. I just did a 3.6.5 to 3.8.2 upgrade following those instructions
and the only hitches were in local customizations.

Also, I use root for schema updates instead of rt_user and never have
problems.

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati

Ok now that upgrade completed on the test system, I now see 5000 more
tickets already
created on the production systems. Do I have to redo this whole thing? I
have binlog enabled
since the beginning of the original instance. How do I append those new 500
tickets?
I guess I am now on a catchup game :slight_smile:

You’re gonna have to shut down the production instance during the
conversion. No way around it. Stay late and bring pizza and beer :wink:

– ============================
Tom Lahti
BIT Statement LLC

(425)251-0833 x 117
http://www.bitstatement.net/
– ============================

I am looking for a way to use the binlogs to add the new tickets to the test
server

That way I don’t have to dump the whole database again and the import and
all that
from the beginning.

Can’t. The binlogs contain insert/update statements for a different schema.
If you tried to apply them to the new schema, they’d fail with SQL errors.

– ============================
Tom Lahti
BIT Statement LLC

(425)251-0833 x 117
http://www.bitstatement.net/
– ============================