MyISAM to InnoDB Conversion: Converting almost a billion records

So my challenge last week was to convert almost a billion records in 37 databases and 74 tables. Oh, and I wanted to do it only during the night (between 12:30AM and 6AM) and in the least number of nights.

This was not my first massive MyISAM to InnoDB migration, nonetheless, I still manged to learn a few things. We're at a stage where MyISAM just isn't the solution any more. Our plans are to go almost 100% InnoDB and this migration project completes yet another massive step towards that direction.

The first night was depressing. I applied every trick up my sleeve but only ended up getting 9.48% complete. Second night was only half depressing allowing me to complete ~ 33%. Third night was a charm and I got ~42.5% done. I would have finished the project that night but there was some storage issue and so I completed the last ~15% on the fourth day. Of course, optimizations and the method of conversion I selected really saved the day in the end.

Now that this has been accomplished, the next step will be to cover another 700-900 million records in a different cluster. Oh well, I will start doing that this weekend.

As far as performance is concerned, I couldn't be more happier. Load average on all servers in this cluster is well under 0.30 and each server is happily doing upto 1800 queries per second.

Note: Indexes were not dropped. Primary key did not consist of an integer. There was a composite primary key on all tables. The servers continued to handle production traffic on all databases on which migration was not being performed.

Update: What I did in a nutshell, for very large tables, was:

1. set innodb_flush_log_at_trx_commit=0 in my.cnf and restart
2. create new table tbl_innodb
3. set sort_buffer_size and read_rnd_buffer_size

SET SESSION sort_buffer_size=512*1024*1024; 
SET SESSION read_rnd_buffer_size=512*1024*1024;

4. then insert into tbl_innodb selecting from tbl_myisam and sorting by primary key
5. rename tbl_innodb to tbl

Of course, you need to have sufficient memory or adjust the buffers accordingly. But doing this ended up working great for me.

Update2: Regarding read_rnd_buffer_size, MySQL Manual says,

"If you are performing GROUP BY or ORDER BY operations on tables that are much larger than your available memory, you should increase the value of read_rnd_buffer_size to speed up the reading of rows following sorting operations."

Peter Zaitsev has also written about read_rnd_buffer_size.

Update3: My system (Solaris 10) had 10G of memory and read/writes were done to mounts residing on a SAN.

Update4: Best case scenario was 9600 records / second on average. Worst case was 500 records / second on average.

Did IBM's ERP implementation drive American LaFrance bankrupt?

American LaFrance has filed for Chapter 11 after not being able to properly migrate from their ex-parent company's ERP system to a new one that was being implemented by IBM. They said that the new system caused production disruptions and left the company with a $100m debt. The company is now taking action "based upon services provided by IBM in connection with the problem-riddled transition to the ERP system."

Hmmm... since the transition was done last year, I wonder whether IBM really is to blame? Did they not have a QA environment?

MySQL dumped - Oracle loaded - Whose fault is it?

The purpose of this post isn't by any way to bad mouth MySQL but rather to show the impact of lack of qualified DBAs to those who use MySQL.

I was shocked last year, when a CTO of a large company confided in me and said basically that they are so tired of searching for qualified MySQL DBAs that they may switch to Oracle. At some point, I guess the frustration alone can justify an otherwise unneeded cap-ex of such magnitude.

Today, I hear that ValueCentric, a pharmaceutical technology consulting firm based in New York, has decided to let go of MySQL in their environment and instead switched to Oracle on Oracle Linux.

"as the firm expanded and began taking on bigger clients like AstraZeneca, Roche and P&G Pharmaceuticals, company officials became concerned over MySQL's ability to keep up with rapidly growing data stores and complex quality-of-service requirements."

Now, MySQL may not be an ideal fit for many

"We were faced with some pretty big issues around performance, both in processing and on the back end, as well as reporting, where we had problems with queries returning on time and being able to handle the processing of data at night -- or whenever it came in -- in an expedient manner," Janca explained. "We needed to step back and see where we were headed strategically, do an assessment and try to remove some risk that we thought we had in continuing down the path with MySQL."

This gives the sense that MySQL cannot hold up as a company grows. However, to me, it seems like they had someone with little or no MySQL experience working on it. Or worst, their data architect did a horrible job of architecting their data and reporting environment. Or even worse, they hired services of a consultant who showed them the only way out of their issues was MySQL. There isn't a shortage of such consultants, you know.

