Comments on: Reasons to use innodb_file_per_table http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table Blog by Shlomi Noach Wed, 01 Feb 2012 20:47:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: MySQL performance tips for Zabbix | Zabbix Zone http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-58013 MySQL performance tips for Zabbix | Zabbix Zone Tue, 08 Nov 2011 10:33:52 +0000 http://code.openark.org/blog/?p=614#comment-58013 [...] Some discussions about this: http://dom.as/2009/05/21/innodb-tablespace/ http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table [...] [...] Some discussions about this: http://dom.as/2009/05/21/innodb-tablespace/ http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table [...]

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-55313 shlomi Tue, 18 Oct 2011 12:29:16 +0000 http://code.openark.org/blog/?p=614#comment-55313 Well, you're in a serious problem. I would tell you to open your backup, but I'm sure you're asking this question as you don't have one. Or you could rely on your replicating slave if you have one. Depending on your file system, you may be able to restore the file itself. If this is made possible, you may recover your innodb data using <a href="https://launchpad.net/percona-data-recovery-tool-for-innodb" rel="nofollow">innodb-tools</a>. But if you're down to that, you may seek out help from Percona, who author those tools. Well, you're in a serious problem.
I would tell you to open your backup, but I'm sure you're asking this question as you don't have one. Or you could rely on your replicating slave if you have one.
Depending on your file system, you may be able to restore the file itself.
If this is made possible, you may recover your innodb data using innodb-tools. But if you're down to that, you may seek out help from Percona, who author those tools.

]]> By: rahul http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-55312 rahul Tue, 18 Oct 2011 12:15:29 +0000 http://code.openark.org/blog/?p=614#comment-55312 i want to know one thing>>>>if bychance iddata1 file has deleted then all table data would gone.....how i will resolve this solution. i want to know one thing>>>>if bychance iddata1 file has deleted then all table data would gone.....how i will resolve this solution.

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-52559 shlomi Fri, 23 Sep 2011 04:56:28 +0000 http://code.openark.org/blog/?p=614#comment-52559 @John, George, Ah, but it has been more than two years since this post was published. Much has happened since. In particular, the emergence of InnoDB Plugin (now just InnoDB), replacing the older "builting" InnoDB. InnoDB Plugic comes with many improvements; performance, scale up, bugfixes, blob storage, ... And to fully utilize its functionality (you can use half of its advantages without changing anything), you need to upgrade your tables to "barracuda format". Guess what? It requires innodb_file_per_table. So file-per-table is now also a feature issue. You loose features (e.g. compression, blob storage) which can directly relate to performance issues. @John, George,

Ah, but it has been more than two years since this post was published. Much has happened since.
In particular, the emergence of InnoDB Plugin (now just InnoDB), replacing the older "builting" InnoDB.
InnoDB Plugic comes with many improvements; performance, scale up, bugfixes, blob storage, ...
And to fully utilize its functionality (you can use half of its advantages without changing anything), you need to upgrade your tables to "barracuda format".
Guess what? It requires innodb_file_per_table.
So file-per-table is now also a feature issue. You loose features (e.g. compression, blob storage) which can directly relate to performance issues.

]]> By: George M http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-52555 George M Fri, 23 Sep 2011 03:36:40 +0000 http://code.openark.org/blog/?p=614#comment-52555 I've been running several MySQL servers for a number of years. I have one particular box that has a little over 400 databases totaling about 350GB. The server was originally setup using 3 ibdata files back on 4.0, and was later changed to file per table. There has not been any appreciable speed difference from what I can see. The server is very busy, averaging 6-7 GB of binlogs per day. There is file system overhead for sure, but the db files are stored on a 16 spindle 6gb/s sas array, so I don't expect that any small gain would warrant moving back to single files again. I've been running several MySQL servers for a number of years. I have one particular box that has a little over 400 databases totaling about 350GB. The server was originally setup using 3 ibdata files back on 4.0, and was later changed to file per table. There has not been any appreciable speed difference from what I can see. The server is very busy, averaging 6-7 GB of binlogs per day. There is file system overhead for sure, but the db files are stored on a 16 spindle 6gb/s sas array, so I don't expect that any small gain would warrant moving back to single files again.

]]> By: John Scott http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-49169 John Scott Thu, 18 Aug 2011 17:47:01 +0000 http://code.openark.org/blog/?p=614#comment-49169 I hail from DB2 land and I really enjoyed the ability to put one or more tables of my choosing in a particular tablespace and others in another tablespace. I totally agree with many of the points here about the filesystem overhead of having a file per table. However, I also don't want all tables to be in one file. Is there not a happy medium in mysql? I hail from DB2 land and I really enjoyed the ability to put one or more tables of my choosing in a particular tablespace and others in another tablespace.

I totally agree with many of the points here about the filesystem overhead of having a file per table. However, I also don't want all tables to be in one file.

