Upgrade RT

Hi All

Here is my current setup for RT

RT 3.4.5
Perl 5.8.6
DBIx::SearchBuilder 1.40
Apache 1.3.33
mod_perl 2.8.22
OpenSSL 0.9.7g
mysqld Ver 4.0.24-log for pc-solaris2.10 on i386 (Source distribution)

I like to upgrade it to latest RT.

Is there a path I can follow? Do I also need to upgrade mysql?

Thanks

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

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

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

It looks complicated w/o a roadmap.

I am using RT in production environmentOn Fri, Nov 14, 2008 at 5:04 PM, Asif Iqbal vadud3@gmail.com wrote:

Hi All

Here is my current setup for RT

RT 3.4.5
Perl 5.8.6
DBIx::SearchBuilder 1.40
Apache 1.3.33
mod_perl 2.8.22
OpenSSL 0.9.7g
mysqld Ver 4.0.24-log for pc-solaris2.10 on i386 (Source distribution)

I like to upgrade it to latest RT.

Is there a path I can follow? Do I also need to upgrade mysql?

Thanks


Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

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

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

Upgrade of mysql is not required, but mysql 4.0.x is not supported
anymore by mysql development team. However, mysql 4.1 is not good
target as well. Use mysql 5.0.X where X is greater than 45. Don’t use
5.1 for a while, it has some known performance issues.

As it’s been mentioned by Tim you’ll have to follow UPGRADING.mysql
doc if you’re going to upgrade mysql server by the way.

It looks complicated w/o a roadmap.

I am using RT in production environment

Hi All

Here is my current setup for RT

RT 3.4.5
Perl 5.8.6
DBIx::SearchBuilder 1.40
Apache 1.3.33
mod_perl 2.8.22
OpenSSL 0.9.7g
mysqld Ver 4.0.24-log for pc-solaris2.10 on i386 (Source distribution)

I like to upgrade it to latest RT.

Is there a path I can follow? Do I also need to upgrade mysql?

Thanks


Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu


Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

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

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:

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?

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:

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.


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

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

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?

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:

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.

There’s no simple way to do that because the schema has changed, so
your binary logs can’t be applied to the new server. When I updated
our RT I did what the last person suggested; shut down the production
RT, dump, load, upgrade, bring up new production RT.

Tim

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

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

After that, it all seemed to work pretty well.

Tim

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

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

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

MySQL database.

  1. 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

  2. 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.

  3. 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

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

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

I haven’t tested the attachments thoroughly yet, so I don’t know
whether it worked. I just used one of our regular backup dumps, which
isn’t massively complicated. Our RT instance is replicated, and we
back up off the slave using:

mysqldump --defaults-extra-file=/mysql/data_3307/slave.cnf --single-
transaction --flush-logs --master-data=2 --all-databases -q | gzip >
backup.gz

Are there particular attachment types I should look for to check
whether things are working?

Tim

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

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?

Tim

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

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?

Answered my own question. About to test again using --default-
character-set=binary and see whether that fixes things.

Tim

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

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)

  5. Apply the 3.8.0 -> 3.8.1 update

Any ideas?

Tim

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

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?)
    As you’re on mysql 4.1.x and RT older than 3.8 then you should
    dump/load data using binary character set to avoid any data
    conversions.
  1. Load that dump into a new MySQL 5.0 database on my new system
    using binary character set again to avoid conversion.
  1. Apply the 3.4.2 -> 3.8.0 update

  2. 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)
    You must do it.

  1. Apply the 3.8.0 -> 3.8.1 update

Any ideas?

Tim

Best regards, Ruslan.

Thanks very much, Ruslan.

As you’re on mysql 4.1.x and RT older than 3.8 then you should
dump/load data using binary character set to avoid any data
conversions.

OK, so that’s:

mysqldump --default-character-set=binary … > dump.sql

yes?

  1. Load that dump into a new MySQL 5.0 database on my new system
    using binary character set again to avoid conversion.

so when I run the SQL back through mysql, I should again do:

mysql --default-character-set=binary rtdb < dump.sql

  1. Apply the 3.4.2 -> 3.8.0 update

  2. 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)
    You must do it.

OK, good.

  1. Apply the 3.8.0 -> 3.8.1 update

So, I’ve now done the above procedure again, using --default-character-
set=binary, and I still seem to have the problem with corrupted
attachments, so I’m still missing something.

I think the difficulty here is that I don’t know at what stage in this
process I’m doing the damage.

Tim

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

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

I haven’t tested the attachments thoroughly yet, so I don’t know whether it
worked. I just used one of our regular backup dumps, which isn’t massively
complicated. Our RT instance is replicated, and we back up off the slave
using:

