RT3 (solaris) to RT4(linux)

Hi

I am looking for suggestions on upgrading rt3(solaris sparc) to rt4(ubuntu
linux).

rt3:

OS: solaris 10 sparc on T1000
Mysql: 5.0.75
Total number # Transactions: 6 million+

rt4:
OS: ubuntu linux precise
Mysql; 5,5

What would be recommended way to break down the upgrade and proceed?

I am guessing rsync mysql data and /opt/rt3 configs over to

mysql 5.5 (apt) and /opt/rt4.0.6.x (tarball)

and then follow the upgrade instruction on /opt/rt4 (tarball).

Please advise.

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?

Hi

I am looking for suggestions on upgrading rt3(solaris sparc) to rt4(ubuntu
linux).

rt3:

rt3: 3.8.2

OS: solaris 10 sparc on T1000

Mysql: 5.0.75
Total number # Transactions: 6 million+

rt4:
OS: ubuntu linux precise
Mysql; 5,5

What would be recommended way to break down the upgrade and proceed?

I am guessing rsync mysql data and /opt/rt3 configs over to

mysql 5.5 (apt) and /opt/rt4.0.6.x (tarball)

and then follow the upgrade instruction on /opt/rt4 (tarball).

Please advise.


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?

Hi

I am looking for suggestions on upgrading rt3(solaris sparc) to
rt4(ubuntu linux).

rt3:

rt3: 3.8.2

OS: solaris 10 sparc on T1000

Mysql: 5.0.75
Total number # Transactions: 6 million+

rt4:
OS: ubuntu linux precise
Mysql; 5,5

What would be recommended way to break down the upgrade and proceed?

I am guessing rsync mysql data and /opt/rt3 configs over to

mysql 5.5 (apt) and /opt/rt4.0.6.x (tarball)

and then follow the upgrade instruction on /opt/rt4 (tarball).

Please advise.

I like to do a test migration. How do I start with 600 newest tickets
instead of doing
a migration test with all 1 million+ tickets?


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

I like to do a test migration. How do I start with 600 newest tickets
instead of doing
a migration test with all 1 million+ tickets?

Your test migration really should use all your data so you know how long
it’ll take, what the downtime will be, and so you can sanity check that
the oldest data migrates over OK.

I like to do a test migration. How do I start with 600 newest tickets
instead of doing
a migration test with all 1 million+ tickets?

Your test migration really should use all your data so you know how long
it’ll take, what the downtime will be, and so you can sanity check that
the oldest data migrates over OK.

I’d break the migration into pieces, and do it in sections.

  1. Migrate the database from HP-UX to Linux, using the same version of MySQL you’re currently using. Dump and restore is safest, but you can do it more quickly by shutting down the database and copying the table files to an identically configured MySQL instance on the new machine (at least, identically configured as far as InnoDB settings are concerned).

  2. If you’re happy the new database looks good, reconfigure your HP-UX RT web service to talk to the copy of the database on the Linux server.

  3. Now, set up a new RT web server, running the same version of RT as you’re currently using, on the Linux server (or a separate one, if you’re keeping them separate - I have the web server and db on separate VMs, but that’s up to you).

  4. Test the new web server to check it’s working.

  5. At this point, upgrade the new database server’s MySQL version, taking note of the UPGRADING.mysql document that comes with RT to check that there are no gotchas that you might have to deal with.

  6. Test the new web interface again.

You can do all the above as a trial run, without affecting your production server. If you’re going to do the real switchover, you will have to block access to your RT by both web and mail while you perform the migration, so that you don’t lose any incoming tickets during the transition.

  1. Once you’re sure it’s working, you can adjust your web front ends and mail delivery setups to deliver production traffic to the new web server.

The above is the procedure I followed for migrating our service from Debian Lenny to Ubuntu Lucid. I haven’t migrated to Precise yet.

Regards,

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.