Comments on: mg_hot_replace_table.pl

By: Log Buffer #188, a Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #188, a Carnival of the Vanities for DBAs | The Pythian Blog — Mon, 10 May 2010 15:01:56 +0000

[...] the community know about his blog MySQL Fan Boy, where he wrote an interesting post on including a script to replace MySQL table files on a live system, making it faster and limiting locking on large table loads. Also a post this week [...]

By: mark

mark — Thu, 06 May 2010 15:25:05 +0000

You are right. I can think of lots of ways to make this a more useful utility.
– Check that the new data files is on the same file system
– move the file to the same file system for the user
– check the file is not corrupted.
– option to archive the old file
– add the old file to an archive by renaming it and moving it.

Most people don’t completely replace a table. What I have is weather forecast data. It’s good for a short time and then is replaced. Old forecast data is replace with the observations for the same location.

I also found this useful when I had large amounts of cell phone records that arrives in large CVS files and needed to be indexed before “loading” into another database. I would prepare the data on an offline server using “Load File”, index it and then move it to the production server. This method would load millions of records in milliseconds.

By: Nic Zero

Nic Zero — Thu, 06 May 2010 07:52:40 +0000

You can make this more generally useful if you implement it as a class and your routines become methods. Modify them so they take the db handle as a parameter. Then any piece of code you have that has a mysql db handle can call one or more methods as it wants.