Re: Upgrade large databases from 4.1 to 5.1
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 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
Re: Upgrade large databases from 4.1 to 5.1
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=arch...@jab.org
Re: Upgrade large databases from 4.1 to 5.1
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 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
Upgrade large databases from 4.1 to 5.1
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=arch...@jab.org
