This is not quite a liveblog, but a set of notes about the points I found most interesting in this morning’s Linux Conf AU keynote, given by Dr. Andrew “bunnie” Huang, best known for Hacking the Xbox and developing the chumby.

The talk was a fascinating look at how complex developing embedded Linux devices is. Let’s start with the takeaways:

One of the points bunnie made was that customizing embedded devices is really a frontier at this point (though he did not use the word “frontier”). There are not a lot of folks doing it. The “Sustainability” bullet point emphasizes this – bunnie talked about how people create custom environments for the device and want updates pushed to it, but that’s difficult because the environment may mean special tweaks to the updates.

The cost point was interesting …

Sheeri wrote a blog post that claims that “IN Subqueries in MySQL 5.6 Are Optimized Away” and uses that as a basis to conclude that subquery optimizations in MySQL 5.6 are superior to MariaDB’s.
The claim is incorrect (and so is the conclusion). As a person who has coded both of the mentioned FirstMatch and semi-join materialization, I think I need to write about this.

Sheeri wrote:

1. “So MariaDB recognizes the subquery and optimizes it. But it is still optimized as a subquery”
2. “In MySQL 5.6, the subquery is actually optimized away”

The first statement is somewhat true. The second one is not. …

Standard MySQL is configurable such that a single master server can be clustered with a number of read-only slave servers. To enable this master-slave replication, master’s transaction logs are communicated to the slaves (log shipping). Log shipping is a form of asynchronous replication. Under this configuration, the data on the slave always remains behind the master, a condition referred to as slave lag or replication lag. The extent of the slave lag depends on workload, network bandwidth and network latency. Database reads can be served out of the slaves, assuming the application has been designed to tolerate the slave lag and requisite staleness of data (eventual consistency), which can at times be variable and opaque. MySQL master-slave replication offers the possibility of promoting a slave to become the new master should the master fail, but this is very painful to do in practice. The cluster has to stop taking ANY writes while it waits for …

MySQL Users Group, please let us know you schedule so we can help promote your events. And if you are interested in starting a MySQL — let us know as we can help.

The MySQL Community Team wants to make sure you do not miss out on upcoming shows.

Fosdem is this coming weekend and there will be a MySQL and Friends devroom. This show in Brussels features presentations from Lars Thalmann, Sveta Smirnova, Luis Soares, Giuseppe Maxia, Øystein Grøvlen, and many more.

MySQL is a sponsor of the SunShine PHP and Ligaya Trumelle will be presenting on MySQL.

The Rocky Mountian orage Users Group will hold their training days February 11th through the 13th with a very interesting …

Actian acquires Pervasive. ObjectRocket has liftoff. And more.

For 451 Research clients: Actian’s persistence pays off as Pervasive agrees to $162m acquisition bit.ly/WPiGiS

— Matt Aslett (@maslett) January 30, 2013

For 451 Research clients: ObjectRocket has liftoff for MongoDB database as a service bit.ly/WuqF6R

— Matt Aslett (@maslett) January 29, 2013

Pervasive Software Inc. Enters Into Agreement to be Acquired by Actian Corporation bit.ly/TQ3J3t

— Matt Aslett (@maslett) January 29, …

New GreenSQL 2.3 Version Strengthens Underlying Database Security Technology While Further Simplifying User Experience

GreenSQL new version is easier to configure and manage locally and on the cloud

The newest version of GreenSQL, 2.3, makes it even simpler to secure databases with its streamlined configuration and Amazon cloud compatibility.

GreenSQL provides unified database security protection against SQL injection attacks and other internal and external threats via database activity monitoring, real-time dynamic data masking, and database security.

• Version 2.3’s database security policy automatically detects SQL injection attempts. To ease administration, it automatically detects both the operating environment and database session identifiers (user, database, source IP, and application). By pushing activity monitoring logs …

Last year, when I was speaking about MySQL performance at Devconf in Moscow, I expected my audience will be very experienced as this always happen at all PHPClub conferences. So I had to choose: either make full-day seminar and explain people every basic of performance, or rely on their knowledge and make some one and half hours seminar. I prefer short speeches, so I considered latter.

But even with such a mature audience you don't always know if they knew some or another basic thing. Like somebody can be good analyzing EXPLAIN output and other is in reading InnoDB Monitor printout. Also, native language of the audience is not English and it would be always good to have short reference to simple things, described in their native language. In this case Russian. This is why I created …

The MySQL & Cloud Solutions Day will take place at the Hyatt Regency Santa Clara, immediately following Percona Live: MySQL User Conference and Expo 2013

read more

We continue to improve Percona XtraBackup, and today I would like to give a preview for one feature which comes in next Percona XtraBackup 2.1 release.

This feature is “Compact backups”, and let me explain what it does.
As you may know InnoDB PK (Primary Key) contains all data, and all secondary indexes are only subset of columns of Primary Key. So in theory we can store only PK, and re-build secondary indexes as we need. Well, now it is possible not only in theory.

To create a compact backup you should use
innobackupex --compact
and it will create a backup where all InnoDB tables contain only Primary Keys and not secondary.
It allows to safe some space on a backup storage. How much? Well, it depends on how many indexes you have.
…

In MySQL 5.6, it looks like IN() subqueries are optimized even better than they are in MariaDB 5.5. Here’s a typical IN() subquery, using the sakila sample database (query taken from slide 6 of the presentation about new MySQL 5.6 optimizer statistics):

SELECT title FROM film WHERE film_id IN (SELECT film_id FROM film_actor)

Before there were any subquery optimizations, say if you are using MySQL 5.1, you would have to rewrite this query as a JOIN, to avoid the dreaded DEPENDENT SUBQUERY that shows up in the EXPLAIN:

mysql> explain SELECT title FROM film WHERE film_id IN (SELECT film_id FROM film_actor)\G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: film
type: index
possible_keys: NULL
…