Linked by Thom Holwerda on Wed 16th Jan 2008 14:34 UTC, submitted by BluenoseJake
Thread beginning with comment 296366
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
The issue becomes a horrid mess when you have 160G of data and you need to dump the data twice a day . A plain old SQL dump of this size eats Disk I/O like its going out of style. Now say I have Dumps / database / table , and I need to restore a dump to a new server. Say I have a 50G table to restore to a new box , a 50G dump is going to take a long time to read into a new server.
Say I just need backups once a day there is no database snapshot system. This has to be done on the filesystem with a read lock on the database. So on most UNIX OS's this can be done but now that I have a snapshot of the datadir how do I say restore one table from an innodb database ? Yes I am aware of innodb files / table , but this is adding up to a pile of band-aids added to MySQL to make it work better.
Say I just need backups once a day there is no database snapshot system. This has to be done on the filesystem with a read lock on the database. So on most UNIX OS's this can be done but now that I have a snapshot of the datadir how do I say restore one table from an innodb database ? Yes I am aware of innodb files / table , but this is adding up to a pile of band-aids added to MySQL to make it work better.
There is a hot backup product for innodb. Not so for myisam. I'm not sure why you'd be using myisam if you're doing a lot of updates, inserts, and deletes.
Using innodb and even without a hot backup tool, you could achieve something close to what you're interested in with a combination of traditional cold full backups and binary logs. You could also use replication and backup your replica to achieve high uptime.
Edited 2008-01-16 20:57 UTC
Again this sort of stuff needs to looked at by SUN / MySQL . Innodb is nice but its going away. Filesystem Snapshots work well in some cases but not all. A Database which has the snapshotting built is better. A MySQL system that has non blocking backups, that work correctly, fast and consistently on various architectures, would rock. And yes both things can be with software already out there. I know I am asking for allot but Have you seen Oracle 11G RAC with ASM.
There is a hot backup product for innodb. Not so for myisam
mysqlhotcopy?
http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html





Member since:
2007-01-22
My issues with mysql are not about if it does Stored Procedures or what level of SQL compliance it has. I don't even care how fast it is. My issues have to do with two simple things. Backups / Restores and Snapshots.
When users had 20meg databases and they had the time to spare for a read lock for the dump to work. This was not a big deal. The issue becomes a horrid mess when you have 160G of data and you need to dump the data twice a day . A plain old SQL dump of this size eats Disk I/O like its going out of style. Now say I have Dumps / database / table , and I need to restore a dump to a new server. Say I have a 50G table to restore to a new box , a 50G dump is going to take a long time to read into a new server.
Say I just need backups once a day there is no database snapshot system. This has to be done on the filesystem with a read lock on the database. So on most UNIX OS's this can be done but now that I have a snapshot of the datadir how do I say restore one table from an innodb database ? Yes I am aware of innodb files / table , but this is adding up to a pile of band-aids added to MySQL to make it work better.
When will they address this in a proper way say the way Oracle does this with RMAN .