mysqldump --defaults-extra-file=/mysql/data_3307/slave.cnf
–single-transaction --flush-logs --master-data=2 --all-databases -q | gzip

backup.gz

How do I do the mysqldump w/o locking ?

Are there particular attachment types I should look for to check whether
things are working?

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?

Good morning/afternoon/evening :slight_smile:

I have some questions about the time worked field and tickets by mail.
Here is a brief rundown of how tickets work after regular business
hours.

Call comes in and is transferred to After-hour support

After-hours support has their own in-house (non-RT) ticketing
solution. IF a ticket is escalated to level 2 support, their system
shoots off an email which is received by my RT system. It looks
something like this:

Owner: afterhours-support
Status: stalled
Requestor: john_smith@yahoo.com
Queue: AfterHours
TimeWorked: 00:14:06
RealName - John Smith
HomePhone - 360-555-1212
City - CityName
State - State
Password - None
Problem - Caller is having a problem with his email in which he is
unable to send or receive
Solution - We checked all of his email settings and they are correct.
Customer is having a hard time following directions, this is his first
computer. We checked his firewall settings. They looked ok. We tried
turning off Norton Firewall and email scanning as this will normally
fix the issue. This did not fix the issue. Escalating.

All the fields get set as they should except for TimeWorked. I tried
to do it multiple ways, but unsuccessfully. I need to be able to have
the exact time as well, Hours:Minutes:Seconds. Is this possible to do,
and if so would someone be willing to explain to me how to do it :slight_smile:

Thanks in Advance for any help,

Greg Evans
gevans@hcc.net
Hood Canal Communications

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

I haven’t tested the attachments thoroughly yet, so I don’t know
whether it
worked. I just used one of our regular backup dumps, which isn’t
massively
complicated. Our RT instance is replicated, and we back up off the
slave
using:

mysqldump --defaults-extra-file=/mysql/data_3307/slave.cnf
–single-transaction --flush-logs --master-data=2 --all-databases -
q | gzip

backup.gz

How do I do the mysqldump w/o locking ?

You can’t. Not if you want a guaranteed consistent backup, anyway.

Tim

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

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

I haven’t tested the attachments thoroughly yet, so I don’t know whether
it
worked. I just used one of our regular backup dumps, which isn’t
massively
complicated. Our RT instance is replicated, and we back up off the slave
using:

mysqldump --defaults-extra-file=/mysql/data_3307/slave.cnf
–single-transaction --flush-logs --master-data=2 --all-databases -q |
gzip

backup.gz

How do I do the mysqldump w/o locking ?

You can’t. Not if you want a guaranteed consistent backup, anyway.

Actually the --master-data and --single-transaction make sure the tables are
not locked

“The --master-datahttp://dev.mysql.com/doc/refman/4.1/en/mysqldump.html#option_mysqldump_master-dataoption
automatically turns off
–lock-tableshttp://dev.mysql.com/doc/refman/4.1/en/mysqldump.html#option_mysqldump_lock-tables.
It also turns on
–lock-all-tableshttp://dev.mysql.com/doc/refman/4.1/en/mysqldump.html#option_mysqldump_lock-all-tables,
unless --single-transactionhttp://dev.mysql.com/doc/refman/4.1/en/mysqldump.html#option_mysqldump_single-transactionalso
is specified

Plus it took me less than 14 mins to dump about 8G data

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?

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

My dump import is failing

mysql --default-character-set=binary < dump.sql

ERROR 1050 (42S01) at line 19: Table ‘columns_priv’ already exists

  1. Apply the 3.4.2 -> 3.8.0 update

  2. 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)

  3. 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?

Asif, it’s getting really hard to tell whose writing what with the way you
are quoting/replying to emails. It sounds like you are trying to not only
upgrade RT but also move your database from mysql 4.x.x to 5.x.x.

I would start by getting your current RT database dumped and successfully
moved to the 5.x.x system first:

mysqldump --opt --single-transaction > rt3.sql

Create the database on the new 5.x.x server, but don’t create any tables,
etc. Then import the dump:

mysql < rt3.sql

The way you are currently doing it is failing because the database and
tables already exist in the new 5.x.x system and your dump does not contain
the ‘drop table if exists’ syntax. A lot of the issue here is mysql
administration and I’d advise you to consult the mysql support site for
syntax for dumping, restoring, etc.

Once the above is done, you can then follow the instructions in the RT
upgrade documentation to get from 3.4.x to 3.8.2.

Yes, you will need to apply the ‘MySQL 4.0->4.1 schema changes’. It’s not
a patch, but a boatload of schema changes. The first part of the operation
only dumps the sql syntax to a file. You’ve then got to apply those sql
commands to the actual database.

The ‘UPGRADING.mysql’ document covers this in detail.

Good luck.

James Moseley