3.6 to 3.6.1 server migration

RT Users
1

Hi All,
I am planning our RT move from our pilot hardware to our production
hardware (fresh box just for RT :). I found a great article in the wiki
for the server migration
(Request Tracker Wiki ).

My question is about 3.6 and 3.6.1 though.

I believe I read there were some changes made to the database in 3.6.1,
is this change something I can change to my current 3.6 db and just put
it over on my new machine running 3.6.1? Or is it a change I’ll need to
“upgrade” to as suggested in the article?

Many thanks!

2

Hi All,
I am planning our RT move from our pilot hardware to our production
hardware (fresh box just for RT :). I found a great article in the wiki
for the server migration
(Request Tracker Wiki ).

My question is about 3.6 and 3.6.1 though.

I believe I read there were some changes made to the database in 3.6.1,
is this change something I can change to my current 3.6 db and just put
it over on my new machine running 3.6.1? Or is it a change I’ll need to
“upgrade” to as suggested in the article?

No database changes between 3.6.0 and 3.6.1.

-Todd

3

Todd,

Can I ask the same question about 3.5.5 → 3.6.0 (and hence 3.6.1)?

I have an RT 3.5.5 deployment that started out as a test but unfortunately
management got wind and liked what they saw way to much, now I am
pondering upgrading to the legitimate stable release.

Thanks.

BenR

Todd Chapman todd@chaka.net
Sent by: rt-users-bounces@lists.bestpractical.com
18/08/2006 11:48 PM

To
Helmuth Ramirez HelmuthRamirez@compupay.com
cc
rt-users@lists.bestpractical.com
Subject
Re: [rt-users] 3.6 to 3.6.1 server migrationOn Fri, Aug 18, 2006 at 08:58:03AM -0400, Helmuth Ramirez wrote:

Hi All,
I am planning our RT move from our pilot hardware to our production
hardware (fresh box just for RT :). I found a great article in the wiki
for the server migration
(Request Tracker Wiki ).

My question is about 3.6 and 3.6.1 though.

I believe I read there were some changes made to the database in 3.6.1,
is this change something I can change to my current 3.6 db and just put
it over on my new machine running 3.6.1? Or is it a change I’ll need to
“upgrade” to as suggested in the article?

No database changes between 3.6.0 and 3.6.1.

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

4

look into /etc/upgrade from the tar.gz file, there are the version inside
where you need to update the DB

torsten2006/8/18, Benjamin Robson ben.robson@classicblue.com.au:

Todd,

Can I ask the same question about 3.5.5 → 3.6.0 (and hence 3.6.1)?

I have an RT 3.5.5 deployment that started out as a test but unfortunately
management got wind and liked what they saw way to much, now I am pondering
upgrading to the legitimate stable release.

Thanks.

BenR

–

Todd Chapman todd@chaka.net
Sent by: rt-users-bounces@lists.bestpractical.com

18/08/2006 11:48 PM
To
Helmuth Ramirez HelmuthRamirez@compupay.com cc
rt-users@lists.bestpractical.com Subject
Re: [rt-users] 3.6 to 3.6.1 server migration

On Fri, Aug 18, 2006 at 08:58:03AM -0400, Helmuth Ramirez wrote:

Hi All,
I am planning our RT move from our pilot hardware to our production
hardware (fresh box just for RT :). I found a great article in the wiki
for the server migration
(Request Tracker Wiki ).

My question is about 3.6 and 3.6.1 though.

I believe I read there were some changes made to the database in 3.6.1,
is this change something I can change to my current 3.6 db and just put
it over on my new machine running 3.6.1? Or is it a change I’ll need to
“upgrade” to as suggested in the article?

No database changes between 3.6.0 and 3.6.1.

-Todd

The rt-users Archives

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

The rt-users Archives

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

MFG

Torsten Brumm

http://www.torsten-brumm.de

5

So would it be safe to say I can install a fresh copy of 3.6.1 on my new
box, drop the db, put the ‘old’ db on it and run it? Sorry about the
questions, just rather be safe than sorry.

CheersFrom: Todd Chapman [mailto:todd@chaka.net]
Sent: Friday, August 18, 2006 9:48 AM
To: Helmuth Ramirez
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] 3.6 to 3.6.1 server migration

Hi All,
I am planning our RT move from our pilot hardware to our production
hardware (fresh box just for RT :). I found a great article in the
wiki
for the server migration
(Request Tracker Wiki ).

My question is about 3.6 and 3.6.1 though.

I believe I read there were some changes made to the database in
3.6.1,
is this change something I can change to my current 3.6 db and just
put
it over on my new machine running 3.6.1? Or is it a change I’ll need
to
“upgrade” to as suggested in the article?

No database changes between 3.6.0 and 3.6.1.

-Todd

6

I wrote that srtciale actually … I’ve just done a 3.6.0 to 3.6.1
migration - there are no schema changes so all you need to do is a dump
and import, that’s it. Be aware that 3.6.1 needs a couple of extra Perl
modules though - do a “make testdeps” in the 3.6.1 tree to check for
these.

