MySQL 5.6 through the eyes of a custom storage engine MySQL plugin
MySQL is famous for its pluggable storage engine architecture which allows a DBA or an application developer to choose the right engine for the task. An application uses MySQL API and is isolated from all of the low-level implementation details at the storage level. As an example, the Cloud Storage Engine (ClouSE) enables existing MySQL applications to use cloud storage such as Amazon S3 or Google Cloud Storage to store its data. The application doesn’t need to be changed or even redeployed: with ClouSE, remote cloud storage will look like a better (ultra-scalable, durable, always-on) alternative to the local storage.
As you may already know, ClouSE now supports MySQL 5.6 release series. See this announcement for more detail. Let’s go through the set of changes that were required on the ClouSE side in order to keep up with core MySQL 5.6 changes.
We had to adapt our code to compile and work with MySQL 5.6 while keeping 100% compatibility with MySQL 5.5. As much as we could, we tried to fix the code in a way that would work with both release series, but there are cases where the code has to be conditionally compiled for each release series.
Here is the list of MySQL 5.6 breaking changes and our solutions, in no particular order.
I got a few questions like the ones below that I’d like to address to avoid further confusion.
How exactly secure is ClouSE for MySQL, the first secure database in the cloud? Am I protected against standard application level security attacks or even accidental admin mistakes?
With the help of ClouSE I get instantaneous backup for my database on the highly durable cloud storage. But how would I protect my data in case a malicious attack or an accident did occur?
I’ve got a comment pointing out that data encryption on the storage level doesn’t protect from SQL injections. Of course, data encryption does not protect from SQL injections (as long as there is SQL involved, there will be a risk of a SQL injection). Neither does it protect from the infinite number of attack vectors that can happen at any layer of the application stack: PHP, Apache, MySQL, Linux, application code, application users, etc.
When I was a little boy, I thought the Old New Year (Jan 14) was the day when the New Year becomes “old”, becomes the current year, the thing of the present. To the mind of a little systemic thinker it made perfect sense – if there was not a date when the New Year stopped being new, how would we be able to celebrate the New Year that comes after it?
Later I learned that the Old New Year was just Jan 1, but by the Julian calendar. So in a sense the reason for this informal holiday is that little details of the relationship between the Earth and the Sun were ignored and it led to a growing gap between the tropical year and the calendar that tried to express it.
At OblakSoft we have other things to celebrate besides the Old New Year. We started a new company and launched a public Beta of our first product: ClouSE – the Cloud Storage Engine. At a high level, though, the problems that ClouSE is trying to address in Cloud Computing are somewhat similar to the ones the Gregorian calendar has solved in date counting: to take into account little details of the relationship between the cloud provider and the cloud consumer and to close the gap between the cloud computing promise and cloud computing reality.