-----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
==================================================================================
On 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
[EMAIL PROTECTED] 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://socrates.berkeley.edu/~mikef http://security.berkeley.edu
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBROZP/a0bf1iNr4mCEQJv9gCg/iozFI5cicmUdcFHq26graWzNrYAn2zO
n2/J7MO54nzxmhSCbjsHlbL1
=WbtY
-----END PGP SIGNATURE-----
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
