As of MySQL 4 the default when compiling and binary release is to have innodb support. I believe USE="innodb" emerge mysql should no longer be necessary.
USE=innodb greatly increases the MySQL compile time. So for those that don't want it, I see no reason to include it.
I would urge you to reconsider this issue. Many people need transactions and/or foreign keys, and for this InnoDB is a requirement. For comparison... on Windows, in many 4.1 setups InnoDB is now actually configured to be the default storage engine. I don't think increased compile time is really a reason for seriously crippling basic functionality of software. Indeed, not everybody uses/needs transactions, but that's not the point. It is basic functionality, and has been for years. Please change this? Thanks. I'd be happy to discuss this further, arjen (at) mysql (dot) com. Arjen Lentz Community Relations Manager MySQL AB
I'd say go for InnoDB. Gentoo users, I believe, are used to the long compile times. And since InnoDB is so important (because of transactions) I think it should be enabled by default. After all, anyone who is not interested on it, can disable it.
I'd also like to see this enabled by default. InnoDB has been there for a long time, and still many people claim MySQL lacks transactions. Additional compile time should not be an argument for disabling such an important feature.
My understanding is that ebuilds should follow upstream defaults whenever possible. Thus I am +1 for enabling +innodb by default.
Lets come to a compromise on this here. I'm NOT willing to have USE=innodb in the default USE flags. The primary reason is that for the average Gentoo user, they only have mysql installed as a dep for something else, and actually don't use mysqld - in which case innodb needlessly increases the compile time. (Yes, I know this could be worked around if we had better sub-packages). Even still, for those that have MySQL servers, I don't make all that much use of InnoDB (I've got a lot of legacy work in MyISAM, but it is being converted over slowly [to properly take advantage of innodb]). So here's what I would like to propose instead. 1. For existing MySQL packages: additional of a 'minimal' USE flag to mysql packages, that builds just the libs, headers, and client. innodb stays as it is. 2. For MySQL4.1/5.0: change the innodb flag to a noinnodb flag, so that innodb is built by default. Keep the 'minimal' USE flag as well. 3. For all MySQL packages: when innodb is being compiled in, don't install a configuration file with skip-innodb, and instead having a basic innodb configuration. Arjen: would something similar to the innodb sample config in my-small.cnf/my-medium.cnf be reasonable to use as a distro-wide default?
*** Bug 79832 has been marked as a duplicate of this bug. ***
*** Bug 79879 has been marked as a duplicate of this bug. ***
In my opinion, I'd say don't touch the use flags. Innodb is an option in MySql it is not a critical component for it to function by itself (i.e. for the case where mysql is installed because of deps). Users are introduced to the concept of use flags in the handbook so they should know about it and at least check the list once if not a little RTFM wouldn't hurt. At best, it could be made local but nothing more since I did a quick grep on the tree and only the mysql packages uses the innodb use flag and a lone rt package that requires innodb support. Arjen : Not to be nitpiking but what is the upstream default for the linux package ? I'm probably sure it's innodb since you brought the example but hey we are talking about a linux distro here :). As for the config file, you use einfo to inform the user that it is disable by default but he can quickly enable innodb support by commenting-out "skip-innodb". Or by your suggestion copy a different one if innodb flag is set. I don't know if it is possible in mysql but maybe source another config file (a la apache) like the other devs do for example svn or php ? I highly doubt it but that could be another possibility. My 2cents
The upstream default is for InnoDB to be compiled in and enabled, the build scripts will do this if no specific enable or disable flags are provided. And this is exactly the point. People expect it to be in there, and then trip with Gentoo. The compile option to disable InnoDB exists mainly for embedded and other small-footprint ISVs. Many components of MySQL can be excluded from compile, for limited applications. However, that is not the default. By default, all the common features like InnoDB, query cache, etc are enabled, and the non-necessary extras are disabled (unless you use a -max binary from mysql.com, which explicitly has those extras enabled). In short, InnoDB is a standard feature of MySQL, not an optional extra. Excluding it makes no sense. Regarding the dependencies... other apps would only have a dependency on the MySQL client library. So if you want to split the package into client/server (like everybody else does ;-) then that's fine. Have the client package to satisfy the dependencies, and the complete server including InnoDB if people actually want to run the MySQL Server. However (counter argument) the server dependency would not show up as a dependency, it would only show up at runtime when an application cannot connect to it. This again is cause for confusion and user annoyance. Most other Linux distributions simply install MySQL Server by default because so many apps use it anyway. On disk and in mem it has a pretty small footprint. Continuing the functional argument... many apps that would use MySQL with InnoDB would not have Gentoo packages. Many are PHP or other apps, people get them off the net, install them, and use them. Except, the app trips over the lack of InnoDB, they may not complain but just not function correctly, as many apps have very bad error checking. Now we can argue that fact, but I just take it as a reality we have to deal with. Again, InnoDB is a standard feature, apps can expect at least any 4.0 or above server to have it. Regarding the default config. No need to put anything into my.cnf, the compiled-in defaults are fine for a minimal functional setup including InnoDB. Of course, a production server should always be tuned, but we're just talking basic operation (for say a simple dev/user system) and that's fine. I hope this info helps your deliberations. Thanks!
Thanks Arjen for the big picture. I'd like to keep it short and sweet since this is not the place to have a lenghty discussion and more importantly I'm not a gentoo dev. I do not speak for the MySql herd whatsoever. People using gentoo except use flag since they are thaught how to use them on a very early stage trought the handbook. When they set the "innodb" use flag, they are expected to have the function compiled-in and not necessarily enabled in the config AFAIK. If they don't set this use flag, they shouldn't complain upstream. Gentoo has always been a more hands-on approach. Point taken, it would be useful to seperate the client from the server. As for the implementation or true usefulness, I would leave it to the mysql herd. Except the fact that gentoo dev's doesn't throw everything with the kitchen sink like other distro. Some people use mysql with php some don't (think PGSQL or no db at all). Some apps uses innodb some don't. When it is mandatory to use innodb, ebuilds have a way to check it and stop with a message (like the RT ebuild). That is why innodb isn't compiled by default, I use many webapps that doesn't even use innodb and I'm glad it doesn't clutter one of my server. It's all in the name of flexibility from compiling from source. As for the increase compile time, yes for some people it does matter. innodb support is an option. Yes it is a VERY GOOD feature to have but it's simple to enable and it keeps the system lean and mean if you don't want it. See here for more opinion : http://thread.gmane.org/gmane.linux.gentoo.user/117353 My own 2 cents
I totally forgot to respond to Robin for picking a solution. So here goes : 1. A minimal use flag would be good. Will it also build the server or only the client ? 2. I'm not really fond of that use flag. I'm one of many poeple that set -* to disable everything and enable only what I want. Setting noinnodb instead would go against the flow IMO. 3. That could be a work around. Would that mean that you would carry two config file or you would sed it ? Just commenting out skip-innodb with a little sed when innodb is in the use would be great. I should have taken the "little discussion" directly to the mailing list. Sorry for that. In short, I'm all for 3, maybe 1 and not for 2.
I opened this bug when I was new to gentoo. I think the issue about client/server and bloated mysql is more of an issue of poor planning, it should be mysql-client & mysql-server but I'm not indepth into the logic and reasoning for them not exist - but it seems like a serious lack of thought then to say 'well its okay to give people a daemon that they didn't want, but lets not make it a featured one because that takes longer to compile'. I would say make a mysql-client & mysql-server with minimal to disable innodb and other mysql features. I think we should factor in Arjen is a 'Community Relations Manager' and is raising the issue because users are having problems. And thus at the very least a message should be added to the end of the ebuild saying "* InnoDB, mysql's transaction storage engine was not included..." But I'm just a user who happened to file a bug report...
The gentoo policy is to NOT split up a package and make redhat-like subpackages. Instead, it's recently be found that a USE=minimal is coming in handy in the case of some larger packages - esp. xorg-x11 (which brings the overhead down significently, and is great when you need a server box, but have an app that uses some of the X libraries still). USE=minimal will build just: headers, libmysqlclient, client-side binaries. it will leave out all of the server/mysqld parts (include the tests and sql-bench). USE=innodb dates back to when MySQL-3.23 didn't have a stable innodb and didn't even compile it by default (A very long time ago), and given the opposition USE=noinnodb, I'm open to just having it as included as non-optional when building the server, and then just having the innodb configuration chunk from the sample configurations (commented out, just like in upstream's sample config files). As Dane brings up, having a message that InnoDB is turned off during the compile is a good start, so I've done that in the tree already.
I'd leave sql-bench out of any minimal (or even normal) build, it's not really part of the basic setup. Probably also removes a dependency on Perl. (for comparison, on RPM based systems the bench stuff is separate, and most people don't ever install it). There is the standard test suite which SHOULD be included and of course be run after a build of the server (to make sure it's a good build!) I think the "minimal" flag is a good idea, if that fits best with the Gentoo way. I would just like to see that IF the server is built, it is built WITH innodb by default and that it's not disabled in the default/sample config. When picking up a sample config, please grab the example from http://dev.mysql.com/doc/mysql/en/innodb-configuration.html rather than the old sample configs that may be in some distributions, as it's more up-to-date. Comment out all the lines as the built-in defaults are ok for a minimal setup. Please note that this whole story is valid for 4.0, 4.1 and 5.0 For 3.23, InnoDB has of course also been stable for a long time, however it was not compiled-in by default. It was also not enabled by default (at runtime), and needed explicit configuring. I don't mind leaving the 3.23 situation as-is. It's ancient history. Most people use at least 4.0 anyway, 4.1 is production, and before mid this year we'll see 5.0 production. So if the discussed changes are applied to 4.0 and up, I'm sure that users would be very happy indeed (which in turn makes me happy ;-) Thanks. Regards, Arjen. Community Relations Manager MySQL AB
arjen: thanks for the input. We're going to keep the sql-bench stuff when the server is installed. I find it's got some nice examples of how to do things in MySQL, esp. when DBI is concerned. It's only installed when USE=perl anyway, so if the user have USE=-perl, they don't get perl pulled in. These are the options I plan to use the my.conf. # don't eat too much memory, we're trying to be safe on 32Mb boxes. set-variable = innodb_buffer_pool_size=32M # this is the default, increase if you have lots of tables set-variable = innodb_additional_mem_pool_size=1M # seperate filesystem space for innodb data # this keeps /var/lib/mysql clean. # i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-( innodb_data_home_dir = /var/lib/mysql.innodb/data/ # you may wish to change this size to be more suitable for your system # the max is there to avoid run-away growth on your machine innodb_data_file_path = ibdata1:16M:autoextend:max:128M # keep these two the same! innodb_log_group_home_dir = /var/lib/mysql.innodb/logs/ innodb_log_arch_dir = /var/lib/mysql.innodb/logs/ # we keep this at around 25% of of innodb_buffer_pool_size # sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size) set-variable = innodb_log_file_size=8M # this is the default, increase if you have very large transactions. set-variable = innodb_log_buffer_size=1M # this is the default, and won't hurt you. # you shouldn't need to tweak it. set-variable = innodb_log_files_in_group=2 # see the innodb config docs, the other options are not always safe innodb_flush_log_at_trx_commit=1
A few comments regarding the proposed my.conf > # don't eat too much memory, we're trying to be safe on 32Mb boxes. > set-variable = innodb_buffer_pool_size=32M The comment makes no sense. Do you want 32MB boxes to swap? > # seperate filesystem space for innodb data > # this keeps /var/lib/mysql clean. > # i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-( > innodb_data_home_dir = /var/lib/mysql.innodb/data/ That's a valid choice, however it ones again makes for a layout/setup different from other distros, and this complicated documentation and support. I don't see why InnoDB's stuff needs to be separated from the other database and log file info. Naturally, on a production system people may create their own setup, also separating data from logfiles on different physical drives. The above separation doesn't actually accomplish anything, other than encouraging a new game of hide&seek ;-) As a final counter-argument, a backup would require grabbing both /var/lib/mysql as well as /var/lib/mysql.innodb/. That makes no sense. InnoDB databases also have structural information stored in /var/lib/mysql/(dbname)/... so you're separating info that belongs together. Again, InnoDB is an integral part of MySQL, for the sake of users please do reconfigure things to separate it where it shouldn't be. > # you may wish to change this size to be more suitable for your system > # the max is there to avoid run-away growth on your machine > innodb_data_file_path = ibdata1:16M:autoextend:max:128M Minimum is 10MB, so I'd suggest using that. Regards, Arjen. Community Relations Manager MySQL AB
for those following on this bug, the discussions here will be coming into effect when upstream puts out 4.0.24.
This is now all implemented in 4.0.24-r1.
This is crazy!!!! Nightmare is back! 0_0 Make update the mysql from 4.x to 5.1.51 and lost a lot of money because billing stop counting money correctly, why you not announced what you disable InnoDB AGAIN??? :-\ Quick solution: echo "dev-db/mysql community profiling innodb" >> /etc/portage/package.use && emerge mysql && mysql_upgrade -p && /etc/init.d/mysql restart && mysqlcheck --all-databases --auto-repair -u root -p ps: what is crazy guy disable innodb again? he just pissed me off :(((((((( what reason was to do that? no, seriously???!!! Because mysql is "compiling long time"??? imho, this is totally brain off reason. pps: innodb transactions is standard for present days.
(In reply to comment #20) > This is crazy!!!! > Nightmare is back! 0_0 > Make update the mysql from 4.x to 5.1.51 and lost a lot of money because > billing stop counting money correctly, why you not announced what you disable > InnoDB AGAIN??? :-\ What the crap are you talking about? We haven't disabled InnoDB at all. > Quick solution: echo "dev-db/mysql community profiling innodb" >> > /etc/portage/package.use && emerge mysql && mysql_upgrade -p && > /etc/init.d/mysql restart && mysqlcheck --all-databases --auto-repair -u root > -p There IS no more USE=innodb. It's _always_ built into the binaries, and has been for several years now. It's also included in the stock my.cnf that we install for several years. Read your mysqld.err logfile, and follow the migration procedure in the news item: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2010/2010-02-21-mysql-upgrade/2010-02-21-mysql-upgrade.en.txt?revision=39&view=markup > ps: what is crazy guy disable innodb again? he just pissed me off :(((((((( > what reason was to do that? no, seriously???!!! Because mysql is "compiling > long time"??? imho, this is totally brain off reason. > pps: innodb transactions is standard for present days. 1. _NOBODY_ disabled InnoDB in the Portage tree. 2. This is a professional forum, please discontinue the rant. 3. Your issues really belong on a new bug, NOT a bug that was closed 5 years ago.
