It's the time of the year again: You have 2 more weeks to submit a great proposal to the biggest and baddest MySQL Conference: Percona Live MySQL Conference and Expo 2013 (Santa Clara). Like many things in the MySQL community, this conference has also gone through a transformation over the past 3 years. But last year the growing pains and uncertainty ended with Percona putting up a great show. Attendance was up again (over 1000) and there was a sense of energy and excitement for the future of MySQL. If you are like me and like to dwell in nostalgia (so that you can get into the right mood for submitting great proposals) my coverage of last year's conference is found here: part 1,

It is almost an everyday task for developers to ensure the schema are in sync in their test/development/production databases. No doubt that everyone who works with MySQL servers will encounter situations where schema should be synchronized. When this happens, there must be a reliable solution where it should work in any complex situation.

Challenge:

You have made numerous MySQL schema changes to your databases during development of a new feature. Now you want to sync development and production schemas so that they match when you

InnoDB implements a mutex and rw-lock using pthread synchronization objects when compiled for Linux. These add a great feature -- SHOW INNODB STATUS is able to list the objects and locations where threads are blocked. Unfortunately this comes at a price. The InnoDB mutex uses much more CPU than a pthread mutex for workloads with mutex contention. Feature request 52806 is open for this but the feature request description is vague.

I extracted all of the code needed to use an InnoDB mutex into a standalone file. This includes much of the sync array code. I then added benchmark functions that do the following in a loop: lock the mutex, increment a counter, sleep for a configurable amount of time and then

Do you ever find yourself wanting to open several terminal windows and send the same commands to all of them? I’ve had this need many times, and I’ve never found a completely satisfactory solution. I’ve also known a lot of people who’ve written various sets of scripts to help them accomplish such tasks.

In no particular order, here are a few ways I’ve done this in the past:

The call for papers for Percona Live: MySQL Conference and Expo 2013 has been extended through October 31st. The conference will be held in Santa Clara, California from Monday, April 22nd through Thursday April 25th (and this year it’s not during Passover!).
Why You Should Submit
Percona Live is a meeting of the minds – not just the April Santa Clara conference, but all the Percona Live conferences. If you get a proposal accepted, you get free admission to the conference!
There is no cost to submit, and you do not have to tell anyone you submitted. I have submitted to conferences and been rejected – it stinks. But there is no reason not to submit. Submit a few presentations on different topics, because the presentation you have in mind might be submitted by

I'm honored to accept the role of conference chairman in the upcoming Percona Live MySQL Conference and Expo, April 22th-25th, 2013, Santa Clara, CA. Here are a few administrative announcements:

Call for Papers

Call for papers is extended until Oct 31st. We've already received a good number of submissions, but wish to provide with another chance for latecomers. Now is a good time to submit!

The committee will begin the long reviewing process shortly.

Committee

Members of the reviewing committee are:

• Roland Bouman (Pentaho)
• Ronald Bradford (Continuent)
• Laine Campbell (PalominoDB)
• Colin Charles (MontyProgram)

When your backup script is running for too long it sometimes causes the second backup script starting at the time when previous backup is still running. This increasing pressure on the database, makes server slower, could start chain of backup processes and in some cases may break backup integrity.

Simplest solution is to avoid this undesired situation by adding locking to your backup script and prevent script to start second time when it’s already running.

Here is working sample. You will need to replace “sleep 10″ string with actual backup script call:

#!/bin/bash

LOCK_NAME="/tmp/my.lock"
if [[ -e $LOCK_NAME ]] ; then
        echo "re-entry, exiting"
        exit 1
fi

### Placing lock file
touch $LOCK_NAME
echo -n "Started..."

### Performing required work

The other day I needed to run a simple mysql job to backup and delete some database records on a live server. Being a live server, it is important to make sure you aren't asking the database to take on jobs that could potentially lock it up. Better to run a batch job. Running a batch is simple. You can call it right from the mysql console with:

source [path_to]/[the_batch_script].sql

But what if there are millions of records that need deleting? Bash shell script to the rescue.

Here is the idea of the SQL job that needed to get run a few times

START TRANSACTION;

/* Find what you want to delete and put a LIMIT on your batch size */
CREATE TEMPORARY TABLE records_to_delete_temp SELECT id from `records` where ..... limit 1000;       

/* Creating backup table to archive

After playing a little bit with MySQL 5.6 (RC), and following closely on Giuseppe's MySQL 5.6 replication gotchas (and bugs), I was having some thoughts.

These are shared for a few reasons:

• Maybe I didn't understand it well, and someone could correct me
• Or I understood it well, and my input could be of service to the developers
• Or it could be of service to the users

InnoDB tables in mysql schema

The introduction of InnoDB tables in mysql makes for crash-safe replication information: the exact replication position (master log file+pos, relay log file+pos etc.) is updated on InnoDB tables; with innodb_flush_logs_at_trx_commit=1 this means replication status is