In less than two weeks we will meet at the Percona Live Conference in Santa Clara. I am very pleased to see such a great commitment from Percona, to an event that has always signed big announcements, great talks, famous guests, but above all, a great audience. I am sure this year it will be even better. The schedule is packed with great talks and I would like to highlight some that I think should be interesting for everybody.


But first, a bit of Cloud

Interesting enough, the OpenStack Summit will take place the week before the Percona Conference, only a short flight from the Bay area, in Portland OR. The summit has attracted 2.400 registrations to date and it looks like it will be another great event. As I have already written in previous posts, I think that many DBAs will have to take a look at private and public clouds fairly soon. The growth of MySQL in this decade is strictly related to the adoption of a more scalable and reliable database in the Cloud. If we, as members of the MySQL Ecosystem and Community, fail in providing this "new" MySQL, free and open source as it was before, we will give room to other options, even when they are not the best fit.

In any case, I will post my opinion and comments on the Summit on this very same blog.


Then, Santa Clara!

Percona this year managed to reintroduce a 4 days conference, 1 day tutorial + 3 days of presentations and keynotes. In addition to the conference, a fifth day, hosted by SkySQL, will be focused on Open Source solutions for the Enterprise. If you are in Santa Clara for the Conference, a 5th day for free makes the cost of travel and registration a good value for money - especially because the talks may have similar topics, but they are not the same of the conference and they will give you a different perspective. In addition to that. SkySQL and other companies in the MySQL Ecosystem will give free help and advice to developers and DBAs - as it happened last year.


Here are my favourite talks

Here is a shortlist of my favourite talks, ordered by schedule - my "must-see" list. If some of my fellows and friends don't see their talk here, please do not be offended. And yes, there are some talks that come from my team or my company, but you can easily check that not all the talks from my company are listed here - all in all, I simply added my starred list!


And if you are interested in my talks…

Big Data with MySQL is my first talk on Tuesday. It is primarily an architecture talk, it may help if you are addressing the problem of some large data (if not Big) analysis in your organisation. Perhaps you do not need to create a large infrastructure of Hadoop servers or implement complex transformations - this is something you may figure out in my talk.

What can we learn from NoSQL technologies is the second at the Conference. Again, something architectural, but with fragments of code and table structures that may help in defining how to use MySQL with a NoSQL approach. Maybe, but only maybe, you may continue to use MySQL and you do not need to migrate to another database, or use more than one database for your application.


And then…. the SkySQL Solutions Day. But that is a topic for another post. 


FOSDEM 13 is now over, I am on my way home and I would like to share some thoughts sparkled by the intense atmosphere that I have lived in these two days in Brussels.


I have to admit, I was tempted to skip FOSDEM this year: the last 3 weeks have been crazily busy and I travelled a lot, leaving my family alone for too long. But now I am glad I made the effort.

For once, I will leave the comments around the MySQL talks to others, I am sure there will be posts on the matter. In this post I want to cover some of the non-MySQL talks and discussions I have attended and heard. Of course the topics that have been discussed are still relevant for MySQL and for the future of the MySQL ecosystem.

First of all, the number of attendees was impressive. The organisers claim there were more than 5,000 open source enthusiasts, in my opinion the number was even higher. Every room was packed with people. MySQL had a room in the H building, it was always full and sometimes there were more people outside than people who could find a seat in the room. Naturally, such a great attendance is a good sign that the MySQL Community is alive and kicking and that users and developers are still interested in what is new with MySQL.
The MySQL room was not the only one to be constantly packed. Other streams had the same problem: the cloud room was much bigger, but always full or almost full. The NoSQL room was almost twice the size of the MySQL room and there were always people left outside, as far as I could see. and so it was for many others. 

This great event and  other meetups and "fests" around the world are the clear indication that the interest in open source software is growing more and more. The number of sponsors and exhibitors has also increased. It was great to see Oracle at the event, with a fairly well visited booth.


Some aspects that are relevant for MySQL

