Overview The Skinny

Database Proxies provide a single entry point into MySQL for the calling client applications.

Proxies are wonderful tools to handle various situations like a master role switch to another node for maintenance, or for transparency with read and write connections.

However, when the time comes to perform the switch action, all of the calling clients have been funneled through the proxy, so identification of the calling host from the database itself becomes difficult.

The Problem What is going on?

Let’s illustrate how not knowing the source of a client connection can be an issue for the database administrator…

In the following diagram, three client applications connect to a Tungsten Cluster via the Connector proxy:

…

When you use SHOW VARIABLES LIKE “have_%” to see whether a particular feature is enabled, you will note the value of NO for some, and DISABLED for others. These values are not intrinsically clear for the casual onlooker, and often cause confusion. Typically, this happens with SSL and InnoDB. So, here is a quick clarification!

• NO means that the feature was not enabled (or was actively disabled) in the build. This means the code and any required libraries are not present in the binary.
• DISABLED means that the feature is built in and capable of working in the binary, but is disabled due to relevant my.cnf settings.
• YES means the feature is available, and configured in my.cnf.

SSL tends to show up as DISABLED, until you configure the appropriate settings to use it …

The South East LinuxFest is this weekend (June 7-9) in Charlotte, North Carolina and SkySQL will be attending the conference both as a sponsor and with talks. 

read more

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

Getting to Know MySQL Enterprise Monitor

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the …

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

Getting to Know MySQL Enterprise Monitor

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the …

Note: This article is about the WHERE extension to SHOW. I specifically use SHOW STATUS as an example, but WHERE is an extension to many SHOW statements.

Often DBAs will assess the health of a system by looking at some of the status variables returned by SHOW GLOBAL STATUS (specifying GLOBAL is important; remember that SHOW STATUS is the same as SHOW SESSION STATUS).

There are many status variables that SHOW GLOBAL STATUS returns. (SHOW GLOBAL STATUS on a Windows machine, MySQL version 5.0.67 returned 249, 5.1.22 returned 256 and 6.0.6-alpha returned 295 status variables!). I have used the SHOW STATUS LIKE syntax to help give me the output I really want, particularly when I forget the exact names of the status variables I am looking for.

But I did not know of a way to …