Update 3 June 2008: We have removed the builds below, since they are quite obsolete and no one has posted comments about them since more than a year ago.
Great news are MySQL finally released new Community release – MySQL 5.0.33, which however as promised comes without Binaries.
This version also does not have any community patches yet, coming of the same tree as MySQL Enterprise.
To help those who would like to use MySQL Community version but does not like to build binaries we decided to publish our build for MySQL 5.0.33 Community release.
This build was done using “Generic Linux RPM” spec file on CentOS 4.4 (RHEL compatible) x86_64
(Links removed)
We added one more RPM to stantard MySQL RPMs – MySQL-microslow-5.0.33-0.glibc23.x86_64.rpm
This package contains mysqld-microslow binary, the server built with our microslow patch, which enables microsecound in slow-log.
More info about the patch
https://www.percona.com/blog/2006/09/06/slow-query-log-analyzes-tools/
http://bugs.mysql.com/bug.php?id=25412
Also we propose Linux (AMD64 / Intel EM64T) binaries in tar.gz archive
(Link removed)
The archive contains both mysqld and mysqld-microslow binaries.
Source tar.gz with microslow patch
(Link removed)
The patch by itself
(Link removed)
We are waiting for your response if our binaries are helpful and if we should make binaries for other platforms / Linux distributions or if you would like to help us doing builds.
I’ve already produced RHEL4 specific RPMS based on the official MySQL spec file they had for RHEL.
A windows build which I’ll zip up is also compiling as we speak.
http://server.macvicar.net/downloads/
Thank you Scott,
Your binaries are i386 though, the one we built are x86_64
The purpose of using general RPM specs to have them more suitable for other Linux versions.
Great you’re building Windows version.
I had a generic build on i386 running but it stalled twice during the final packaging, I’ve kicked off another set on our RHEL4 box for the generic RPM version, should be done by the time I get home.
Do you guys have a version of this patch that works for 5.1 hiding around anywhere?
Monty,
No we don’t have.
The logging module was changed in 5.1 so porting the patch to 5.1 is complicated task.
Maybe somewhere…
Good job, guys. I was looking for an i386 flavour too for my servers, and both your packages and Scott’s are downloading right now. Perhaps a single repo for future packages so you could distribute the workload…
I don’t seem to find anything in Scott’s WIN32 folder… But thanks anyway.
And yes, a common repository would be nice. On sourceforge.net, perhaps?
A Windows 32 build is now in the process of being uploaded, its a MySQL-NT release build and a debug build is compiling, that will go up later.
I’ve also now included generic i386 rpm builds to go along with the RHEL4 specific i386 builds.
Thanks for these. They are GREAT appreciated! Hopefully you guys can bring us the latest RPMs/MySQL updates in the future too.
How does the configure lines looks like for the mysqlperformanceblog versions including CFLAGS etc?
Apachez
I used configure line from latest MySQL binary release:
./configure ‘–prefix=/usr/local/mysql’ ‘–localstatedir=/usr/local/mysql/data’ ‘–libexecdir=/usr/local/mysql/bin’ \
‘–with-comment=MySQL Community Edition – Standard (GPL) – build http://www.mysqlpeformanceblog.com‘ ‘–with-server-suffix=-standard-mpb’ ‘
‘–enable-local-infile’ ‘–with-pic’ ‘–with-fast-mutexes’ ‘–disable-shared’ ‘–with-zlib-dir=bundled’ ‘–with-big-tables’ \
‘–with-yassl’ ‘–with-readline’ ‘–with-archive-storage-engine’ ‘–with-innodb’ ‘–with-extra-charsets=complex’ ‘CC=gcc’ ‘CXX=gcc’
Andrisi,
Yes, common repository is good idea,
we will think what to do if our binaries will be popular.
Hmm so no gcc stuff like O3, march etc?
Vadim you did not mention CFLAGS and CPPFLAGS which are important part.
In any case it is same as setting “General RPM” which MySQL build team builds which means it should be reasonably optimized but with no special optimizations for Opteron or Intel Xeons.
Peter
I did not mention CFLAGS and CPPFLAGS as I did not used them
I think it’s just -O2 -pipe -m64 (without -fomit-frame-pointer) if built on CentOS with rpmbuild, unless configured otherwise.
The myth that official RPMs are optimized is just a myth. 🙂 No one cares about extra 1% CPU time, so it’s optimized for compatibility.
Um… looks like directory settings:
‘–prefix=/usr/local/mysql’
‘–localstatedir=/usr/local/mysql/data’
‘–libexecdir=/usr/local/mysql/bin’
are completely different to what we used to on RHEL4/CentOS4.
Alexey, I mean they should be reasonably well optimized. Normally 1-2 percent does not make so much difference especially on IO bound workloads 🙂
The directories are from “Generic RPM” which I guess is why they are different. It is build on CentOS but these are not CentOS RPMs.
Building ones with RHEL RPM Specs should be best if you want compatibility.
1% here, 1% there… and *poff* the binary becomes in the end twice as fast as the rpm version 😛
I showed options for .tar.gz binary, not
for .RPM
RPM params:
sh -c “PATH=\”${MYSQL_BUILD_PATH:-$PATH}\” \
CC=\”${CC:-$MYSQL_BUILD_CC}\” \
CXX=\”${CXX:-$MYSQL_BUILD_CXX}\” \
CFLAGS=\”${MYSQL_BUILD_CFLAGS:-$RPM_OPT_FLAGS}\” \
CXXFLAGS=\”${MYSQL_BUILD_CXXFLAGS:-$RPM_OPT_FLAGS \
-felide-constructors -fno-exceptions -fno-rtti \
}\” \
LDFLAGS=\”$MYSQL_BUILD_LDFLAGS\” \
./configure \
$* \
–enable-assembler \
–enable-local-infile \
–with-mysqld-user=%{mysqld_user} \
–with-unix-socket-path=/var/lib/mysql/mysql.sock \
–with-pic \
–prefix=/ \
–exec-prefix=%{_exec_prefix} \
–libexecdir=%{_sbindir} \
–libdir=%{_libdir} \
–sysconfdir=%{_sysconfdir} \
–datadir=%{_datadir} \
–localstatedir=%{mysqldatadir} \
–infodir=%{_infodir} \
–includedir=%{_includedir} \
–mandir=%{_mandir} \
–enable-thread-safe-client \
–with-readline ; \
–disable-shared \
–with-zlib-dir=bundled \
–with-extra-charsets=complex \
–with-comment=\”MySQL Community Edition – Standard (GPL) – build http://www.mysqlperformanceblog.com\” \
–with-server-suffix=’%{server_suffix}’ \
–with-archive-storage-engine \
–with-innodb \
–with-big-tables
I took it from generic mysql.spec file from MySQL release, so
our RPMS should be compatible with MySQL generic RPMs.
Apachez,
You may spend time rebuilding your binary hopping for massive boost. In practice if you have to changed complier few percent is maximum what you get.
There are many people who just like to build stuff on their own and looking for reasons why it must be done 🙂
Of course, if you do make it twice as fast, be sure to let MySQL know so it can be included in the normal release. 🙂
http://forge.mysql.com/wiki/MySQL_Build_Farm_Initiative
No binaries… but using our PCs for testing? 😕
Andrisi, it’s a build farm. This topic seems to be about building something.
Yes, yes I understand. Build something. Test the building procedure. And have binaries as byproducts?
BTW… I’m not an exprert in building MySQL, but as I imagagine, building installers (rpm or exe) can be automatized, isn’t it? Why is it such a big deal to do it? Could someone light me up (or us) in this? What are the difficulties beside having a proper build enviroment set up once?
I think I missed the original announcement on this, so please forgive my confusion. Is MySQL not providing binaries any more for any community releases? Or will it only be specific releases?
ie, do I need to set up a build machine to continue using MySQL?
Thanks!
Jason, some community releases will be source only, some will be binary as well. A source build was released recently, I’m expecting (not guaranteed!) the next one sometime next month. The big schedule change has been the introduction of somewhat guaranteed monthly builds for Enterprise customers. Also the Community server builds will contain end user code that won’t be in the Enterprise releases because incorporating enhancements would breach their stability objective – which largely prohibits introducing non-bugfix code.
Andrisi, building is scripted but a full production release is actually lot of work and takes at least a week of some members of the build team’s time per release, so their time limits how many full builds can be done. Source releases are much less time-consuming and don’t tend to use resources needed by other ongoing builds that must be deconflicted. The work isn’t so much the builds, although they take a while, there’s also the testing and fixing of problems that show up in them and it’s really easy to underestimate how much time it takes.
James,
Thanks for the clarification. So community builds will tend to be more cutting edge and *possibly* less stable? ie, Fedora vs RHEL.
Enterprise releases won’t be available for general download in binary form? Or both binary and source?
Jason,
The question of stability of Enterprise vs Community is good one, and the true answer will be – it is yet unknown. It will depend on number of factors, for example what kind of community patches MySQL will accept for community version, how solid they would be ? What kind of testing Enterprise version will get compared to Community – remember Enterprise goes out first as a binary, opposite to Fedora/Redhat case so Enterprise users will act as beta testers.
But as it is no there should not be much of the difference as Community and Enterprise is still the same source tree.
Jason, right. The Community builds will probably be a bit less stable. On the other hand, they will have user features before those features can be incorporated into the next release of the production server version. So today you can’t get a user feature into Enterprise 5.0 but you may well be able to get it into Community 5.0, because Community 5.0 can take more risks than Enterprise. Not being able to get things into the production releases has often irritated people who want to be closer to the cutting edge and this is one attempt at a solution. We’ll see how it works out. Hopefully it’ll show that those features are stable and really popular and they’ll be incorporated into the next full release.
Enterprise binaries will only be made available by MySQL to Enterprise customers, along with the source for anyone who wants it.
James,
You are speaking like a marketing guy 🙂 Do you still work in MySQL Support ? 😉
Well, how many community patches you expect will be included in Community release next year ?
Vadim, I’m naturally an optimist and here I’m speaking in public so I have to try to be nice. 🙂 Besides, all I did was explain the plan. I don’t know if it will work, but it is the plan.
I have no good idea about how many community patches will be included in the next year. I would be surprised if it was more than 100 or less than 5. But maybe I will be surprised.
James
Yes, I understand your optimism 🙂
However I’m pessimistic in this case and I will be surprised if more than one-two patches will be included in Community server this year. Anyway there are 11 months to go, will see 🙂
Hey dudes,
Is there anyway you can publish your spec file or src.rpm ? I want to recopile mysql 5.0.33 with sphinx SE.
John,
Here is it
http://www.mysqlperformanceblog.com/files/binaries/5.0.33/mysql-mpb.spec
Hi Guys,
I’m trying to compile this under Solaris 10 AMD64 without success.
I can successfully compile MySQL 5.0.33 source.
Compiling your source gives the following error. Any clues into correct the openSSL problem would be greatly appreciated.
then mv -f “.deps/vio.Tpo” “.deps/vio.Po”; else rm -f “.deps/vio.Tpo”; exit 1; fi
In file included from vio_priv.h:24,
from vio.c:24:
../include/violite.h:95:30: openssl/opensslv.h: No such file or directory
../include/violite.h:106:25: openssl/ssl.h: No such file or directory
../include/violite.h:107:25: openssl/err.h: No such file or directory
In file included from vio_priv.h:24,
from vio.c:24:
../include/violite.h:111: error: syntax error before “SSL_CTX”
../include/violite.h:111: warning: no semicolon at end of struct or union
make[2]: *** [vio.o] Error 1