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. On Tue, Mar 24, 2009 at 7:44 AM, Craig Dunn <li...@codenation.net> wrote: > > > Hi All, > > I need to migrate a large (30G) database from 4.1 to 5.1 on a live system > that cannot afford a large amount of downtime. The official method (copy > files, run mysql_upgrade...etc) is looking like it will take forever, > particularly since I need to move it 5.0 before 5.1. How do people normally > manage this in a high availability environment? > > One idea being floated is to set up slave running 5.1 to replicate off 4.1 > and then cut it over to being the master when we're ready to migrate... is > this feasable or dangerous? > > Anyone else who's dealt with this kind of migration before have any other > ideas? > > Thanks in advance. > > Craig > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=ba...@xaprb.com > > -- Baron Schwartz, Director of Consulting, Percona Inc. Our Blog: http://www.mysqlperformanceblog.com/ Our Services: http://www.percona.com/services.html -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
