Rt2-to-rt3 question

This is a dumb question, and it could be because I am doing this from
home, with a fever and a headache the size of Texas, but where is the
rt2 to rt3 database migration tool?

Actually, a better question would be: how does one migrate from RT2 to
RT3 (with regards to the database contents)?

Thanks!
-Rich

This is a dumb question, and it could be because I am doing this from
home, with a fever and a headache the size of Texas, but where is the rt2
to rt3 database migration tool?

http://bestpractical.com/pub/rt/devel/rt2-to-rt3-v1.7.tar.gz

Actually, a better question would be: how does one migrate from RT2 to
RT3 (with regards to the database contents)?

Since you’re at home with a fever and headache, you’ll find you have lots
of time on your hands. To migrate from rt2 to rt3 you’ll need that. The
process makes a dump of your current database into a metadata file and a
series of directories which contain about 1000 tickets per directory. The
exporting process goes fairly smoothly but at a glacier’s pace. It took
our system about 18 hours to export 60000 tickets + other configuration
data.

The importation process does not go as smoothly; I have pages of errors and
it fatally died about 12 hours in to the process when it suddenly noticed
that the rt3 instance had a queue already in existence as one it was trying
to import – my fault, I’m sure; you really need your rt3 database to be
empty for the process to work.

Total import time was about 28 hours – and this was on a test database,
non-live system and about 20000 less tickets than we have on our production
system. We won’t be migrating to rt3 anytime soon as a result, need to see
if the process can be sped up at all…unfortunately, for us, rt3 is
significantly slower than rt2 at the point that my users notice most:
initial login and presentation of their “home” page summary of
tickets…indeed, it is so slow that Safari times out (sixty seconds) and
generates an error.

Anyway, the conversion tool is at the url above and should get you going…

Good luck,

Scott

Total import time was about 28 hours – and this was on a test database,
non-live system and about 20000 less tickets than we have on our production
system. We won’t be migrating to rt3 anytime soon as a result, need to see
if the process can be sped up at all…

There’s a reason the importer has an “incremental mode” that lets you do
a full import from rt2 to rt3 without turning off your rt2 system and
then doing an “incremental import” of only users and tickets that have
changed since the date you specify. In the case of a high volume
system, I could see the need for an incremental import or maybe even a
second incremental import for huge systems, but there’s no reason you
should need to much actual downtime for a migration.

unfortunately, for us, rt3 is
significantly slower than rt2 at the point that my users notice most:
initial login and presentation of their “home” page summary of
tickets…indeed, it is so slow that Safari times out (sixty seconds) and
generates an error.

I presume you have tuned your MySQL 4 instance to use an apropriate
amount of RAM for your database size but that you’ve not had local staff
do any profiling to see just what is bogging down there. Feedback
there would be rather useful.

Best,
Jesse

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

hmm, I could be in big trouble.

mysql> select count() from Tickets;
| count(
) |
| 528340 |
1 row in set (0.70 sec)

mysql>

Matthew Watson schrieb:

hmm, I could be in big trouble.
mysql> select count() from Tickets;
±---------+
| count(
) |
±---------+
| 528340 |
±---------+
1 row in set (0.70 sec)

The exporting process goes fairly smoothly but at a glacier’s pace. It
took our system about 18 hours to export 60000 tickets + other
configuration data.

Ha! Finally a number to my taste.
We didn’t switch from rt-1.7 to rt2/rt3 yet because of performance
reasons with ~400000 tickets.

Could you please tell us if run-time performance is now acceptable with
rt3 and such a number.

I don’t care that much for some days to wait to convert the data, we
also needed some days to import and index the ripe data.

rt:~ > mysql -uroot -p -e’select count() from each_req’ rt
| count(
) |
| 430273 |
rt:~ > mysql -uroot -p -e’select count() from transactions’ rt
| count(
) |
| 1618402 |
Reini Urban - Programmer - http://inode.at