I just tried out EXPLAIN UPDATE in MySQL 5.6 and found unexpected results. This query has no usable index:

EXPLAIN UPDATE ... WHERE col1 = 9 AND col2 = 'something'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: foo
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 55
          ref: NULL
         rows: 51
        Extra: Using where

The EXPLAIN output makes it seem like a perfectly fine query, but it’s a full table scan. If I do the old trick of rewriting it to a SELECT I see that:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: foo
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 51
        Extra: Using where

Should I file this as a bug? It seems like one to me.

MySQL has exceptional track of record by introducing minor fixes that cause major breakages. Though usually I could blame naiveté of engineers, who did not really ever have to deal with production implications, but lately I can start sensing various business implications against open-source offerings.

As an original author of mydumper I really cannot get out of my mind that 5.5 and 5.6 metadata locking changes are there to screw with anyone who is building a backup solution using stable snapshot views of MySQL (for example, mysqldump –single-transaction, the golden standard of backing things up in MySQL world).

As seen in a bug #71017 (palindrome!) filed by my esteemed colleague Eric, newly introduced behaviors …

Thanksgiving is almost here. We would like to take this opportunity to thank all our users, customers, corporate clients and fans of SQLyog, MONyog for all the support over the years.

We thought we’d get the festivities started a little early by offering a 20% flat discount on all Webyog products. Offer expires on November 27, 2013 at 23:59 PST. Grab the offer before it’s gone.

Head right away to the Online Shop and apply the coupon code: tg2013.

Cheers,
Team Webyog

Tweet

The post Thanksgiving Offer – 20% off …

You should take care when changing schema in a MySQL/InnoDB database cluster. But exactly how much care? that you can find out in next Galera webinar session hosted together with Severalnines:

The webinar goes through best practices for database schema changes in online system, with all Do's and Dontcha's listed. Session date will be Dec 3 and there will be two sessions targeted conveniently for EMEA and US timezones. You can register your seat through following links:

• Europe/MEA/APAC
• North America/LatAm

…

This week we talk about how to install and use the MariaDB Audit plugin, and what the audit log looks like. Ear Candy presents a gotcha with MySQL and temporary directories, and At the Movies is about using Dynamo for more than just a data store.

Events
DB Hangops - every other Wednesday at noon Pacific time

Upcoming MySQL events

Training
SkySQL Trainings
Tungsten University trainings

read more

In general, I chose Google Cloud Storage to store web sites MySQL backups due to its price and speed of upload/download in real time

I used the Google native tool – gsutil , innobackupex and some bash

in short : the /etc and local MySQL  backup

#!/bin/sh
# Barcelona Tue Nov 22 17 16:30:36 CEST 2013

days_to_keep=3
NFS=/home/mysql.backups/
exportDate=`date +%Y-%m-%d.%H.%M.%S`
export_DIR=${NFS}/${HOSTNAME}.${exportDate}
test ! -d "${export_DIR}" && echo "$(date) : creating ${export_DIR}" && mkdir -p "${export_DIR}"
export_MySQL_DIR=${export_DIR}/mysql.bckp
export_ETC_DIR=${export_DIR}/etc.bckp
# backup the /etc directory
rsync -avh …

Connector/Python v1.1.3 is available for testing since last week. It is a “beta” release, so it would be great if we even get more feedback. Check out the Change History if you want to keep up with what is being added and changed.

Notable changes for v1.1.3 include a fix for encoding using \x5c or backslashes in multi-byte characters. We also made the code more PEP-8 compliant, which we think is quiet important.

Some useful links:

• Documentation: http://dev.mysql.com/doc/connector-python/en/index.html
• Release Notes: …

Now this is really getting to be ridiculous. Finally was able to obtain a machine with 24 cores (48 with HT) and ran benchmarks. My colleague was able to come fairly close to Dmitri’s 500K numbers. I was getting nowhere with a 12 core (24 with HT) machine, as MySQL 5.5 was routinely faster in simple readonly sysbench benchmarks (both point queries and range selects). If I have to go to management and ask for these types of machines, they would be justified in sending me off to the funny farm.

Now this is really getting to be ridiculous. Finally was able to obtain a machine with 24 cores (48 with HT) and ran benchmarks. My colleague was able to come fairly close to Dmitri’s 500K numbers. I was getting nowhere with a 12 core (24 with HT) machine, as MySQL 5.5 was routinely faster in simple readonly sysbench benchmarks (both point queries and range selects). If I have to go to management and ask for these types of machines, they would be justified in sending me off to the funny farm.

I just tried out EXPLAIN UPDATE in MySQL 5.6 and found unexpected results. This query has no usable index:

EXPLAIN UPDATE ... WHERE col1 = 9 AND col2 = 'something'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: foo
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 55
          ref: NULL
         rows: 51
        Extra: Using where

The EXPLAIN output makes it seem like a perfectly fine query, but it’s a full table scan. If I do the old trick of rewriting it to a SELECT I see that:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: foo
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 51
        Extra: Using where

Should I file this as a bug? It seems like one to me.