Archive for the ‘Mysql’ Category
Okay, boo hoo, Sun and MySQL got married with Jonathan wearing the oddest of wedding dresses and doing the oddest of post-wedding kisses. This has not drawn the warmest of bear hugs from the PostgreSQL fans (okay, I am one, shoot me!), newly uncertain in the fear of the loss of PostgreSQL’s status as Sun’s preferred OSS RDBMS mistress, now that MySQL has become the preferred OSS RDBMS partner.
The story, I am afraid, is not as simple as that. This move by Sun is not something that can be seen in isolation — it is a just piece of larger pie that Sun is chasing after, which is to recreate the Apple experience on open source software that scales seamlessly from one end of the market (the proof of concept) to the other extreme (enterprise-grade technology).
What Sun wants you to do is to get you started on OpenSolaris when you are a one-man start up, backed by a well integrated stack (they already have helped out the RoR community regarding their scaling woes) and watch you grow till the day you need the beefy servers and storage that is required by any reasonably large online business.
In the picture they are trying to patch together, the code and the components involved will work through this upgrade path without much change, resulting in near-zero disruption or refactoring on the code base. Essentially, what they are aiming for is to reproduce the Apple mantra “It just works” in a segment where such a feature would bring in considerable savings.
But why MySQL? Well, for one it is a proper company. Big companies and their boards love to buy things (especially when they are shelling out a billion dollars) which are a bit prim and propah. Moreover, it also makes it easier for them to integrate both operations. But, more than anything else, Sun needed a widely-used database to finish the stack — something it could own — and you can’t talk about ‘owning’ PostgreSQL without having a good laugh even while you are speaking about it.
Moving on, this is a play that is not meant for the current year. This is something that will only play out some two years down the line and these are the reasons why:
- There is nothing that stops the average start up from using the average $300 a pop dedicated server to flag off their operations and move into the monster servers and server farms at a later stage. But anyone who has done it will tell you that it is a painful experience for which there really is no manual you can look up and replicate.
- Software, by itself, is hard to tune. It is easy to write your first PHP script and run your website, but PHP itself can be tuned in different ways. There is a fair bit of learning that is repeated here with almost every start up and that is time and effort (translating into additional costs) that can be saved when cash is pretty sparse. The same is the case with HTTP servers, databases and application servers.
- A lot of software tuning is highly dependent on hardware. And at high performance levels, even marginal differences on every instance you run can result in significant savings. Moving from a 32 bit architecture to 64 bit architecture can result in significant heartache (let us not start into the ‘lib’ mess that Linux distros can get you into when moving from 32 bit to 64 bit), which is okay when you run about a dozen servers, but as you get closer to the three digit figure this can be a traumatic experience you’d not want to wish on even the worst of your enemies.
Now, imagine a vendor who can accomplish the same for you (also known as a very controlled environment), where things just work. If Sun can guarantee a pain-free seamless upgrade path from an OpenSolaris platform to Solaris proper that will run on Sun’s more expensive rigs, they would have a winner on their hands. And that is the sweet spot Sun is aiming to be in two years.
Related: Give Me a M: The MySQL/Sun Q&A
Update: Updated post (on December 11, 2008) here.
- We won’t be running any binary installations, all software will be compiled from source.
- The installation won’t make use of Fink or Darwinports either.
- These are instructions for the Intel Macs.
- Using this approach would mean that you will need to maintain the stack by hand.
- Use this information at your own risk.
- If you don’t want to go through all the trouble and use a binary installation, read this post.
The software stack we are going to install will be as follows:
Apache HTTP Server 2.2.6
MySQL 5.1.22 RC
We will also need to install the following software dependencies:
- Xcode (from the Leopard DVD or Apple Developer connection )
- Readline (http://tiswww.case.edu/php/chet/readline/rltop.html)
- Tidy (http://tidy.sourceforge.net)
This installation would not have been possible without help from the following websites:
- Installing Readline on OSX without using Fink or Darwinports
- Workaround for Tidy’s platform.h problem
- Installing the GD library on OSX Leopard
Now to the installation:
Download mysql-5.1.22-rc.tar.gz from the http://dev.mysql.com website
$sudo make install
Update: The steps did help me in getting to install the server, but on start up it did give certain location-specific errors.
As Hill has pointed out in the comments, MySQL.com has not released a version of their software for Leopard, but I got 5.1.22 RC to install, run and connect from PHP without any hassles following the instructions in one of the links he had kindly posted.
Download the source from ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz
There are bugs with the installation as elaborated in this link with workarounds:
$sudo make install static
Download the source from http://www.postgresql.org
$sudo make install
Follow the instructions at Veola.net
$CFLAGS="-arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk"
if you get an apr.h error regarding sendfile, edit the apr.h file in srclib/ext/includes and change APR_HAS_SENDFILE to ‘0’
$sudo make install
--with-snmp=/usr --enable-exif \
$sudo make install
And that’s all folks!
Update: New post on installing from source here.
Getting Apache 2, PHP 5, MySQL 5 and Postgresql 8 on Leopard was not as easy as it was made to look, so I am noting it down so that it could help somebody later.
This does not deal with installing PHP or Apache from source which can be a bit hairy on OSX.
This was done on OSX Leopard, I have no idea if the same will work on Tiger, Panther etc.
Follow the instructions at your own risk. It did not blow up my Macbook Pro in doing this, but I can’t guarantee you that you’ll extract the same mileage.
All binaries have been downloaded from Marc Liyanage’s website (thanks Marc!):
- Download the respective packages from the website
- Install them according the instructions
- Stop the httpd that is shipped with leopard (sudo /usr/sbin/apachectl stop)
- Backup existing PHP module: cp /usr/local/apache2/modules/libphp5.so /usr/local/apache2/modules/libphp5.so.orig
- Replace with the Entropy version: sudo cp /usr/local/php5/libphp5.so /usr/local/apache2/modules/libphp5.so
- Backup existing php.ini: cp /private/etc/php.ini /private/etc/php.ini.orig
- Replace with the Entropy version: sudo cp /usr/local/php5/lib/php.ini /private/etc/php.ini
- Edit the httpd.conf in /usr/local/apache2/conf to load the PHP module
- Back up existing httpd.conf in /private/etc/httpd
- Replace it with the version in /etc/local/apache/conf
- Start Apache
I know it is not the best or the most proper way possible. But after many days of poking around, this was the easiest and I am not one to complain about that.