Amazon RDS for MariaDB Finally! I have been broadcasting for sometime that the reason that Amazon has not moved RDS MySQL from it’s 5.6.x version, was due to the belief that Oracle was intending to charge an arm-and-a-leg from AWS for the privilege of doing the upgrade to 5.7.x. I was of the opinion that this was the initial reason for AWS Aurora, to have an alternative both to arm twist Oracle into a better deal for MySQL 5.7, but also a fallback position should Oracle refuse to bargain.
Now that whole subject has been rendered null and void with this announcement. The MySQL community will now have a direct replacement, with improvements, from the 5.6.x installations into MariaDB 10.x and the Oracle (toll booth) issue can now be side stepped entirely.
I have already indicated to my management that this move should be undertaken as soon as is viable.
I’m testing Aurora, and now I can’t talk about it. But I believe I understand why its named Aurora.
Being a user of MySQL (5.6) on the Amazon RDS I was impressed with the announcement of Aurora. Having said that I was also suspicious as to it’s providence. Nowhere were there references to it’s origins or engines. Databases and database systems don’t just drop out of the sky.
Amazon were also was making comparisons to MySQL version 5.6, not the newest version 5.7.x. This is interesting as I have been fighting I/O issues in the RDS implementations of MySQL 5.6.x for sometime. Version 5.6 has serious Mutex issues in I/O and from my reading MySQL 5.7 has managed to improve that situation. But the Amazon folks have not managed that upgrade yet.
Software politics being what it is, especially with regards to Oracle, whom own MySQL, indicates that there will be licensing issues with the release of MySQL 5.7.x. Issues that Amazon may be seeking to side step or ameliorate with the threat of Aurora (or MariaDB).
Having said that, many of the DB community seem to be of the opinion that Aurora does not offer anything that can’t be found within the MySQL 5.7 upgrade, as far as performance is concerned.
What does concern me is the lack of transparency about the nature of Aurora. What I see is smoke and mirrors. And frankly in the DB community, that does not lend trust to the Aurora project of Amazon’s. Not a good thing where trust, and dependability are Keys. (pun intended)
It is with sadness that I had to turn off the last Sybase Instance we had running. Our last ASE server quietly shutdown on an Amazon EC2 server on Tuesday the 20th of December, never to boot again.
In all truth both Sybase instances were developer installs operating as production systems. Our two instances, operating with the 25 user limit that each was restricted to, was barely able to operate the system. But the Sybase Licensing was too archaic and inflexible to continue operating it as a small business. Thus the economics forced us to convert to MySQL.
If it hadn’t been for the previous management, who in some delusion of saving money, refused to pay the datacenter bill, forcing us to move the Sybase instances out into the Amazon cloud (EC2) in the first place we would probably have been on MySQL sooner, as that was the plan.
But the sadness remains, Sybase as a technology proved again that it would run, and run reliably, on just about any hardware, even when it was virtual, and NOT meeting the specified certified, requirements of operation. Which can’t be said for the Amazon RDS version of MySQL, which crashed spontaneously while applying an index on our live production database without warning. This having happened after weeks of testing and trial runs at operating the system on it. The only defense, the RDS instance rebooted and was available without data loss, in less time than a Sybase HA switchover would have taken, a system this production system was developed from.
So we are up in MySQL and I am now a MySQL DBA exclusively, after spending the last 25 years as a Sybase DBA and evangelist. The decision now has to be rather to remain so, or find another place of employment where Sybase remains. Those are becoming more and more rare. Maybe I should takeup MongoDB to stay at the cutting edge.
Over the past week I found myself in a situation as follows, during a migration, conversion from a Sybase Production server to a MySQL based version, I was required to ‘expedite’ a Sybase 15 ASE installation into an Amazon (EC2) instance, The Cloud!
The company has been in the position of seeking less expensive IT infrastructure over the past few years, moving from Sun Enterprise servers with ASE clustering to commodity Intel based Redhat Sybase servers with poor mans replication. The final goal became a decision to convert the expensive Sybase ASE (read inflexible licensing), to MySQL, and generally into the Amazon RDS (cloud).
The move of a Sybase ASE into the Cloud was the result of an urgent desire to terminate a data-center contract early by management. The shrinking time line for the conversion of the Sybase schema to MySQL could not be guaranteed so a Plan B had to be created. Hence, the Cloud based Sybase production edition of a production server.
To my surprise, it works! after a bit of twisting, the Redhat ASE developer installation came off more or less just like any other Sybase install. There are irregularities from a normal Linux install, but functional. Being a bit of a spindle jockey, I was surprised (happily) at the overall performance of the storage systems of the EC2 instance. And the production server is now operating in the instance. (having previously moved the app and web servers into the EC2)
This post needing a point to make, is this, while working this issue, I did considerable Googling for anyone using Sybase ASE in the cloud, and nothing! or nearly nothing. What I did find first, a press release from Sybase corporate that they were now in the Amazon Cloud, dated in 2009, and not a peep since. Nothing, no product, no advertising, no options. What a missed opportunity, it’s now easy to see why Sybase has been loosing so much market to a ‘free’ RDBMS like MySQL.
My first Home PHP project, IdeaForecasting, has yet to draw a great deal of interest, but most of the search engines have found it. In fact the Chinese have taken a great interest in the form of BaiDuSpider!
I wish the Idea of IdeaForecasting would take off, but I haven’t really publicized it yet. In the mean time I’m learning a great deal about PHP, MySQL and OpenSolaris.
Even though my workplace and reduced costs by migrating from Sybase on Solaris to Sybase on redhat. We are now in a move from Sybase to MySQL to further reduce the license costs of the applications. This has brought to forefront one of the reasons to use Sybase. Triggers and stored procedures. And while MySQL now provides both, and transactions in InnoDB engines, Sybase triggers and Procedure are far more advanced. This forms a type of trap, they are very useful, but create serious obstacles to convert triggers that perform Referential Integrity. Just to highlight two types of these issues, take the following;
You can not use ‘select’ criteria in a trigger that returns a value. This prevents executing a select on a table to check for the existence of record prior to an insert/update. This was a major issue with a trigger used to produce a history file via a ‘update’ that had to both insert and update the history table. My workaround was to create a MySQL procedure that had no such restriction, and to call the procedure from the trigger. This worked very well, but of course meant that there was additional overhead and more coding involved.
The second example was, in my opinion, was a far more severe omission of Referential Integrity, ‘Rollback’! You cannot perform a rollback in a trigger. What! Further more, you have use ‘set autocommit=0’ either as a database default, which it is not, by default, set. Or set it during the batch or client operation that you are performing. Twice bad! Again, my solution was to call a procedure that could perform a ‘rollback’ and to ensure that either the developer set autocommit off or to insure that it was set as a database wide option.
As easy as these solutions were, they highlight an omission of functionality that requires addressing in the future development of MySQL.