I attended some of the talks in the Cloud room. Most of you know that SkySQL has released an open source solution to automatically deploy a highly available cluster of MariaDB servers in the Cloud - the SkySQL Cloud Data Suite. The interest in Cloud environments is quite natural for me and for other SkySQLers.
It was not a surprise to see that the majority of the talks were around OpenStack, but there were other Cloud solutions presented as well - a CloudStack presentation, for example, was also very good.

All the cloud talks I have attended have addressed, in some way, the use of relational databases. First of all, MySQL is undisputedly the standard RDBMS for the Cloud. It is used in the platform layer to support application and as internal repository for the Cloud software. Despite the fact that it is potentially a single point of failure and that the whole Cloud would stop in case of fault, standard installations do not address this problem. The best you can see are some suggestions on how to improve availability, typically using DRBD.
Despite the large number of options, MySQL does not have a standard HA solution that can be installed in minutes and work out of the box. You may say HA is not easy, but in essence this is what the cloud provides, i.e. a reliable and highly available solution. Cloud developers put enormous efforts in producing a Cloud that is easy to install and run, but MySQL still remains a complex piece of the jigsaw.

Mark McLoughlin, from RedHat and Common Project Technical Leader, presented the state of OpenStack. He went through the various components of a typical Cloud environment, he explained how they would fit in the Cloud and how they could benefit from availability, flexibility, scalability and the elasticity provided. Mark referred to load balancers, business logic components, application servers, schedulers, and of course databases. For each component, he gave some good examples, but when he tried to find the same examples for the database, all he could say was that "users have to stick around with active-active or active-passive sort of things". Again, another reason for MySQL developers and for the MySQL ecosystem to think more and to find a solution to this unsolved problem.

But if the Cloud tracks have in some way highlighted  aspects to consider in the development of new versions of MySQL and MariaDB, the NoSQL tracks were really inspiring. Above all, I would like to comment on Jonathan Ellis's talk around Cassandra.

Jonathan's talk was smartly titled "Five questions to ask about NoSQL" . The 5 questions were:
1. How do you model your database?
2. How does your database performs?
3. How does your database handle failures?
4. How does your database scale?
5. How is your database flexible?
 
This is, in my opinion, the essence of what developers are looking for today from a database solution. The 5 questions were of course an excuse to show how Cassandra can give you a good answer to them. But my question is "What kind of answers can MySQL provide?" These are the reasons why some developers look at NoSQL solutions and leave MySQL, at least for some projects.

Jonathan is really a balanced guy. He did not verbally attempted to minimise the value of MySQL and relational databases. He showed plenty of examples in standard SQL, something that the audience could easily understand. But he clearly highlighted what developers wanted and he explained how Cassandra, sometimes very well and other times in an OK way, could provide a good solution.
In my presentation at the Percona Live Conference in Santa Clara in April - What can we learn from NoSQL technologies? - I will cover most of the aspects with technical details and practical examples. So, stay tuned and wait for a while - and if you plan to attend the event, please come and see.


Thinking of FOSDEM 14

I really hope I will participate to the next FOSDEM. I hope to see a more "cloudy" MySQL and some "No" close to the "My". I also hope there will be a bigger room for the MySQL friends, and some cross talks. I also hope to find an alternative to OS X as desktop OS, as for now, Ubuntu or Fedora cannot provide what I need.


On 29 November last year, SkySQL and Monty Program jointly  announced the release of the so called "MariaDB Client Library for C Applications" and "Maria DB Client Library for Java Applications", which I will call C and JDBC connectors here. You can follow this link to read the press release from SkySQL.

Last week Baron Schwartz posted some findings re the C connector in his blog. Today, another post from Robert Hodges added few details and were looking for answers. I think I can help a bit in understanding what we have released and how the connectors can be used. I will not comment the accuses of plagiarism mentioned in Baron's post, for two reasons. First of all, I think plagiarism is a serious accusation that refers to illicit actions (but I am not a native English speaker and I may be wrong) and I do not have any legal expertise. Second, I think that any discussion around the ethical or unethical use of somebody else's code, especially when it is based on the number or on the percentage of code changed, is a pretty slippery field and it is too prone to individual interpretations.

