Migration to rt3 ... final episode

Migration to rt3 from rt2 is finally under way, but before I get all my
fingers burnt,
I thought I would write down the proposed procedure and have other
people have
a poke at it. Here it goes.

Step 1:

Two rt3 machines will be setup, but only one of them will be used in
production.
Both machines are going to be redhat 9 servers, with the following
installed:
rt 3 (3.0.7_1)
apache 2 (2.0.40-21.5)
mod_perl 2 (1.99_09-10 custom built)
DBIx Search builder (0.93_1)
Storable (>=2.0.8)

The difference will be one will have Pg 7.4.0-5PGDG, and the other Mysql
4.0.16-1.
On the two machnines, new tickets will have starting number of 200 000.

Step 2:

On the current rt2, stop the web and mail servers, export tickets. This
will probably take
half a day, so I will be done after hours. When the export is completed,
the mail server
will be restarted.

Step 3:

The export tickets (dump), will be import into the two rt3 servers in
reverse order of tickets.
(rt2-to-rt3 1.20 has been modified to load tickets in reverse order, so
that the newest tickets
are loaded first.) This will likely take about 5 days, so it will be
started Saturday morning.
The import will then be verified on both machines, and the two will then
be benchmarked.
The faster of the two, will become the new rt.

Step 4:
Decomission the old rt, and start on the new one.

Does this seem feasible? Are there any other pittfalls that I should be
on the look out for?
Is it possible to configure rt to start new tickets from 200 000?
How can I configure mysql and pg for the best perfomance using the
hardware availabe:

Machine specs:

Machine 1
72.8 GB HD ( 1GB swap, 22 GB /, 22 GB /var, 22 GB free)
Dual Pentium III (Coppermine) 933MHz
1 Gig Ram

Machine 2
145.6 GB (1 GB swap ,45GB /, 45GB /var, 45GB free)
Quad Pentium III (Cascades) 700 MHz
512 MB Ram

Ideally, I would have like to have the same hardware specs, but these
will have to do.

Stefan Seiz wrote:>On 10.12.2003 9:37 Uhr, mixo mixo@coza.net.za wrote:

Step 3:

The export tickets (dump), will be import into the two rt3 servers in
reverse order of tickets.
(rt2-to-rt3 1.20 has been modified to load tickets in reverse order, so
that the newest tickets
are loaded first.) This will likely take about 5 days, so it will be
started Saturday morning.
The import will then be verified on both machines, and the two will then
be benchmarked.
The faster of the two, will become the new rt.

Step 4:
Decomission the old rt, and start on the new one.

Well, first glimpse i’d say you’d loose all tickets created on the rt2
machine while you do the benchmarks on the rt3 machines.

Peherps I should have machine that for the benchmarks, I will be using
Apache Jmeter
(Apache JMeter - Apache JMeter™) which wont wipe out data,
but will work with
the existing data.

My suggestions:

You are aware of the issues around Apache2/mod_perl2/RH9, right?

Do the evaluation before your production switch, not during. Sounds
like you have a big installation and you want to minimize down time.
You are taking on more risk this way as well. (What happens if you get
stuck?)

If performance matters enough to do a test, do a fair comparison. That
means two installs on the same hardware. That also means taking the
time to tune both databases. Neither one is appropriately tuned out of
the box. I know that postgres performance can increase significantly; I
suspect mysql can also.

You might want to throw more than just performance into your database
evaluation. Do you have equivalent expertise in both? Do you have
other database instances already? Do you believe them both to be equal
in terms of features that matter? Equal quality?

If you have both machines at your disposal, consider (strongly) the
option of using both in production; one as a dedicated database machine
and one as the web server. Make the bigger one the database server; the
more memory you can give it the faster the overall system will be. 512
is almost certainly not enough. I think I would put the gig of memory
in the quad machine and make it the db server…

Jim Rowan wrote:

My suggestions:

You are aware of the issues around Apache2/mod_perl2/RH9, right?

Right

Do the evaluation before your production switch, not during.

Thats the plan.

Sounds
like you have a big installation and you want to minimize down time.
You are taking on more risk this way as well. (What happens if you get
stuck?)

The process is started again, the following long weekend. The one thing
that could get us stuck is the import
failing for what ever reason, so down should remain at the minimun
during the next try.

If performance matters enough to do a test, do a fair comparison. That
means two installs on the same hardware.

This has been done already on the dual machines, and unfortunately there
isn’t another spare quad. “mysql” was faster.

That also means taking the
time to tune both databases. Neither one is appropriately tuned out of
the box. I know that postgres performance can increase significantly; I
suspect mysql can also.

What recommendations would you make for postgres (or mysql) considering
the hardware specs?

You might want to throw more than just performance into your database
evaluation. Do you have equivalent expertise in both? Do you have
other database instances already? Do you believe them both to be equal
in terms of features that matter? Equal quality?

If you have both machines at your disposal, consider (strongly) the
option of using both in production; one as a dedicated database machine
and one as the web server. Make the bigger one the database server; the
more memory you can give it the faster the overall system will be. 512
is almost certainly not enough. I think I would put the gig of memory
in the quad machine and make it the db server…

More memory is a possible. I would like to add that having an
additional rt instance means that we have backup
in case the one fails during the data import. Testing of perfomance is
not a must, but its a good (but expensive)
exercise.