Don't forget triggers, stored routines, views, database/table specific user permissions, and replication/binlog options!
Regards, Gavin Towey -----Original Message----- From: Saravanan [mailto:suzuki_b...@yahoo.com] Sent: Friday, December 11, 2009 2:02 PM To: MySql; Michael Dykman Subject: Re: Are you serious? mySQL 5.0 does NOT have a RENAME DATABASE? if you have myisam alone tables you can rename the folder of the database. That can work like rename database. If you have innodb table you have to move one by one table because details of those tables will be stored in innodb shared table space. Moving folder cannot work. Thanks, Saravanan --- On Fri, 12/11/09, Michael Dykman <mdyk...@gmail.com> wrote: From: Michael Dykman <mdyk...@gmail.com> Subject: Re: Are you serious? mySQL 5.0 does NOT have a RENAME DATABASE? To: "MySql" <mysql@lists.mysql.com> Date: Friday, December 11, 2009, 10:54 PM No, not a loophole. Just a plain-old management feature.. there is nothing particularly hacky about it.. this is not trying to leverage undocumented features: this has been a published part of the API for at least a couple of years. On the same file system, yes it should be pretty damned fast. Depending on how your data is stored, it might now be 'quite' as simple as a unix 'mv' command.. if this is a production system, I would recommend you do a dry run with a replicant/slave. No amount of theorizing will tell as much as the experiment. - michael dykman On Fri, Dec 11, 2009 at 4:40 PM, Daevid Vincent <dae...@daevid.com> wrote: > Will this work in 5.0? > > If I'm reading this right, it seems like this is some kind of trick or > loophole then right? If it works and solves my dilemna, I'm fine with that, > but I'm just curious. > > How fast is this? I mean, if I have an 80GB database, is it like a real > unix 'mv' command where it simply changing pointers or is it a full on > copy/rm? (Assume same filesystem/directory) > >> -----Original Message----- >> From: Michael Dykman [mailto:mdyk...@gmail.com] >> Sent: Friday, December 11, 2009 6:08 AM >> To: MySql >> Subject: Re: Are you serious? mySQL 5.0 does NOT have a >> RENAME DATABASE? >> >> If you want to move the database atomically, a RENAME TABLE statement >> may have multiple clauses. >> >> RENAME TABLE >> olddb.foo to newdb.foo, >> olddb.bar to newdb.bar; >> >> Here, I hot-swap a new lookup table 'active.geo' into a live system >> confident that, at any given point, some version of this table always >> exists: >> >> RENAME TABLE >> active.geo to archive.geo, >> standby.geo to active geo; >> >> - michael dykman >> >> >> On Fri, Dec 11, 2009 at 8:58 AM, Johan De Meersman >> <vegiv...@tuxera.be> wrote: >> > On Fri, Dec 11, 2009 at 1:56 PM, Ken D'Ambrosio >> <k...@jots.org> wrote: >> > >> >> > rename table oldschema.table to newschema.table; >> >> >> >> Just to be 100% clear -- I assume you have to first create >> the destination >> >> database, and then do this for all the tables in the >> source database? >> >> >> > >> > Yep. Easily scriptable, though :-) >> > >> >> >> >> -- >> - michael dykman >> - mdyk...@gmail.com >> >> "May you live every day of your life." >> Jonathan Swift >> >> Larry's First Law of Language Redesign: Everyone wants the colon. >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe: >> http://lists.mysql.com/mysql?unsub=dae...@daevid.com >> > > -- - michael dykman - mdyk...@gmail.com "May you live every day of your life." Jonathan Swift Larry's First Law of Language Redesign: Everyone wants the colon. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=suzuki_b...@yahoo.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org