Comments on: My “hot” list for next InnoDB features http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Baron Schwartz http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-712693 Baron Schwartz Thu, 21 Jan 2010 14:26:42 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-712693 XtraDB lets you do that. XtraDB lets you do that.

]]> By: Mikael Fridh http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-712666 Mikael Fridh Thu, 21 Jan 2010 12:14:04 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-712666 ALTER TABLE ... IMPORT TABLESPACE is great ... only thing missing is EXPORT TABLESPACE ... ALTER TABLE … IMPORT TABLESPACE is great … only thing missing is EXPORT TABLESPACE …

]]> By: Theo http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-663893 Theo Mon, 12 Oct 2009 01:04:57 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-663893 It's a table cold backup and restory without shut down of InnoDB Restoring a single .ibd file http://www.innodb.com/doc/hot_backup/manual.html#partial.restoring.single It’s a table cold backup and restory without shut down of InnoDB

Restoring a single .ibd file
http://www.innodb.com/doc/hot_backup/manual.html#partial.restoring.single

]]> By: Reinhard http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-604634 Reinhard Fri, 03 Jul 2009 22:25:31 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-604634 Make auto_increment persistent in InnoDB. So when we restart the server, it doesn´t lose the latest value (if we deleted it) Make auto_increment persistent in InnoDB. So when we restart the server, it doesn´t lose the latest value (if we deleted it)

]]> By: Kevin Burton http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-530781 Kevin Burton Mon, 06 Apr 2009 06:47:45 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-530781 Nice..... those are a hot set of features and something at the top of my list for a while now! We'd definitely upgrade ASAP to this release when it became available. Some of the performance improvements are really nice but these would be bigger wins for us.... Nice….. those are a hot set of features and something at the top of my list for a while now!

We’d definitely upgrade ASAP to this release when it became available.

Some of the performance improvements are really nice but these would be bigger wins for us….

]]> By: John Allspaw http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-530772 John Allspaw Mon, 06 Apr 2009 05:32:11 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-530772 A 'show fragmentation' or equivalent command to give me some idea of exactly how badly I need to run an OPTIMIZE. Any of the traditionally proposed solutions relies on math that is too much of an approximation. Like this: http://www.flickr.com/photos/allspaw/3174500698/in/pool-webopsviz -j A ‘show fragmentation’ or equivalent command to give me some idea of exactly how badly I need to run an OPTIMIZE. Any of the traditionally proposed solutions relies on math that is too much of an approximation.

Like this: http://www.flickr.com/photos/allspaw/3174500698/in/pool-webopsviz

-j

]]> By: pat http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-530717 pat Mon, 06 Apr 2009 02:25:12 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-530717 I'd like to be able to use file_per_table, and then move those files to a different server, mount them, and run off them. I don't mind doing something like: source machine: unmount scp * -> some other machine target machine mount Having to do an export/import to move data between innodb servers is really rather onerous with large databases. I’d like to be able to use file_per_table, and then move those files to a different server, mount them, and run off them.

I don’t mind doing something like:

source machine:
unmount

scp * -> some other machine

target machine
mount

Having to do an export/import to move data between innodb servers is really rather onerous with large databases.

]]> By: Dimitri http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-530415 Dimitri Sun, 05 Apr 2009 16:27:42 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-530415 Regarding scalability issues what is fixed for the moment - there is no more dramatic performance degradation with upgrading a given server from 8 to 16cores (for ex.). But there is still not to much performance improvement with it, there is even no 50% gain, so work in this direction is far to be finished :-) (of course it depends on workload, but it's what I saw).. For other features: * parallel degree of query execution - specially for all "full scan" queries where it should be quite easy to implement (and "select count(*)" is one of cases) * remove datafile names list from conf file, as well remove data dir path, and keep all datafile related information within a single master file *per* database - in way each database may be independently backed up and restore elsewhere; all datafile operations should be accessible on-line and via SQL commands; move from datafiles to "tablespaces" (may contain one or more datafiles), and then add "tablespace" to CREATE TABLE option, etc; make tablespace "transportable" (keeping all even dictionnary information inside leaving tablespace free to move between databases, systems/servers, etc.) Rgds, -Dimitri Regarding scalability issues what is fixed for the moment – there is no more dramatic performance degradation with upgrading a given server from 8 to 16cores (for ex.). But there is still not to much performance improvement with it, there is even no 50% gain, so work in this direction is far to be finished :-) (of course it depends on workload, but it’s what I saw)..

For other features:

* parallel degree of query execution – specially for all “full scan” queries where it should be quite easy to implement (and “select count(*)” is one of cases)

* remove datafile names list from conf file, as well remove data dir path, and keep all datafile related information within a single master file *per* database – in way each database may be independently backed up and restore elsewhere; all datafile operations should be accessible on-line and via SQL commands; move from datafiles to “tablespaces” (may contain one or more datafiles), and then add “tablespace” to CREATE TABLE option, etc; make tablespace “transportable” (keeping all even dictionnary information inside leaving tablespace free to move between databases, systems/servers, etc.)

Rgds,
-Dimitri

]]> By: Bhushan Uparkar http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-528462 Bhushan Uparkar Fri, 03 Apr 2009 00:59:02 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-528462 I like to add one more feature with 5.1 we have partitions , so if 1 partition gets corrupt innodb crashes the mysql, it should handle the corrupt partition gracefully without causing the assertion. Same could be said for corrupt table as well. During innodb crash recovery the modes available should provide some table dictionary i.e. some dynamic view informing the corrupt innodb tables. Presently you dont know how many tables in db are corrupted without spending some good amount of time with innodb recovery tools [ http://code.google.com/p/innodb-tools/ ]. I like to add one more feature with 5.1 we have partitions , so if 1 partition gets corrupt innodb crashes the mysql, it should handle the corrupt partition gracefully without causing the assertion. Same could be said for corrupt table as well.
During innodb crash recovery the modes available should provide some table dictionary i.e. some dynamic view informing the corrupt innodb tables. Presently you dont know how many tables in db are corrupted without spending some good amount of time with innodb recovery tools [ http://code.google.com/p/innodb-tools/ ].

]]> By: Brian Cavanagh http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/comment-page-1/#comment-525947 Brian Cavanagh Tue, 31 Mar 2009 23:53:44 +0000 http://www.mysqlperformanceblog.com/?p=651#comment-525947 The big thing I would like innodb to have is solid sup to date statistics. The big thing I would like innodb to have is solid sup to date statistics.

]]>