Folks, MySQL is a tool and you need to know how to use that tool to get the job done. Just because you have been able to successfully open a tool doesn't mean that you know how to use it.

No one argues the need to have a competent DBA when one is using Oracle. However, the notion of Open Source makes people somehow believe that MySQL should run great out of the box even if the database architecture of the company sucks.

One of the biggest mistakes companies and IT managers make, IMHO, is to hire a data architect with minimal MySQL experience. They think their data can be architected by someone who doesn't necessarily has the expertise with underlying database. This can be a disastrous call as a competent data architect must possess an in-depth knowledge of the underlying database.

ValueCentric had also become disenchanted with MySQL's disaster-recovery capabilities and support services, added John LoFaso, ValueCentric's director of technical operations.

Those of you who attended my talk at MySQL Camp II, know the hell I went through on 7.5.07, when our SAN crashed leaving more than 1TB of InnoDB data severely corrupt (won't stay started even with innodb_force_recovery set to 6). For sure, I wasn't able to tap any readily-available resource to recover from this disaster. However, I was able to write programs myself to extract data from InnoDB tablespaces and the recovery rate was truly impressive. However, I realize not everyone will be wanting to write programs themselves especially in the times of extremely high stress (i.e. when disaster has occurred). This is one area that is definitely still ignored by MySQL. Peter Zaitsev recently blogged about releasing a DR tool for InnoDB however, I don't think that has happened yet.

"The support was very sketchy, and we just couldn't rely on it," he said.

Ok, since this is a somewhat touchy subject, for me and many others so I will mainly let it pass. I do however feel that you need to have the highest support plan to really get MySQL to help you. We, for one, have paid for support but hardly use it (MySQL software is so great).

I find it pretty amusing that while people use MYSQL, their budget for MySQL support is just pennies compared to when their support budget for Oracle. I believe had they spent same amount of resources on MySQL support, they would be a happy MySQL user.

One thing I will say is that we are preferring to bring in independent consultants for our next major project, though, that may/may not qualify as support to some.

So in case you are wondering why ValueCentric didn't go with Microsoft?

"because of "impersonal" support operations" and because "The goal was that we needed a partner, not an 800-number"

I believe in one thing: MySQL has a remarkable community, remarkable product, remarkable leadership and a remarkable vision so why not make the support remarkable as well? Right now, it may be great support, but it certainly isn't remarkable. And to know the difference between great and remarkable, well, you gotta read Purple Cow. (hint: they are both opposite of each other).

Going back to the shortage of competent MySQL DBAs, this is something that, I think, MySQL can artificially overcome by making their support remarkable.

However, to be fair to MySQL, the support is all there, however as with most things in life, it has a price. Ok, I seem to be in a catch 22 situation so I guess, enough for today.

BTW, thanks Ronald, for giving me Purple Cow as a gift in 2006. The book has really changed my view of thinking.

Fotolog crosses 400 million photos!!!

Just a few hours ago, Fotolog crossed the 400,000,000 photos milestone. Considering that free members can only upload one photo a day, that's a lot of dedication by 14.5 million members (and growing).

Vendor Neutral Database Certification?

Dave wrote about new vendor neutral database certification, or as I like to call it "Jack-of-all-trades-but-master-of-none certification "

spotting the wolf in sheep's clothing

This is all my personal rant based on my little investigation as I have been very upset.

If you're the one who I am targeting this post to: please don't take it personally. You have no one but yourself to blame for this backlash.

==start rant==
So, Looking at the sites of one-who-shall-not-be-named-or-linked-to-any-more or aka wolf in sheep's clothing, I am coming to an opinion. To me, it seems like he is basically using his sites to benefit his current and/or future clients. He also seems to be a DMOZ editor or very closely associate with it, something that really hurts his credibility in my eyes. DMoz should be shredded by now as it has absolutely no value other than to lame SEOs who still either beg editors to get their site listed or enjoy being begged to. Even the parent company of DMoz has no interest in it. I mean come on. If you are 1% serious in your "database research" business you wouldn't spend time working on getting your client links into Dmoz, knowing the massive corruption that exists within Dmoz. I have dealt with Dmoz bullshit and know anyone who really values time would stay away from it.

To me, it is only a heaven for Internet marketers who try to show-off to their prospective clients about their control over certain categories and who knows, may be it even helps them get more money to write more biased posts.

Ever since Google launched Bourbon update, Dmoz and Dmoz based directories lost its value. Whoever told you that Dmoz is still powerful is just entering the SEO world. It is a base for every scraper site out there. Once you land on those scraper sites, you are asking for trouble.

To help with an analogy for the lack of better words: If you are associated with red-light district then people are going to point fingers when you go to church looking all innocent.
P.S: I don't go to church but it gets the point across

Do yourself a favor and leave DMOZ and instead start playing with MySQL or start researching your MySQL articles before posting them to an aggregated blogs community. May be now that MySQL is owned by Sun, they can give you a free Sun box and MySQL subscription to curb your ignorance about MySQL.

The guy's last three posts were the biggest waste of my time since this. I mean how do we even let people like this on Planet MySQL? To me, he is definitely interested in keyword and company plugs rather than an honest, objective review of a database that is my bread and butter. And MySQL being my bread and butter is the precise reason I am so mad about his posts. Talk about entering a community and losing respect within a week. We don't need your un-researched and biased commentary. No matter what you say, it will not make me or hundred of thousands of websites to stop using MySQL and start following you. It only makes you look bad. I mean he won't even dig up past presentations or research articles and instead ask people if they know of any one using MySQL in a mission critical environment. Ughhhh! Do your homework yourself dude.

May be there should be a moderation system where the community can mark such biased posts as 'flame bait' and after wasting enough time of the community with their stupid flame baits, they should be kicked off of Planet MySQL. Also for those who pimp their blogs, even once, there should be a badge saying 'pimped' similar to the 'employee' badge.

Last, but not least: If you don't know how to work with MySQL, don't say MySQL doesn't work since both have different meanings.

==end rant==

I may sound upset but honestly, I am tired of seeing people just loosing their conscious and saying whatever comes in their mind. Grow up!

Update: Ending thoughts: Not everyone in MySQL community loves everything about MySQL. Jeremy, Peter Zaitsev, Baron, Ronald, Roland are fierce community critics. However, their critique is always well received because it is based on some solid observation, experience or research. It is that kind of well-researched, fact-based critique that calls for discussion and dialog. Poorly researched and biased critique just wastes the time of everyone and no one gets anything in the end.

Update3 (Update2 is on top): Oh, how can I forget the numerous Planet'eers who drive this constructive-criticism-demanding community. Thanks also goes to Mark, Giuseppe, Beat, Sheeri, Keith, Kevin, Colin, Brian (Kelley and Aker), Mark and many others for providing factual based criticism. You should read all their blogs for an educated decision of whether MySQL is right for you. These are people who actually use MySQL in their jobs.

Update4: added links to constructive blogs

Hammer and Nail

To Curt Monash, in response to his latest attacks on MySQL, all I have to say is:

"Those who just know how to use a hammer, approach every problem as if it were a nail."

Maria released

Monty has announced on his shiny new blog that Maria is now available.

He says, "No clustered keys on roadmap."

Ah! that's the one thing I would have liked a lot. The benefits we have achieved with clustered keys are so awesome, I can't think of a good reason to reverse them. So as far as I see, Maria won't be a possible future InnoDB replacement until this is added. But other than that, it sounds that Maria is coming along pretty good.

Welcome Monty!

Finally, the wait is over. "The" Monty has started blogging. Welcome, Monty!

I WILL NOT BLOB

A comment was left for me by Roland and that made me want to write my thoughts.

My thoughts have changed on this topic over time. Primarily, because I now work on a large scale infrastructure where I can see how things would have been if BLOBs were stored in database. Most of the following discussion keeps the size and scale of my work load in mind and is targeted towards those who are interested in evaluating BLOBs for a work load, access patterns, budget and performance requirements similar to ours. The following are my thoughts and opinions.

When I started my current job, we were near 4 million members and just over 100 million photos. There were a lot of performance issues at that time. Today we have 14 million members and reaching 400 million photos and topping 152 million page views a day with at times reaching more than 900,000 photos a day and 8.9 million comments a day. During this time, on the database end, we only recommissioned one new test database server as production server in our guestbook cluster. Other than that one "addition", all our growth is being currently served from the same number of purchased servers/instances in our photo, friend/favorite and guestbook clusters. In that sense, one can say we have been scaling up with MySQL and Solaris 10 on Sun hardware.

There are more than available features, cost and quantity discount factors to take into account when making a decision about the DBMS that should be used for a particular environment and architecture. Just because a data type (that you weren't going to use) is available in a DBMS, shouldn't be the reason to pick it.

When you're in charge of data, you have to wear many hats to make decisions. As a data architect, your job is to take a principle based approach that is not influenced primarily by what extra features a DBMS offers but rather takes into account the "organization's strategic goals," and its budget. Experience in architectures is an important requirement to being an effective data architect as an approach considered optimal in one environment may not be equally ideal in another environment especially given unique constraints of each organization. Same is true from a database administrator point of view except that now maintainability, performance and scalability requirements are of utmost concern to you.

I was not the decision maker when my company decided to store images on file system, however, I couldn't have been more happier. If given the choice tomorrow, I would go with the decision of keeping photos outside the databases.

For an extreme high performance environment like ours where there is constant explosive growth, BLOBs could not have been the SOLUTION. In fact, had we stored nearly 400,000,000 photos (we are about to reach that milestone probably tomorrow) in *a* DBMS, we would be not only be crippling our performance and forcing our existing database infrastructure to become mostly unusable. For us, it's not just about storing 400 million photos. It's also about handling load that is generated by serving more than 4 billion page views a month. I would be very interested in seeing if any company, that is similar in specs like us and has intense performance requirements per server, like ours, uses BLOBs to store their images.

The concept of databases is generally suited to storing a very large number of objects that are small in size. Here, both "very large" and "small" are relative to each industry and requirements of the system. When you look at overall picture, file systems are more suited to handling large objects, especially if the large object consists of an image.

The decision of whether or not to store images as BLOBs MUST NOT BE DONE based on what your DBMS offers (even if its Oracle, SQL Server or MySQL). If you primarily base that decision based on your DBMS offering alone, you have done a great disservice to your organization in my opinion. The decision should be based on your performance requirements, scalability needs, ease of maintenance, cost of future features to be added to the application etc., and not on what you are more comfortable using.


Just for a moment, we have to think outside the box to be able to understand the argument of why storing BLOBs in file system is a wiser decision especially in a data-intensive web based environment.

When a client browser requests a page, it parses it out for presence of any media files and then makes a separate request to retrieve and display each media file. Typically, you can query the database for the data elements and then for each media request made later, simply use the file system to serve the request. If, however, you store media files as BLOBs, then for each media request you will need to communicate with database to get the contents of the requested media file. This can put unnecessary load on your database and increase I/O contention on your database server. Then, suddenly, you have your database server doing a lot of IO activity and your plans to keep disk I/O to minimum and serving your working data set mostly from memory goes hay wire. Some would argue that the cost of opening files is greater than accessing it from database but I wonder how long that would hold true for large media files.

For my company the size of the images is in double-digit (TT) terabytes. The size of databases is in multiple, but single digit terabytes (T). It makes no sense to me now that a database administrator would agree to bloat their databases to add TT more terabytes when they could have kept them at T terabytes and kept the other TT terabytes away from the database.

Unless the BLOB is kept in a separate table, say photo_blob, from the main table, say photo, you are going to make schema changes a nightmare for yourself, since you will be performing migrations on an additional TT terabytes. Suddenly, upgrading your database to a new version would seem like a slow walk in hell.

Same remains true for backups of database servers. By keeping the media files away from your database, you relieve your database from having to process TT terabytes of data for backup purposes which can be performed separately using file system backup tools.

If you use snapshot software to take database backups, there is something else to worry about. Snapshot utilities such as fssnap can create snapshots very quickly but as data is written to the original volume, the backup store files are also updated. This means in large environments as write load on database increases, so does your performance issues while the snapshot is held. With BLOBs you are now keeping snapshots much longer on database server so the additional TT terabytes can be backed up. While this happens, your performance will keep crippling. Instead of releasing snapshots within 5 hours, you are now waiting more than 24 hours. Yes, you will still have to backup the TT terabytes of media files, but at least you won't be making it the headache of your poor database server who already has so many things to worry about. By keeping media and its associated metadata separately, you can apply optimal backup techniques to each environment.

Oh, and what happens when you have to reset replication and move extra TT terabytes to slaves?

And let's not forget about disaster recovery issues where you need to recover data from crashed databases. More than half of your data would avoid having to be recovered in case of a database crash, if stored on a separate file system.

As we move towards higher and higher resolution devices, the size of the media files will continue to grow. 20-30MB image files are not rare anymore. Do you really want to store high resolution media in your database? If not, will you store low resolution media in database and high resolution on file system? Why?

Then there is the whole issue of fragmentation of database storage compared to file system storage. Not to mention making a mess by mixing sequential I/O and random I/O instead of separating them and benefiting from the separation.

This is not just an issue with MySQL. A 2006 study conducted by Microsoft researchers states:

"One surprising (to us at least) conclusion of our work is that storage fragmentation is the main determinant of the break-even point in the tradeoff... In essence, filesystems seem to have better fragmentation handling than databases and this drives the break-even point down from about 1MB to about 256KB."

What about Portability? Image formats such as PNG and JPEG are platform independent, whereas your database files may not be.

Of course, there are issues with garbage collection when you store your media outside of database. However, these issues should be trivial to solve for any experienced developer.

The decision to store BLOBs on file system makes even more sense from financial point of view. If an organization of our size was to move to Oracle or SQL Server, then they can significantly reduce their licensing costs by storing TT terabytes of media files on file system. I wonder how much our Oracle licensing costs would be to store and serve TT terabytes. Even with MySQL, our license fee for support would be significantly more for additional servers employed to serve TT terabytes of media.

I'll end with this thought: If you're storing your BLOBs, especially large media files in database, aren't you choosing the most expensive file system available?

Further reading:
To BLOB or Not to BLOB: Large Object Storage in a Database or a Filesystem.
To BLOB Or Not To BLOB by Deep Select.
When to put images in MySQL by Sheeri

Spider-Man or Telepathy?

(Source) 3. ... Besides, an Oracle or SQL Server DBA has access to some pretty good remote tools, which let her administer many database servers at once.

Ah, this has been my biggest wish. I wish all MySQL tools will also let me remotely access databases so I don't have to put on my Spider-Man costume and jump from building to building so I can get to my database servers. With all the New York sky scrapers in my way, I can get really hurt, you know.

BTW,Does any one know if MySQL has any plans to allow me to communicate with my database servers via telepathy?

MySQL and threads: my observation and experience

First: Here's to give an idea of how much traffic our site handles:


I just read the post by Monty Taylor about MySQL and threads which was in response to Curt Monash's post on why not to use MySQL.

As Director of Database Infrastructure for a top 14 Internet destination (according to Alexa), I just wanted to pitch-in with a quick comment.

Monty says, "Try running an top-10 web property with 100+ Oracle databases with a team of 1 DBA and see how long it remains running. I’d be happy to take the challenge of running the same thing on MySQL."

I couldn't agree more. I am a single person at my work working on MySQL. Our MySQL instances handle close to 30,000 queries per second at peak hours. We run MySQL on Solaris 10 with 3Par as our SAN and couldn't be more happier. We are running 64 concurrent InnoDB threads with average of 1000 max connections per server and the results are truly pleasing. For sure, I feel desperate to get some assistance but for now, it is just me managing all our installations. I have been doing that since June 2006 and without MySQL, it would not be possible. So far, I haven't yet come across a similar situation where 1 guy was managing a top 15 web property (traffic-wise) using Oracle.

And what about Curt's remaining points about why not to use MySQL? I will let Roland, a good friend of mine, address that.

When no disaster recovery plan helps

Regardless of how "prepared" and "ready" one feel for a disaster, it will, in one form or another, inevitably happen. The best thing you could do is continuously revise and test your disaster recovery plan, strengthening it each time against any kind of disaster you can think of. Things generally go wrong when you least expect them to go wrong.

I was getting chills reading about Charter Communications, a St. Louis based ISP, accidentally deleted 14,000 active email accounts along with any attachments that they carried. All the deleted data of active customers is irretrievable. As someone who is responsible for data of one of the top 15 heaviest trafficked site in the world, according to Alexa, I know, I'd HATE to be in shoes of the person responsible for this.

As I was reading the news story, I was constantly thinking about the title of Jay and Mike's 2006 presentation: "What Do You Mean There's No Backup?"

Once a disaster happens, you can immediately think of the possible ways it could have been avoided. The real challenge is implementing ways of avoiding all types of disasters before they happen.

For instance, to protect against such a disaster, or at the very least, be able to recover from its effects, Charter communications could have:

1. fully tested the script on a QA/test box to ensure no test records of active users are deleted.
2. created a backup of the data by creating a file system snapshot just before running the script. That way deleted data can be recovered. Depending on your operating system/storage system, there are a lot of tools available that let you take file system snapshots such as fssnap (Solaris), LVM (Linux).
3. had a recoverable backup. There are a lot of cases out there where either no backup exists or the one that does exist, turns out to be corrupt. With a periodic backup, Charter could have, for instance, just announced to their customers that they lost their new emails since last week, instead of dropping the ball and saying that *all* their email is lost. Even having an off-site backup in this case would help if selective restore from that backup was possible.

BTW, Just a few days ago, I was testing a random sample of backups and found backups of a database to be corrupt. That triggered a system wide check of backups. The best way I have found is to have a list of backups from all databases sent to me by email. My report contains information about backups running at the time the script was generated and the backups that were created the previous night.

4. If the data deleted was on a database such as MySQL, recovery from this disaster would be possible by keeping a slave intentionally behind.

What are some of the other ways you can think of to avoid a disaster or to execute a recovery plan?

There are many ways a disaster like this can be triggered. A few, seemingly bizarre but very real, that come to my mind:

- What if you accidentally re-run a previously executed DELETE command, stored in your mysql client history, in a hurry, on the wrong server? Or you re-ran a disastrous command in your shell history in the wrong directory?

- What if you used a list of IDs generated from your QA/test machine to delete users from production machines/databases? Oh and the IDs were generated from an auto-increment column?

Can you think of more?

Sure, there are ways to prevent against each kind of disaster. The question then is: Are you prepared against 'all' of them?

The disaster recovery plan of your company may help your steer out of such a disaster, but in the case of Charter, their DR plan didn't cover this. They do, however, have plans to reimburse their customers $50. Don't know if that'd be sufficient to keep customers from switching.

If you are someone responsible for administering and executing disaster recovery plan(s) for your company, you may find my "Disaster is Inevitable--Are you ready" session at the MySQL Conference 2008 interesting. Plus, we can have great conversation afterward. :)


See also: disaster recovery, disaster recovery journal, mysql conference

Speaking at MySQL Conference 2008

I have been meaning to blog about this for quite some time but time seems to be the most scarce resource in my life.

This year, I will be presenting three sessions at MySQL Conference:

---

Disaster Is Inevitable—Are You Prepared?


What’s the worst database disaster you expect to happen? Are you prepared? Does your architecture support quicker recovery or do you have recovery bottlenecks built throughout your architecture? What will happen if InnoDB crashed beyond repair or if you have a massive irrepairable data corruption? What can you do to better prepare for the disaster, when it does happen? Do you have data restoration tools and procedures in place in case you need to resort to extreme measures? Join us in this eye opening, heart-racing, real-life inspired presentation by Fotolog’s Director of Database Infrastructure, Farhan “Frank” Mashraqi” to find out answers to these questions and more.

Optimizing MySQL and InnoDB on Solaris 10 for World's Largest Photo Blogging Community


Fotolog is a top 19 Internet destination with more than 12 million members, 315 million photos and more than 3 billion page views a month. In just a few years Fotolog has become a social phenomenon in Europe and South America. Through modifications to its data architecture, Fotolog was able to serve four times the number of users using the same number of database servers. A non-conventional, hybrid presentation that conveys the importance of scalability, performance tuning and schema optimizations in a practical way.

The Power of Lucene

Lucene is a powerful, high-performance, full-featured text search engine library that is written entirely in Java and provides a technology suitable for all size applications requiring full-text search in heterogeneous environments.

In this presentation, learn how you can use Lucene with MySQL to offer powerful searching capabilities within your application. The presentation will cover installation, usage, optimization of Lucene, and how to interface a Ruby on Rails application with Lucene using a custom Java server. This session is highly recommended for those looking to add full-text cross-platform, database independent search capability to their application.

---

Registration is now open. See you all soon!

Yay! Sun Acquires MySQL

In 2006, when I joined Fotolog, I made a decision: my specialty is going to be Solaris 10 and MySQL. Very quickly, I realized that MySQL on Solaris is not very commonly deployed architecture. Atleast not as common and popular as MySQL on Linux. Since then, I have promoted MySQL/InnoDB and Solaris combo at various conferences, meetups and through podcasts.

So you can imagine, I couldn't be more happier with Sun's announcement to buy MySQL. It has been one of my top wishes for MySQL and Sun to work together. When I checked my email today, I had the following comment left on my wish list post.

"Looks like your No. 3 has come true:"

And indeed, it seems it has come true.

Fotolog, the company I work for, is one of the biggest users of MySQL on Solaris. Honestly speaking, I felt a little left out being a MySQL on Solaris guy. Now, hopefully all that will change and SAMP/AMPS will hopefully takeover LAMP. At least, that's what I want to believe.

So heartiest felicitations to Marten, Monty, Brian, David, Kaj and everyone at MySQL for working so hard on MySQL and getting it to this point.