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 <li...@codenation.net> 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=mdyk...@gmail.com > > -- - michael dykman - mdyk...@gmail.com - All models are wrong. Some models are useful. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
