I have been using Google’s Go programming language for a couple of years and basically fell in love with it. About a year ago I started using it for almost all of my MariaDB and MySQL development, and pretty much everything I do unless it involves the python pandas library (a subject for a separate blog, perhaps).

read more

We are pleased to inform you that the new Continuent Tungsten 2.0.2 is now available. Continuent Tungsten keeps data available to applications 7x24 through hardware failures, maintenance, and software upgrades. It ensures business continuity and performance by keeping up-to-date data closer to the user, and increases application throughput and improves response time by load balancing SQL

MySQL 5.6 has added support for EXPLAIN FORMAT=JSON. The basic use case for that feature is that one can look at the JSON output and see more details about the query plan. More advanced/specific use cases are difficult, though. The problem is, you can’t predict what EXPLAIN FORMAT=JSON will produce. There is no documentation or any kind of convention regarding the contents of JSON document that you will get.

To make sure I’m not missing something, I looked at MySQL Workbench. MySQL Workbench has a feature called Visual Explain. If you want to use, prepare to seeing this a lot:

In Workbench 6.1.4 you get it for (almost?) any query with subquery. In Workbench 6.1.6 (released last week), some subqueries work, but it’s still easy to hit a query whose EXPLAIN JSON output confuses workbench.

Looking at the source code, this seems to be just the start of …

An article about moving data into Hadoop in real-time has just been published over at DBTA, written by me and my CEO Robert Hodges.

In the article I talk about one of the major issues for all people deploying databases in the modern heterogenous world – how do we move and migrate data effectively between entirely different database systems in a way that is efficient and usable. How do you get the data you need to the database you need it in. If your source is a transactional database, how does that data get moved into Hadoop in a way that makes the data usable to be queried by Hive, Impala or HBase?

You can read the full article here: Real-Time Data Movement: The Key to Enabling Live Analytics With Hadoop

Filed under: …

In this virtual course, you will learn how to get from a single database server to a scalable cluster, or from a brittle MySQL replication system to a transparent, manageable Continuent Tungsten cluster. 

We discuss the benefits of leveraging Continuent Tungsten clustering with MySQL, and walk you through the steps to implement a Continuent Tungsten cluster in Amazon EC2.

MySQL Enterprise Monitor 2.3.17 is now available for download on the My Oracle Support (MOS) web site. This is a maintenance release that updates various third party components. You can find more information on the contents of this release in the change log.

You will find binaries for the new release on My Oracle Support. Choose the "Patches & Updates" tab, and then choose the "Product or Family (Advanced Search)" side tab in the "Patch Search" portlet.

Important: MEM 3.0 offers many significant improvements over MEM 2.3. If you have not already analyzed upgrading any remaining 2.3 installations to MEM 3.0, we highly recommend you do so. More information on MEM 3.0 is available here:

• …

If you run multiple MySQL environments on multiple servers it’s a good habit to set your MySQL prompt to double check which server you are on.
however, using the MYSQL_PS1 environment variable I found this does not work under sudo (the normal way people run sudo).

I.e., the following syntax’s work.

$ mysql
$ sudo su - -c mysql
$ sudo su - ; mysql

but the following does not.

$ sudo mysql

The trick is actually to ensure via /etc/sudoers you inherit the MySQL_PS1 environment variable.

echo "export MYSQL_PS1="`hostname` [d]> "" | sudo tee /etc/profile.d/mysql.sh
echo 'Defaults    env_keep += "MYSQL_PS1"' | sudo tee /tmp/mysql
sudo chmod 400 /tmp/mysql
sudo mv /tmp/mysql /etc/sudoers.d

In the MySQL team, we are changing the system tables currently located in the mysql schema from MyISAM to InnoDB.

Looking at this historically:

• MyISAM was the default storage engine up until MySQL 5.5.
• In 5.5 almost 4 years ago, the default storage engine changed to InnoDB, however system tables used for features such as storing privileges and timezones remained as MyISAM.

Unlike MyISAM, InnoDB is an ACID compliant storage engine, with the behaviour that once a transaction commits, modifications are able to survive power-loss or other failures. This is a solid foundation to build applications on, since developers will need to handle fewer failures. To use an example:

1. Customer places an order
2. A confirmation email is sent
3. Power is lost

Without durability, (2) could occur with no record of (1) occurring! …

After upgrading from MySQL 5.5 to 5.6, I started getting some warnings when running queries in common_schema. For example:

+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | Warning | 1109 | Unknown table 'innodb_index_stats' in information_schema | | Warning | 1109 | Unknown table 'innodb_index_stats' in information_schema | | Warning | 1356 | View 'common_schema.processlist_repl' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them | | Warning | 1356 | View 'common_schema.processlist_top' references invalid …

The recent WebScaleSQL announcement has made quite a splash in the MySQL community over the last few weeks, and with a good reason. The collaboration between the major MySQL-at-scale users to develop a single code branch that addresses the needs of, well, web scale, is going to benefit the whole community. But I feel that the majority of community opinions and comments to date have been based on the announcement itself and the organizational matters only. What we have been missing is an actual look at the code. What actual new features and bug-fixes are there? Let’s take a look.

At the same time, as Percona is also a developer of an enhanced MySQL replacement database server, it’s natural to …