The C connector in [very] short terms

You can find information regarding the C connector here and here. The connector is based on the MySQL Client Library v3.23.58. If you look at the source code of both libraries you can immediately spot that there are significant differences. Take the libmysql.c file for example, you will find significant changes within the C functions and some new functions, such as cli_report_progress, changes to support the 5.X protocol, connection/close/reconnect etc. Obviously, libmysql.c is not the only module to show changes - take the prepared statements in my_stmt.c and my_stmt_codec.c for example, where Monty's team worked on the porting from the mysqlnd extensions.

A bit more history and extra info for the JDBC connector

I can certainly add a more history and info for the JDBC connector. Mark Riddoch (our head of Engineering) and his team have actively participated to the improvement of the connector, together with Monty Program's team. What you can read below is a summary of what happened and the areas that they have improved.

The JDBC connector is directly derived from the Drizzle connector. When we looked for a Java connector that could work as alternative to the MySQL Connector/J from Oracle, we were very happy with the great job that Markus Eriksson did. The only problem was that the Drizzle connector, although it conformed to the basic JDBC interface, had been stripped down to the bare essentials. This is good for the objectives of the Drizzle project, but we wanted to offer something that was more generally useful for the MySQL and MariaDB™ community at large. The problem was, of all the vast array of missing features, which should we tackle first? We embarked on a lengthy evaluation program to determine what features to add either ourselves or to fund Monty Program to add to the driver.

Our first approach was to take a few popular Java applications and test these against the connector. One of the issues with this of course is to identify applications that are a reasonable representation of what an end user might use. Also we have to test these applications to fully investigate the features that the application uses with the driver. Given the Java linkage model this means we need to effectively do as complete a test as possible for each application in order to fully exercise the JDBC API.

Using this approach we quickly found some of the more major areas of incompatibility, namely the fact that the URL used by the original Drizzle connector had an incompatible syntax for the URL and was missing compression. Our aim was to provide a drop in compatible JDBC driver, therefore having a compatible syntax for the URL was an obvious first fix to make, as was the addition of compression.

Although this approach seemed to be reasonable at first sight, the overhead in setting up various applications, creating data sets needed by the application and then manually testing the application was a time consuming operation. As an enhancement to this approach we decided to look around for an application or a framework that had some form of automated test procedures that we could use to test the interface to the database. We choose the Hibernate framework as our vehicle for this since it contains a set of automated tests to verify the SQL dialect it is using. This enabled us to automatically run a large set of tests, across a diverse set of API methods of the JDBC driver. Crucially this enabled us to run regression tests very easily each time we fixed a bug or added new functionality to the JDBC driver. The first runs of the Hibernate test suite yielded several hundred failures and very quickly led us to a number of fixes that we needed to apply to the driver that had not been picked up by the tests we had previously run. The lack of support for BLOB and CLOB datatypes caused a vast number of failures, so these were an obvious first target for our development of the driver. This was quickly followed by a number of other features such as better support for the manipulation of the metadata and schema aspects of the JDBC API.

The lack of support for streaming data sets, and the way of handling large result sets in the Drizzle driver required a number of changes to the driver, callable statement support and stored procedure support also need to be added to support these feature of MySQL.

The third phase of the development and testing of the connector was to engage with some external application developers who required a JDBC driver with the more relaxed licence requirements. This added a whole new set of issues that had not come to light with the Hibernate testsuite. A number of these issues were related to the concurrent usage aspects that had not be highlighted by the Hibernate testsuite, there were a number of synchronisation issues that had not be solved, connection handling for high numbers of concurrent connections, connection leaks and general resource leaks were all highlighted by this test route.  Some of the more interesting issues that this approach raised was related to the MySQL specifics that the more general Hibernate approach didn’t find; this included the various parameters that could be set as connection properties and reliance on particular semantics of the MySQL Connector/J.

