It was with pride I entered the stage at the Percona MySQL Conference yesterday to receive the “Storage Engine of the Year 2013 award” for ndb (the MySQL Cluster storage engine).  Thank you very much, on behalf of myself and the MySQL Cluster engineering team. The team has done a great work over the past 10 years to harden the product, and add new features. MySQL Cluster milestone 7.3.2 was just released. It will be my pleasure to present the “trophy” some members of the team when I get back to Stockholm. Please see a previous post for how the MySQL Cluster journey began for myself and the ndb team 10 years ago.

In my Percona live keynote “Driving MySQL Innovation” on Tuesday I talked about the quality problems we had with 5.0 and 5.1 and the switch to the new Milestone Release model. I explained how this new development process allowed us to deliver both 5.5 and 5.6, on time, including innovative features, and with very high quality.

The description of the Milestone Release model has been available here, for almost two years. So, this is not new but it has now been in operation for 3.5 years and it can be worth looking back and summarize.

Our first MySQL Server Milestone 5.4.3 was released on October 9th, 2009 and was then followed up by 5.5.2 on Feb. 26, 2010. Initially there was a time of trying out and fine tuning the model before it found its current form around 5.5 GA. The …

I think Valentina Studio, more better then Adminer http://www.valentina-db.com/en/valentina-studio-overview

We wanted to thank everyone for naming Tokutek the Corporate Contributor of the Year 2013 for ongoing contribution to the MySQL community.

The MySQL Community Awards are given annually to the people and companies that support the MySQL ecosystem. The MySQL Community Award for Corporate Contributor of the Year recognizes a company or other organization or entity that has made valuable contributions to the MySQL ecosystem either in terms of open source code, knowledge, funding or other resources or sponsorship. The winners are selected by an independent community panel.

“Open Source is about collaborating and contributing to build …

  Continuent CEO Robert Hodges says that NoSQL solutions are oversold, but this is no reason for MySQL fans to become complacent. He kicked off Day 2 of the Percona Live MySQL Conference and Expo with his keynote, "How MySQL can thrive in the world of massive data hype."He said there are new challenges in data management, and relational databases must solve them or risk becoming irrelevant. This

Oracle's VP of MySQL Engineering Tomas Ulin delivered on Tuesday a keynote entitled "Driving MySQL Innovation for Next Generation Applications" at the Percona Live Conference.

If you haven't seen it yet, we highly encourage you to watch it.

Tomas covers:

• Oracle's Investment in MySQL
• MySQL 5.6
• Trends and Product Directions

He makes it very clear that Oracle:

• Invests in MySQL like Never Before
• Drives MySQL Innovation
• Makes MySQL Better for Next Generation Web, Cloud and Big Data Applications

Enjoy …

Sysbench OLTP, transactions per second

When dealing with high performance, low latency storage devices, such as SSD cards, one finds bottlenecks in new places. This is a story about such a bottle neck and how to work around it.

One unique feature of InnoDB is the double write buffer. This buffer was implemented to recover from half-written pages. This can happen in case of a power failure while InnoDB is writing a page (16KB = 32 sectors) to disk. On reading that page, InnoDB would be able to discover the corruption from the mismatch of the page checksum. However in order to recover, an intact copy of the page would be needed.

The double write buffer provides such a copy. Whenever InnoDB flushes a page to disk, it is first written to the double write buffer. Only when the buffer is safely flushed to disk, InnoDB writes the page to the final destination. When recovering, InnoDB scans the double write buffer and for each …

Thu, 2013-04-25 11:37 About the Author Sysbench OLTP, transactions per second

When dealing with high performance, low latency storage devices, such as SSD cards, one finds bottlenecks in new places. This is a story about such a bottle neck and how to work around it.

One unique feature of InnoDB is the double write buffer. This buffer was implemented to recover from half-written pages. This can happen in case of a power failure while InnoDB is writing a page (16KB = 32 sectors) to disk. On reading that page, InnoDB would be able to discover the corruption from the mismatch of the page checksum. However in order to recover, an intact copy of the page would be needed.

The double write buffer provides such a copy. Whenever InnoDB flushes a page to disk, it is first written to the double write buffer. Only when the buffer is safely flushed to disk, InnoDB writes the page to the final destination. When recovering, InnoDB scans …

I've just created a release of Libdrizzle 5.1.4 (the BSD licensed C connector for MySQL servers) which for me is one of the most exciting releases to date.

Why?
Not because the amount of features or anything that we have added, in fact this is mostly a minor release with bug fixes.  It is because Brian Aker and I didn't submit the most code for it.  That honour goes to Wim Lewis from The Omni Group who has done a fantastic job fixing up Libdrizzle.

As for the release itself the main fixes revolve around cleaning up code and many fixes to the server-side prepared statement handling.  Behind the scenes Wim has supplied many improvements to the test suite and Brian has setup more platforms to test against in Jenkins.  …

After nearly every recovery case the same question arises: How many MySQL records were recovered and how many were lost.

Until now there was no way to answer the question without manual investigation. As it turned out a small change can make a big difference.

There are two ways to know how many records an InnoDB page stores. The index page has a header PAGE_N_RECS – this is a number of records the page stores. Obviously it doesn’t count any deleted records. The second method to confirm how many records are in the page is to follow records pointers – and count them.

As you might know, records inside an InnoDB page are organized in an unidirectional list. The list is sorted by primary key and starts with the internal record infinum and ends with another internal record supremum. If you …