PK

7

Why will you drop the DB? Will you loose your data?

From my last migration, it was enough to do a make install and NO Make
Initialize-database.

Mit freundlichen Gruessen / With kindest regards

Torsten Brumm

Kuehne + Nagel
Ferdinand Strasse 29-33
20095 Hamburg
Germany

Tel: +49 40 329 15 199
Fax: +49 40 329 15 500
Www: www.kuehne-nagel.com

8

Thanks Philip for the tip and thanks for writing up that article! (I
would have never figured out that binary tip on the db dump!)-----Original Message-----
From: Philip Kime [mailto:pkime@Shopzilla.com]
Sent: Friday, August 18, 2006 12:03 PM
To: rt-users@lists.bestpractical.com; Helmuth Ramirez
Subject: Re: 3.6 to 3.6.1 server migration

I wrote that srtciale actually … I’ve just done a 3.6.0 to 3.6.1
migration - there are no schema changes so all you need to do is a dump
and import, that’s it. Be aware that 3.6.1 needs a couple of extra Perl
modules though - do a “make testdeps” in the 3.6.1 tree to check for
these.

PK

9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Fri, 18 Aug 2006 at 12:21 (-0400), Helmuth Ramirez wrote:

Thanks Philip for the tip and thanks for writing up that article! (I
would have never figured out that binary tip on the db dump!)

I’m planning to move from RT 3.4.2 on one machine to 3.4.5 on a different
machine with a different OS. I understand that there were no db changes
from 3.4.2 to 3.4.5, so I was hoping I could dump the mysql db on the
first system, restore it on the new machine and just point to it.

Now, this thread has me wondering about the whole issue of mysql dumps.
Do I need to use the ‘default binary’ option also, not only when I do my
conversion, but even on my current nightly db backups? First of all, is
it necessary, and secondly, is there a downside to using that option?

Thanks.

Mike

Mike Friedman IST/System and Network Security
mikef@berkeley.edu 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBROY1Ra0bf1iNr4mCEQJZpgCglE5NnYd0IWKOnnrOEPdH1mo2KfQAmwQF
UiKPRHj3upgqp/4k/hSDG7Bg
=RGPs
-----END PGP SIGNATURE-----

10

Mike Friedman wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Philip for the tip and thanks for writing up that article! (I
would have never figured out that binary tip on the db dump!)

I’m planning to move from RT 3.4.2 on one machine to 3.4.5 on a
different machine with a different OS. I understand that there were no
db changes from 3.4.2 to 3.4.5, so I was hoping I could dump the mysql
db on the first system, restore it on the new machine and just point to it.

Now, this thread has me wondering about the whole issue of mysql dumps.
Do I need to use the ‘default binary’ option also, not only when I do my
conversion, but even on my current nightly db backups? First of all, is
it necessary, and secondly, is there a downside to using that option?

Thanks.

Mike

Mike Friedman IST/System and Network Security
mikef@berkeley.edu 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBROY1Ra0bf1iNr4mCEQJZpgCglE5NnYd0IWKOnnrOEPdH1mo2KfQAmwQF
UiKPRHj3upgqp/4k/hSDG7Bg
=RGPs
-----END PGP SIGNATURE-----

The rt-users Archives

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

This is what I did when migrating from 3.0.9 to 3.6.1:

1: Set up the old version locally on my workstation (I use Red Hat WS 4
so it was an easy thing to do). If you are using Windows just install
RT to an intermediate server that you will use just for the migration
process.

2: We were using Postgres for our old setup so migrating involved using
the Postgres->MySQL script created by Jesse with some modifications.
However, it would appear that you are starting with a MySQL database.
So basically, all you need to do is create a dumpfile of the RT database
using mysqldump and copy it to the intermediate server.

3: Import the database dumpfile into your instance of the old RT version
you are migrating from on the intermediate server.

4: Install v3.6.1 with the ‘make upgrade’ build option using the
‘–with-rt-database=’ configure option pointing to the same database as
the old version.

5: Run all the scripts in the etc/upgrade directory of the untarred RT
directory (I’m not 100% on the name of that upgrade directory. It will
tell you what it is when ‘make upgrade’ is done). This will perform all
the upgrades on the database ultimately giving you a database with all
your old data but in a newer schema.

6: Create a dumpfile of the upgraded database using ‘mysqldump’ and copy
it to the new, permanent server.

7: After installing a fresh instance of v3.6.1, import the dumpfile you
created on the intermediate server using ‘mysql -u root -p < dumpfile’

8: Log into RT and enjoy that Perl-y goodness.

I hope that was clear enough and will help you out. Good luck!

Mathew Snyder

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mathew,

Actually, I’m planning just to go from 3.4.2 to 3.4.5, in part because the
database schema doesn’t change. (I’m actually going to install two RT
instances on the new machine, each pointing to a different database).