Datatype support also became an issue as we tested with more and more application developers; temporal datatypes needed to be updated to support microseconds and numerous were found where the Drizzle driver had a different mapping between the database types and the native Java data types. In particular the getObject API call required some work to give true compatibility with the MySQL Connector/J.

One particularly interesting case was the getTable() and getColumn() API, used to get table information from the database schema. The implementable of getTable() in the Drizzle driver was 100% compatible with the specification of this routine in the JDBC specification, however the MySQL Connector/J was not current according to the JDBC specification. A particular application we were working with depended upon this particular behaviour in MySQL Connector/J, which was technically incorrect, so this gave us an issue; we had a driver that was correct but different from the one we wanted to emulate. So should we deliberately put what could be considered a bug into our JDBC driver? The solution we arrived at was to add a connection parameter to switch between the strict JDBC behaviour for getTable() and the MySQL Connector/J behaviour; so we added the NoSchemaPattern connection option for this switch.

At this point we believed we had something that was fairly usable, and started to widen the availability of the JDBC driver to more application developers in an attempt to ascertain if the driver was complete enough to be interesting to the general user base. There were still major areas of functionality that we knew to be missing, in particular the support for connection pooling and connection failover. In parallel to the widening of the testing we also added these features and support for introspection.

The improvements

In all we spent just over a year taking the Drizzle core and slowly testing and enhancing it before handing the driver over the Monty Program for release to the community.

Here is a summary of the improvements that we made in the MariaDB connectors since initial fork, in chronological order:
- UseCompression option
- Connection string compatibility with MySQL Connector/J
- Implemented getWarnings/clearWarnings
- Added support for CLOB
- Added callable statements
- Allowed IP addresses in connection URLs
- Added large result set support
- Fixed synchronisation issue when multiple connections are used by threads in a single application
- Added an option to control the output of tracing messages from the MySQLProtocol class, using a connection option MySQLProtocolLogLevel=FINEST
- Fixed prepared statements so that the parameters are not automatically cleared between each invocation the prepared statement
- Added support for the MaxRows API
- Added connect URL options: socketTimeout, interactiveClient, localSocketAddress, createDatabaseIfNotExist
- Fix for IGNORE_BACKSLASH_ESCAPES
- Implementation of the IGNORE_BACKSLASH_ESCAPES option in line with the MySQL Connector/J treatment
- Update error handling for zero dates to correctly set SQLState
- Corrected object type returned by getObject for INTEGER columns
- Bring other object types returned by getObject into line with the MySQL Connector/J
- Added support for setCatalog and getCatalog. These follow the model my the MySQL driver and treat databases as catalogues
- Resolved quoting issue with setCatalog
- Added the NoSchemaPattern option to the connection string to enable compatibility with MySQL Connector/J. The schema pattern argument to getColumns and getTables are ignored by the MySQL if NoSchemaPattern is set to true.
- Update the remainder of the meta data functions to honour the NoSchemaPattern connection options
- Fix issue with naming of auto increment columns
- Clears the cached result set on closing a statement
- Removes the prepared statement cache
- Make the methods GetDatabaseMajorVersion and GetDatabaseMinorVersion work.
- Support for the javax.sql.pooledConnection class
- A fix for the pooled connection to tidy up transactions in the event of close() being called
- Extra methods on the MySQLDataSource class to allow the data source to be created via reflection:
  - zero argument constructor
  - public void setDatabaseName(String dbName)
  - public String getDatabaseName()
  - public void setUserName(String userName)
  - public String getUserName()
  - public void setPassword(String pass)
  - public void setPort(int p)
  - public int getPort()
  - public void setPortNumber(int p)
  - public int getPortNumber()
  - public void setServerName(String serverName)
  - public String getServerName()
- Addition of the setURL and setUrl methods on MySQLDataSource to aid creation of data sources using reflection
- Addition of setUser and getUser as well as the less used setUserName and getUserName methods
- Update to setURL to avoid overwrite of items set with individual methods if the corresponding value is not set in the URL itself
- Corrects a problem with final attributes in the JDBCUrl class preventing modification of connection parameters
- Addition of connection properties
  - socketFactory
  - tcpKeepAlive
  - tcpNoDelay
  - tcpRcvBuf
  - tcpSndBuf
- Added in the ability to return generated keys in executeUpdate methods of a statement
- Addition of the dumpQueryOnException connection property
- Further fixes for the generated key support
- Corrected behaviour of GetObject on a resultSet with a TINYINT(1) column. If TINYINT1_IS_BIT property was set this previously always returned false.
- Fixed issue that prevented '-' character in hostnames in a URL
- Fixed issue related to BufferUnderflow exceptions
- Fixed issue with the mapping of CHAR columns into a Java type


Naturally, we want to improve both connectors. We are also seeking for contributors in testing, in providing feedback and ideas or even more if it is possible. The fact that Baron, Robert and others are blogging about the connectors is really encouraging. Suggestions and comments are more than welcome!




What is the value of a seed? 


When I discussed the MariaDB Foundation with friends and colleagues, many said I was exaggerating. My believe is that the Foundation is important for MySQL and for the future of the IT industry - services and applications. Many agreed with me that the Foundation is important for the MySQL ecosystem, but involving the global economy and the whole IT industry is a bit of a stretch.

Fact is, the World Wide Web would not be as it is today without MySQL. MySQL was part of the LAMP stack. It powered - and still powers - some of the most successful web sites in the world. Without LAMP, companies like Facebook, Twitter or Google would have been developed in a completely different way or they would have not been developed at all.

The importance of MySQL for the Internet is pretty clear for many of us. What is perhaps less clear is what is the current situation of MySQL and the MySQL ecosystem.

If we look at the main development of MySQL today, we can say that so far Oracle has played a good and positive role in improving it. MySQL 5.5 has been significant milestone in the development of the database, especially because the development has been stagnating for a relatively long time. MySQL 5.6 has addressed some of the issues left open in 5.5 and it has been improved scalability and reliability. The point is, most of these improvements happened within one of the most important pieces of MySQL - the InnoDB storage engine. Oracle made several changes outside InnoDB, but some of them were really a catch-up with MariaDB, and the strong skill at Oracle are clearly in the transactional storage engine. At the same time, the team at MariaDB has worked on other pieces of the jigsaw. The optimizer is clearly one of them, other specialised storage engines, plugins and Replication are other aspects. In addition to Oracle/MySQL and MariaDB, Percona did a great job in applying specific patches to the server and in providing essential tools that make MySQL "a better MySQL".


Why can't Oracle improve in other areas?


So, the obvious question is: why can't Oracle improve MySQL in other areas? Of course they have the expertise to work on a better database and they can easily attract talented developers.

I think relies on two factors. First of all the InnoDB team appears to the strongest team at Oracle/MySQL(*). In the last two month the team has improved its knowledge with the addition of new developers as well. The second factor is purely economical. Despite the enormous resources that Oracle can put together, all must end with a costs/benefits analysis and with a positive number at the bottom. Oracle has a wide variety of great and profitable solutions in their portfolio: they simply act as anybody else would act in their position, i.e. they will be focused on the most profitable and promising technologies that can guarantee a great return of investments. Unfortunately, in long term MySQL is not one of them.


A completely different scenario


The scenario today is completely different from three or four years ago. When Oracle acquired Sun, there was very little competition between MySQL and the Oracle database. Yes, there were some examples of migrations or new applications being developed on MySQL, but the distinction between Enterprise and the Web applications, and consequently between the use of the technologies related, was pretty clear.

Things have changed dramatically though. The future - and most of the present - is in the Cloud and in Cloud services. In the next 5 years, SaaS technologies will expand more an any other software solution. Which database technologies are these SaaS providers going to use? But, above all, from which applications and traditional software solutions will SaaS providers grab customers? A detailed answer to this last question deserves another post.

An answer to the first question - which database technologies are SaaS providers going to use? - is a key element to understand why the Foundation is so important.
It is difficult to identify which technology will be mostly used, but it is clear that there will be a mix of NoSQL and SQL technologies.


SQL, NoSQL, NewSQL


NoSQL databases, believe it or not, are here to stay. Developers love them, they solve lots of problems that software engineers had to fight for years. As usual, they fixed some issues and they found some others, this is pretty natural.

Software engineers looked at NoSQL technologies because they could not find solutions to their problems in standard SQL databases. On the other hand, SQL databases cannot be completely replaced by NoSQL solutions. They need to work together. Eventual consistency and non-ACID databases work for some data, but not for everything.

There are many relational databases on the market, but when the selection is narrowed down to robust open source software, the choice can be made only between two: Postgres and MySQL. Postgres is living a glorious momentum, but it is far from the adoption and the ubiquity of MySQL, not to mention that the agility of MySQL make the database a perfect component for the Cloud, whilst Postgres seems to be still marketed as the open source alternative for Enterprise software.


Putting all together


In the end, why is the Foundation so important? In a single sentence, because it is backed by the key players in the MySQL ecosystem and it acts with only one and clear interest: to make MySQL a better MySQL, regardless the label applied to the software - MySQL, MariaDB or else.

MariaDB is evolving greatly, also thanks to the great improvements made possible by the InnoDB team at Oracle. On top of that, the MariaDB team has worked and is working on that important link that is the integration of SQL, NoSQL and NewSQL, on premises and in the Cloud. This is not only related to the creation of new storage engines, but also to the availability of other plugins and components that will make SQL and NoSQL a single, complete database solution.

I believe this great work will give a boost to the adoption of MySQL/MariaDB in the Cloud, for host providers, for public, private and hybrid clouds, and for SaaS providers. And again, there will be space for new solutions, made by bright entrepreneurs with great ideas and little money. And hopefully these new services will better serve new businesses at very low cost. Will see, but in the meantime, let's not wait, let's contribute!


(*) I do not refer to MySQL Cluster here


Sitting at the Hilton in San Francisco, listening to the MySQL Connect opening Keynotes, sparks interesting thoughts. Thoughts about the future of MySQL, the Oracle stewardship, the MariaDB alternative and the advantage of the solutions provided by the MySQL Ecosystem.

But there is something missing. I know something is not part of this picture, but I can't figure out what it is.

At the end of keynotes and pane,l I turn to the exhibitors area, an approx 800 sq ft., 50% occupied by Oracle. At the bottom left corner stands my answer. 

The small yellow cubic hive of AWS was at the top of the rollup that reminds of MySQL and RDS, admittedly the most used version of MySQL in the cloud so far. And here is the missing part. 


New great features in 5.6 Release Candidate and in MySQL Cluster 7.3


The new features packed into 5.6 are simply awesome - my Brit friends will forgive me here, I tend to use local terms, but I can always turn them into "wonderful". The additions to InnoDB will make a big difference for many users and they will fill the gap between the power that the new hardware can bring and the what MySQL can use. Benchmarks show a great improvement in scalability with 48 and 96 core machines. Not bad at all. Equally important, online DDL additions will make the life of DBAs much easier and ultimately they will bring better availability.

MySQL Cluster 7.3 is also a good release. Personally, I am less interested in the new foreign key addition: I still believe that somebody who decides to use MySQL Cluster should not bother too much about foreign keys, but I perfectly understand that some users may have different needs.

It is also good to see DRBD back in the list of the HA solutions provided by Oracle, although I would say this is a bit far from "driving innovation" and that today there are more options in terms of HA, compared to 5 years ago.


What about MariaDB 10?


Some of the features announced in 5.6 today are already available in MariaDB 5.5 or they are present in the new version of MariaDB 10.

Subquery optimisation has been available in MariaDB for years now - I have not checked the details of what is here and what is there, but in general I would say that this is really a catch-up for Oracle. So is the replication group commit that people can enjoy in GA fashion in MariaDB 5.5. 

The other additions for replication - the Global Transaction ID, multi-threaded options etc. - have been announced in MariaDB 10 few weeks ago. Personally I have not checked the differences yet.


And where is the Cloud?


We can argue that almost all the new features in 5.6 and in MariaDB 10 will help users in deploying MySQL in the cloud. What is missing is a good set of real cloud features. Some of these features, like JSON, HTTP, Javascript and NoSQL options have been mentioned by Tomas and what will come next, but that means that they are at least another 2 years away.

Multi-tenancy capabilities, data encryption and obfuscation, multi-protocol communication, NoSQL integration, in-server sharding and data aggregation are some of the features we are looking for. I am perfectly conscious that this is a bit too much to ask at this stage, but I believe that if we want to tag MySQL with the word Innovation, you must couple it with the equally valid word Cloud.


Look! You can see the heart beating!


In case you are wondering, no, nobody in the family is expecting another baby…



I thought I had to start the post with this picture. Today I feel a bit like the day I went to the hospital for a pregnancy scan. As you may expect, seeing the baby moving was incredibly emotional, and I can feel some similar emotions with this announcement.



Many of you already know that today SkySQL has announced and will release the very first version of our very first product, the SkySQL Cloud Data Suite. Before I enter into more details about the product, let me add a couple of points.

First of all, this is still a Beta version of the product - it is the scan of a baby, not his/her birth. From here though, you can see all the bits and pieces the product has. You can configure it, test it and deploy it in EC2 and we really, really welcome all your comments, opinions, suggestions. We want to make the product right for as many users as possible and we really welcome your collaboration. This is the main reason why our code inside the product is fully open source: you can look at it, and please give us feedback.

I also want to reiterate how special this product is. I have worked on many software products in the past. I have designed, coded, engineered and led team that created many products. I will never forget the enormous number hours spent on an ERP system designed for publishing companies that I have created and coded in the early 90s. Certainly, I cannot forget the first time that the broadcast platform that I designed reached the [at that time] incredible number of 1M personalised messages for a single event - that was back in 2000, every company thought they had to own and provide some sort of personalised content for free - something that later became "social" and made more sense… 

What is really special this time is that we are touching a very, very unexplored ground. There are already companies active as database providers in the Cloud but, in my opinion, nobody has yet adopted an enterprise approach to some of the most common problems that affect the deployments of a DB platform in private and public clouds.

What is the SkySQL Cloud Data Suite?


SkySQL Cloud Data Suite is part of a bigger project that we have simply called SkySQL Data Suite. If you check the SkySQL website, you will notice a clear differentiation between the SkySQL Cloud Data Suite and other options. In simple terms, the first version of the product allows the user to configure, deploy, administer and monitor MySQL databases in Amazon EC2.


Users can visit config.skysql.com - the same site that was previously used to configure the SkySQL Reference Architecture - to start the configuration process. They have the option to use a simplified or a more advanced configuration. The latter provides more control of the parameter that will be set in the MariaDB databases that will be deployed.

The deployment consists of one or more MariaDB servers, depending on the selections made. For example, if a user requires maximum availability for critical applications, the configurator will prepare a cluster of nodes connected with semi-synchronous replication and with multi-regional asynchronous replication.

The user can also decide how the cluster will be deployed in EC2. The simplest option is to generate the cluster directly from config.skysql.com by using the access keys provided by AWS. We are fully aware of the security aspects associated to this option and we reassure that no keys will be stored at SkySQL, they will be destroyed immediately after the deployment of the configuration.

If users are uncomfortable with the first way to deploy the cluster, they can use two alternative ways to deploy. The first one is to start an instance in EC2 and pull the configuration from the SkySQL servers. The second one requires manual operations from the System Administrator, SkySQL will simply send an email with all the necessary steps to create the Cluster required.

We have made public an AMI that is used to create the nodes of the Cluster. The AMI is loaded with MariaDB, our Administration Console, the probes used to interact with the various nodes, the agents used to provide full high availability of the system and with an Enterprise Monitor, i.e. MONyog. Everything except the monitoring tool is provided with GPL license and it is free to use. The monitoring tool is fully functional for a month through a commercial trial license.

How can you help and where can you find help?


We have set up a forum that will specifically address topics around the SkySQL Data Suite and we have now a bug system. You can search and post messages in the forum, browse for and file bugs in the bug system. And again - every feedback will be very helpful.

What's next?


We are fully aware that the product is still in an early beta and if you plan to use it in product we strongly recommend to contact SkySQL.

We will update the AMI on a regular basis and we will provide patches for the existing installation from our website. So it will be your choice whether you may decide to update an existing cluster or create a new cluster and import data in there. We will notify users about patches, bug fixes and new versions, unless users will opt out of the notification. 

And there is more, much more to come. Just stay tuned!

Or, better say, I have not blogged for so long…


What happened? Well, it has been a crazy year, probably the busiest year in my whole working life.
When you are in your late twenties/early thirties, you can dedicate all your energy to something, work, hobby, charity, sport, study, you name it. You work hard, and every now and then you have time to lie down and recharge your batteries. In one or two days, if you can sleep 9/10 hours per day, all the tiredness you have accumulated goes away. I have felt that feeling, but in your late forties, there is no such thing anymore.

When you are forty and you have a family, your priorities change. You try to accommodate work, family and friends. You remove most, if not all, of the time you dedicate to yourself. You have less rest, usually not enough to recharge. The 9/10 hours you used to recharge and be up and running, ready for a new week, they become barely 6/7 hours, if you are lucky… and you feel like your head is in a constant foggy atmosphere that does not allow you to think straight. You do, but you must use more energy and it takes more time simply to get things done.

So, this is what happened to me. But I was used to that. Even in the weird days of the post-acquisition, when many people could not really do much business-wise, I felt pretty busy.
Nevertheless, I managed to enjoy this fantastic year at SkySQL. 2011 has superseded 2005 (the year I joined MySQL AB), as the best year of my entire working life. Thanks to SkySQL, thanks to all my great colleagues, to all the partners, users and customers. And thanks to my family and friends, who are supporting me so much.

What are the plans for the future? In long term, it is hard to say, but the short term plan seems really exciting, more than ever, better than 2011. I can see so many new opportunities to use MySQL and MySQL-related products and to be involved in very cool projects. MySQL is not the only wild kid in the block anymore: PostgreSQL and the NoSQL armada are rightly claiming their space and users are adopting old and new technologies. This is good news, it repositions our technology right were it should be, leaving PostgreSQL, HBase, Cassandra and others doing what they do better.

Our technology - i.e. MySQL and the MySQL Ecosystem - is evolving and improving. There is a growing demand for database systems, there is space for everybody. There is space for new projects and for integrations with the current and new infrastructures.

SkySQL will be more and more focused on new solutions and on new architectures. The reference architecture is key for these new solutions. I will blog more about in in the near future and clarify the reference architecture is and what is not. We will offer legacy systems, we will support the standard, vanilla version of MySQL, the servers that Oracle and Percona can now provide. But we will offer more, much more. There is a whole new set of highly available systems - see my talks at various meetups in the US this week - there is a new way to integrate MySQL with other databases, and a new way to create huge data warehouses systems and compete head to head with Vertica or Greenplum, not to mention the quite outdated technologies in 11g. There is a huge demand of migration from legacy systems into the cloud, with MySQL.

Here is the promise - an End-Of-Year resolution, or an anticipated New Year resolution. I will share more of this experiences and the excitement of applying the open source values and technologies where until now only expensive commercial solutions were allowed. Some of my posts will be generic and will fit in here, in my personal blog. Other posts will be more MySQL specific and will be published in MySQL4all.

The future looks bright, I hope many will enjoy the ride with me.

-ivan

Older Posts