Hi,
I am curious if somebody already tried a mysql/postgres migration in RT 4.2.
From what I read in the docs the intended way to accomplish this task is to dump the mysql database using the rt-serializer command and importing the dump using rt-importer to a new instance.
In detail I would try the following:
apachectl stop; service fetchmaild stop
rt-validator --check && rt-serializer —clone --directory path/to/export/directory
making appropriate changes to RT_SiteConfig.pm (changing Database engine from mysql to pgsql)
rt-importer path/to/export/directory
apachectl start
checking if everything looks as before
service fetchmaild start
Am I missing something or should the migration basically work as described?
Regards,
Matthias
Matthias Peplow
IT Director
Scholz & Friends Berlin GmbH
Tel.: +49 30/70 01 86-532
Fax: +49 30/70 01 86-599
matthias.peplow@s-f.com
Litfaß-Platz 1
10178 Berlin
Germany
Scholz & Friends
The Orchestra of Ideas
Hi,
I am curious if somebody already tried a mysql/postgres migration in RT 4.2.
From what I read in the docs the intended way to accomplish this task is to dump the mysql database using the rt-serializer command and importing the dump using rt-importer to a new instance.
In detail I would try the following:
apachectl stop; service fetchmaild stop
rt-validator --check && rt-serializer —clone --directory path/to/export/directory
You may also need to rt-validator --check --resolve if it finds
anything.
making appropriate changes to RT_SiteConfig.pm (changing Database engine from mysql to pgsql)
rt-importer path/to/export/directory
apachectl start
checking if everything looks as before
service fetchmaild start
I’ve made a number of bug fixes which we are in the process of
merging. I suspect that the tip of 4.2 trunk and/or 4.2.2 will
perform better and deal with potentially bad data lurking in your
MySQL database better than the Migrator available in 4.2.1 right now.
We do have reports of people successfully running it, but you may run
into bugs I’ve already fixed.
-kevin