But my immediate question, in view of recent discussion on this list, is
about the mysqldump command. Is it really necessary to use the ‘default
binary’ option to keep binary attachments from being corrupted? And, if
so, then this applies to my current nightly dumps, not only to my upcoming
conversion, correct?

I haven’t seen any documentation on the ‘default binary’ option, which is
why I’m asking here. If I ever have to restore one of my current backups,
it would be nice to know that binary attachments weren’t corrupted.

So, should I change my current dumps to use the binary option?

Thanks.

MikeOn Fri, 18 Aug 2006 at 18:53 (-0400), Mathew Snyder wrote:

This is what I did when migrating from 3.0.9 to 3.6.1:

1: Set up the old version locally on my workstation (I use Red Hat WS 4 so it
was an easy thing to do). If you are using Windows just install RT to an
intermediate server that you will use just for the migration process.

2: We were using Postgres for our old setup so migrating involved using the
Postgres->MySQL script created by Jesse with some modifications. However, it
would appear that you are starting with a MySQL database. So basically, all
you need to do is create a dumpfile of the RT database using mysqldump and
copy it to the intermediate server.

3: Import the database dumpfile into your instance of the old RT version you
are migrating from on the intermediate server.

4: Install v3.6.1 with the ‘make upgrade’ build option using the
‘–with-rt-database=’ configure option pointing to the same database as the
old version.

5: Run all the scripts in the etc/upgrade directory of the untarred RT
directory (I’m not 100% on the name of that upgrade directory. It will tell
you what it is when ‘make upgrade’ is done). This will perform all the
upgrades on the database ultimately giving you a database with all your old
data but in a newer schema.

6: Create a dumpfile of the upgraded database using ‘mysqldump’ and copy it
to the new, permanent server.

7: After installing a fresh instance of v3.6.1, import the dumpfile you
created on the intermediate server using ‘mysql -u root -p < dumpfile’

8: Log into RT and enjoy that Perl-y goodness.

I hope that was clear enough and will help you out. Good luck!

Mathew Snyder

Mike Friedman IST/System and Network Security
mikef@berkeley.edu 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBROZP/a0bf1iNr4mCEQJv9gCg/iozFI5cicmUdcFHq26graWzNrYAn2zO
n2/J7MO54nzxmhSCbjsHlbL1
=WbtY
-----END PGP SIGNATURE-----

12

Mike Friedman wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mathew,

Actually, I’m planning just to go from 3.4.2 to 3.4.5, in part because
the database schema doesn’t change. (I’m actually going to install two
RT instances on the new machine, each pointing to a different database).

But my immediate question, in view of recent discussion on this list, is
about the mysqldump command. Is it really necessary to use the ‘default
binary’ option to keep binary attachments from being corrupted? And, if
so, then this applies to my current nightly dumps, not only to my
upcoming conversion, correct?

I haven’t seen any documentation on the ‘default binary’ option, which
is why I’m asking here. If I ever have to restore one of my current
backups, it would be nice to know that binary attachments weren’t
corrupted.

So, should I change my current dumps to use the binary option?

Thanks.

Mike

The only thing I could recommend is to try it both with and without the
option during your testing before actually doing the migration.

I didn’t know about the ‘default binary’ option when I did my migration
and as a result probably had to lose a few attachments that were causing
the data migration to error out. Instead I just uploaded them to our
internal online documentation.

Mathew

13

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Fri, 18 Aug 2006 at 19:55 (-0400), Mathew Snyder wrote:

I haven’t seen any documentation on the ‘default binary’ option, which
is why I’m asking here. If I ever have to restore one of my current
backups, it would be nice to know that binary attachments weren’t
corrupted.

So, should I change my current dumps to use the binary option?

The only thing I could recommend is to try it both with and without the
option during your testing before actually doing the migration.

Mathew,

I just tried specifying ‘–default-character-set=binary’, but this wasn’t
accepted. I got the following message instead of a dump:

Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]
For more options, use mysqldump --help

This is mysql 5.0.22-1 on Linux (Fedora (FC5)).

In the mysql manual, although I see the ‘–default-character-set’ option
documented, there’s no mention of ‘binary’ as a valid value. What am I
missing here?

Thanks.

Mike

Mike Friedman IST/System and Network Security
mikef@berkeley.edu 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBROnbua0bf1iNr4mCEQJaUQCgjj4+7Xheq9hfqq90EvNYnHOWiRwAoO2p
9i1HlqrsThxQf6QTdD6edUAW
=EzsR
-----END PGP SIGNATURE-----

14

taken from http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html:

–default-character-set=charset_name

Use charset_name as the default character set. See Section 5.11.1, �The
Character Set Used for Data and Sorting�. If not specified, mysqldump
uses utf8.

and

–character-sets-dir=path

The directory where character sets are installed. See Section 5.11.1,
�The Character Set Used for Data and Sorting�.

If you know where your character sets are stored simply use the latter
option and point mysqldump directly to it. The only thing I can think
of otherwise is that either binary isn’t actually a supported character
set or you don’t have it set as a configured option.

Mathew

Mike Friedman wrote: