The latest from the MySQL community

Continuing on with the cloud theme, I think its worth noting that since mid-2014, Rackspace has offered MariaDB (as well as MySQL and Percona Server) in the cloud, as part of their Cloud Databases offering. It’s powered by OpenStack.

Now there is an additional “High Availability instance” being offered — this gives you up to two replicas per database instance, you have the ability to load balance reads across all replicas (pretty standard), but the cool thing to try out: failover is automatic. …

Mon, 2015-11-09 14:44diptijoshi

MaxScale is an intelligent database gateway for high availability, scalability, security, interoperability and manageability beyond MariaDB and MySQL. As the gateway between client applications and backend databases, MaxScale insulates the client applications from complexities of the backend database servers and clusters.

MaxScale’s architecture is highly configurable consisting of a core and database aware plugin modules. This flexible and configurable plugin architecture of MaxScale has enabled a wide variety of use cases for the community:

• Securing your database
• Minimizing maintenance downtime
• Migrating your database
• Ensuring uptime
• Scaling your database
• Interoperating with other databases

In this blog we look at how MaxScale helps minimize database access down time for client applications. Following …

The "innodb_read_only" parameter is perhaps not among the most commonly used MySQL parameters. It may however influence server behaviour in a way that you may not expect. This post is a record of an investigation that revealed one of MySQL quirks caused by said parameter.
Background The MySQL 5.6 server topology I was looking at during this investigation consisted of a single main server (R/W) and multiple replicas serving read-only statements.
This is relatively simple and you wouldn't expect to run into issues on the replicas as long as you stick to statements that do not modify data, right?
Not quite. Issue I was asked to investigate can be described as follows:
The DBA created two tables connected using a foreign key relationship:

CREATE TABLE `employee` (
  `e_id` int(11) NOT …

Percona is glad to announce the release of Percona Server 5.6.27-75.0 on November 5, 2015. Download the latest version from the Percona web site or from the Percona Software Repositories.

Based on MySQL 5.6.27, including all the bug fixes in it, Percona Server 5.6.27-75.0 is the current GA release in the Percona Server 5.6 series. Percona Server is open-source and free – …

Percona is glad to announce the release of Percona Server 5.5.46-37.5 on November 5, 2015. Based on MySQL 5.5.46, including all the bug fixes in it, Percona Server 5.5.46-37.5 is now the current stable release in the 5.5 series.

Percona Server is open-source and free. Details of the release can be found in the 5.5.46-37.5 milestone on Launchpad. Downloads are available …

Many of our customers use Graphite, and I don’t think anyone would argue with me when I say it’s probably the most commonly used time series database in the DevOps community. Not only does it have a huge installed base, it also has a robust community of advocates and developers, including Jason Dixon, who’s writing a book on monitoring with Graphite. (We featured Jason in our Brainiac Corner a while ago.)

I remember when Graphite first came onto the scene. It was praised to the heavens. Recently, though, the conversation has really changed. Not as many people seem to love it. What happened? The answer points to broader trends in the technology landscape and community.

In The Beginning

I first heard about Graphite from Percona’s …

If you're one of the users having updated HeidiSQL this morning to revision 5002, then you will surely see a crash when starting heidisql.exe . This is due to an accidental commit of a file with unfinished changes from me. Sorry for that. I have just reverted that in revision 5003.

As the program crashes at the very start, you won't be able to update HeidiSQL automatically. As a solution, you can use the installer from that fixed build for updating:
32/64bit: http://www.heidisql.com/installers/HeidiSQL_9.3.0.5003_Setup.exe
32bit only: http://www.heidisql.com/installers/HeidiSQL_9.3.0.5003-32_Setup.exe

See this forum thread for details.

Looking through our exception tracker the other day, I ran across a notice from our slow-query logger that caught my eye. I saw a SELECT … WHERE … LIKE query with lots of percent signs in the LIKE clause. It was pretty obvious that this term was user-provided and my first thought was SQL injection.

[3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10

Looking at the code, it turned out that we were using a user-provided term directly in the LIKE clause without any checks for metacharacters that are interpreted in this context (%, _, \).

def self.search(term, options = {})
  limit = (options[:limit] || 30).to_i
  friends = options[:friends] || []
  with_orgs = options[:with_orgs].nil? ? false : options[:with_orgs]

  if term.to_s.index("@")
    users = User.includes(:profile) …

Looking through our exception tracker the other day, I ran across a notice from our slow-query logger that caught my eye. I saw a SELECT … WHERE … LIKE query with lots of percent signs in the LIKE clause. It was pretty obvious that this term was user-provided and my first thought was SQL injection.

[3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10

Looking at the code, it turned out that we were using a user-provided term directly in the LIKE clause without any checks for metacharacters that are interpreted in this context (%, _, \).

def self.search(term, options = {})
  limit = (options[:limit] || 30).to_i
  friends = options[:friends] || []
  with_orgs = options[:with_orgs].nil? ? false : options[:with_orgs]

  if term.to_s.index("@")
    users = User.includes(:profile) …

Mon, 2015-11-02 09:30geoff_montee_g

Losing temporary tables on a slave when binlog_format is not set to ROW is a well-known problem, and there is even a way to avoid it, as described by the safe slave shutdown procedure in the MySQL documentation. However, the documentation doesn't describe how to fix your slave if you accidentally shut it down while it has temporary tables open. In this blog post, I'll describe how to do that.

The Problem

Let's say that you run these statements on a master server:


-- statement 1
DROP TEMPORARY TABLE IF EXISTS tmp_table;
-- statement 2
CREATE TEMPORARY TABLE tmp_table (
id int primary key,
str varchar(10)
);
-- statement 3
INSERT INTO real_table VALUES (1, 'str1', false, …