Craig,
It is both feasible and dangerous. Good to hear you plan to put it
through a couple of QA cycles (you will need them), but this can be
accomplished. With a planned downtime window of an hour, I migrated a
couple of terabytes from 4.0 to 5.0 a couple years back while making
numerous schema changes along the way using a similar slave-driven,
process-as-much-as-you-can-in-advance plan. It was excruciating, but
we pulled it off.
- michael dykman
On Tue, Mar 24, 2009 at 9:38 AM, Craig Dunn <lists@stripped> wrote:
> Baron Schwartz wrote:
>>
>> If you can't take downtime, I'd go the slave route.
>>
>> You should certainly test your application to make sure 5.1's
>> differences (data types, syntax, etc) don't cause problems. Otherwise
>> you're risking getting badly stuck and having to downgrade to 4.1
>> again in a crisis.
>>
>> If you dump and reload, you don't need to go to 5.0 first. That is
>> only for in-place upgrades with mysql_upgrade, which I would not do
>> anyway because of the file format changes. I would dump and reload.
>>
>
> Sorry I wasn't very clear there - testing will all be done in a QA
> environment before anything is cut over, what I'm after is a way of
> switching from 4.1 to 5.1 as quickly as possible when we come to do the live
> stuff. Looks like replication may work from what you are saying.
>
> Cheers
>
> Craig
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>
>
--
- michael dykman
- mdykman@stripped
- All models are wrong. Some models are useful.