Is there not a happy medium in mysql?

]]> By: Gabe da Silveira http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-17800 Gabe da Silveira Sun, 19 Sep 2010 22:43:10 +0000 http://code.openark.org/blog/?p=614#comment-17800 I find the whole tone of Domas' post extremely irritating. Internet trolls are a dime a dozen, but when someone really knows their stuff, it's annoying when they go around with an attitude like anyone without that domain knowledge is an idiot. Especially when he makes hand-wavy assumptions about real world scenarios that aren't universally true, such as the idea that permanent data will always grow faster overall than temporary data. Not to mention cases where there are other infrastructure considerations in play, such as using Time Machine on OS X where monolithic files defeat the primary utility of the system. It sort of reminds me of Fabian Pascal's dbdebunk.com mysterious silence coinciding very closely with the rise of the NoSQL movement. That guy was one of the foremost experts in relational theory, and yet for all his expertise, he was not able to educate people and fell prey to his own dogma which was unreconcilable with the unprecedented scaling challenges faced by the social web. No doubt he is still sitting in his office wildly gesticulating about the failure of the market to produce a "true" RDBMS system, which, of course, would have superceded the need for the current breed of alternate database technologies. The lesson here, which I would have posted to Domas' post if he allowed comments, is that no one knows everything, and if you are a domain expert you should share your knowledge openly rather than belittling others. If Domas built a web application I could poke his implementation choices full of countless holes, but it wouldn't make me smarter than him. I find the whole tone of Domas' post extremely irritating. Internet trolls are a dime a dozen, but when someone really knows their stuff, it's annoying when they go around with an attitude like anyone without that domain knowledge is an idiot. Especially when he makes hand-wavy assumptions about real world scenarios that aren't universally true, such as the idea that permanent data will always grow faster overall than temporary data. Not to mention cases where there are other infrastructure considerations in play, such as using Time Machine on OS X where monolithic files defeat the primary utility of the system.

It sort of reminds me of Fabian Pascal's dbdebunk.com mysterious silence coinciding very closely with the rise of the NoSQL movement. That guy was one of the foremost experts in relational theory, and yet for all his expertise, he was not able to educate people and fell prey to his own dogma which was unreconcilable with the unprecedented scaling challenges faced by the social web. No doubt he is still sitting in his office wildly gesticulating about the failure of the market to produce a "true" RDBMS system, which, of course, would have superceded the need for the current breed of alternate database technologies.

The lesson here, which I would have posted to Domas' post if he allowed comments, is that no one knows everything, and if you are a domain expert you should share your knowledge openly rather than belittling others. If Domas built a web application I could poke his implementation choices full of countless holes, but it wouldn't make me smarter than him.

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6462 shlomi Thu, 12 Nov 2009 06:11:26 +0000 http://code.openark.org/blog/?p=614#comment-6462 Hi, They guy who absolutely hates innodb_file_per_table would be <a href="http://dammit.lt/2009/05/21/innodb-tablespace/" rel="nofollow">Domas Mituzas</a>. I disagree with part of his arguments. But he is an expert in the field, so this does not mean I belittle him. It's just that there's some contention between "what's utterly best for performance" and "what's best to live with". The two do not work well together. There's reasons for and against. I've presented the reasons "for". As I see it, the development is moving in the direction of innodb_file_pre_table: the innodb plugin has to use this option if you want to use Barracuda table format (which allows for compression, among other things). Anyway, I don't get paid to support innodb_file_per_table :) I'll use the single tablespace if I think it's superior. Regards Hi,

They guy who absolutely hates innodb_file_per_table would be Domas Mituzas.
I disagree with part of his arguments. But he is an expert in the field, so this does not mean I belittle him. It's just that there's some contention between "what's utterly best for performance" and "what's best to live with". The two do not work well together.

There's reasons for and against. I've presented the reasons "for".
As I see it, the development is moving in the direction of innodb_file_pre_table: the innodb plugin has to use this option if you want to use Barracuda table format (which allows for compression, among other things).

Anyway, I don't get paid to support innodb_file_per_table :) I'll use the single tablespace if I think it's superior.

Regards

]]> By: Mikev http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6460 Mikev Thu, 12 Nov 2009 05:25:22 +0000 http://code.openark.org/blog/?p=614#comment-6460 I have found various blogs/sites on the net attacking the innodb_file_per_table setting due to extra threads and disk io usage that can occur. This guys post appears to be the most complete with small benchmark examples of fdatasync/sec numbers http://yoshinorimatsunobu.blogspot.com/2009/05/overwriting-is-much-faster-than_28.html I lost some of the other links there is this other guys blog that totally hates it and he seemed like his arguments were quite good. I read since I closed by browser down earlier today. Seems like if you value the odd amount of disk space over performance by all means enable innodb_file_per_table but if you value performance above easy management thing don't use this setting. Also I grabbed this out of the "High performance MYSQL" Book. 'Innodb_file_per_table causes each file to be fsynced separately, which means writes to multiple tables can't be combined into a single I/O operation. This may require InnoDB to perform a higher total number of fsync() operations.' I have found various blogs/sites on the net attacking the innodb_file_per_table setting due to extra threads and disk io usage that can occur.
This guys post appears to be the most complete with small benchmark examples of fdatasync/sec numbers

http://yoshinorimatsunobu.blogspot.com/2009/05/overwriting-is-much-faster-than_28.html

I lost some of the other links there is this other guys blog that totally hates it and he seemed like his arguments were quite good. I read since I closed by browser down earlier today.

Seems like if you value the odd amount of disk space over performance by all means enable innodb_file_per_table but if you value performance above easy management thing don't use this setting.

Also I grabbed this out of the "High performance MYSQL" Book.

'Innodb_file_per_table causes each file to be fsynced separately, which means writes to multiple tables can't be combined into a single I/O operation. This may require InnoDB to perform a higher total number of fsync() operations.'

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6458 shlomi Thu, 12 Nov 2009 04:20:20 +0000 http://code.openark.org/blog/?p=614#comment-6458 @Mikev, I'm not aware that there's a difference in write speed. Can you point out the references? Thanks @Mikev,

I'm not aware that there's a difference in write speed. Can you point out the references?
Thanks

]]>