Red Hat Bugzilla – Bug 187842
MySQL 5.0.18 on FC5 does not have archive engine enabled
Last modified: 2013-07-02 23:09:06 EDT
Description of problem: The MySQL server contained in FC5 final release has the ARCHIVE engine disabled; I understand rectification of this requires a recompiliation with a flag. I'd much prefer to use a distro binary! This problem ("Archive not enabled on linux binary by default") was raised on the relevant MySQl forum 2005-Oct-14: http://forums.mysql.com/read.php?112,49448,49448#msg-49448 and was immediately responded to (by Brian Aker, presumably a MySQL team member) with "I've mentioned this to our build group and they are fixing the problem for the next release." Seems it didn't happen. (:-(( [FYI: MySQL ARCHIVE engine is enabled by default on the Windows binary.] I don't know whether this is mainly an issue for MySQL folk or Fedora folk, but I'd guess M's need to fix it and F's need to issue it. Version-Release number of selected component (if applicable):5.0.18 How reproducible: Easily... Steps to Reproduce: 1.Load and start mysqld from FC5 final release 2.Connect with mysql client 3.SHOW VARIABLES LIKE 'have_archive'; Actual results:NO Expected results:YES Additional info:I have re-raised this on the MySQL forum: http://forums.mysql.com/read.php?112,49448,80365#msg-80365 No response yet as I write. My thanks to Rahul Sundaram for directing me to re-raise this here. To me, the priority of this issue is high, as I cannot easily advance my project without ENGINE=ARCHIVE, and I would much prefer NOT to have to go into compiling a fresh version and replacing the existing one.
MySQL AB doesn't build the Fedora RPMs, although I believe they do offer RPMs that will work on Fedora and are built the way they see fit ... so you might want to see what they have. Fedora's mysql RPMs are built essentially as testbeds for eventual RHEL releases, which means we're fairly conservative about what compiler flags to use and what optional features to enable. In this case, if you want the archive storage engine enabled, you're going to have to convince me why it's something we need to support in RHEL. I haven't gotten any previous requests for it AFAIR, which makes it seem pretty low-priority to me. [ checks bugzilla... ] Actually, there's bug #173253, but given the lack of apparent interest I don't think that request is going anywhere.
Tom, thanks for your very prompt response. (Sorry I had not spotted 173253.) I doubt if I alone can convince you to support ARCHIVE engine in RHEL. You would want "me too" from lots more FC and RH MySQL users. I collect traffic data and want to squash it onto as few DVDs as possible for long term archiving. MyISAM>>ARCHIVE gives my data about 10::1 compresssion, as the data is compressed and the indexes omitted. And yet the tables can still be (serially) read, so it seems a good way to go. I guess I'll either need to learn to compile MySQL and replace the distro version, or devise another archive path.
Colin Charles (byte@fedoraproject.org) made a brilliant suggestion which i also like to see: Include the "mysql-max" rpm into extras for the additional storage engines. Especially the cluster-storage engine will become more popular as the version is now ready to be used in production.
*** Bug 216096 has been marked as a duplicate of this bug. ***
I agree, new storage Engines are really usefull. I'm used to rebuild MySQL from Fedora SRPM to enabled them. mysql-max probably could not go to Extras as it will "conflict" with mysql. We probably have to wait for mysql 5.1.x which support Storage Engine as entension. Regards
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.