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
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover 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.1Do 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:
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.1Make a dump of your production MySQL instance, and load it into the new
MySQL database.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.0Run 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.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 
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 gameYou’re gonna have to shut down the production instance during the
conversion. No way around it. Stay late and bring pizza and beer
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 gameYou’re gonna have to shut down the production instance during the
conversion. No way around it. Stay late and bring pizza and beerI am looking for a way to use the binlogs to add the new tickets to
the test
serverThat 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:
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
Make a dump of your production MySQL instance, and load it into
the new MySQL database.
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
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.
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.1Do 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:
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.1Make 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.
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.0Run 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.Run the /opt/rt3/sbin/rt-setup-database --action upgrade thing again for
the last small changes from 3.8.0 to 3.8.1After 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 stuffOK, 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 stuffOK, 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:
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?)
Load that dump into a new MySQL 5.0 database on my new system
Apply the 3.4.2 → 3.8.0 update
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)
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 stuffOK, 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:
- 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.
- Load that dump into a new MySQL 5.0 database on my new system
using binary character set again to avoid conversion.
Apply the 3.4.2 → 3.8.0 update
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.
- 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?
- 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
Apply the 3.4.2 → 3.8.0 update
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.
- 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 stuffI 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 | gzipbackup.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
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
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 stuffI 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 | gzipbackup.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 stuffI 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 |
gzipbackup.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 stuffOK, 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:
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?)Load that dump into a new MySQL 5.0 database on my new system
My dump import is failing
ERROR 1050 (42S01) at line 19: Table ‘columns_priv’ already exists
Apply the 3.4.2 → 3.8.0 update
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)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
