The MySQL Developer Tools team is pleased to announce the availability of the third beta release of MySQL Workbench 6.0. MySQL Workbench 6.0 is the new major update of the Development and Administration tool for MySQL. This release includes almost 200 bug fixes (~40 since 6.0.3), 30 new features and a new redesigned UI. As a beta, this release is not suitable for production use.  Please test and file your bug reports at http://bugs.mysql.com

As always, MySQL Workbench is natively available on Windows, Mac, Linux.

Improvements in MySQL Workbench 6.0:

• a new redesigned Home screen
• the SQL Editor and Server Administration UIs were merged into a single connection specific interface, allowing for quick access to administration features while simplifying the location of specific features
• improved model Synchronization, lets you …

It was once said that “real artists ship.” In looking over the history of Percona software releases, we are currently shipping more software than ever before.

First, let’s look at Percona Server. Let’s look at all major versions: 5.1, 5.5 and 5.6 as well as the total for each year. The estimate for 2013 comes from assuming the second half of 2013 is similar to the first half.

Percona Server releases per year

In 2011, when Percona Server 5.5 came along, we see a sharp reduction in Percona Server 5.1 releases (remember that there’s at least one Percona Server 5.1 release for each Oracle MySQL 5.1 release, and this reduction is likely a reflection of the reduction of releases from Oracle). In 2011, 2012 and 2013 we see a pretty steady number of Percona Server 5.1 releases. It seems that 5.1 is not going anywhere yet.

For Percona Server 5.5, we see an increase in 2012, which likely mirrors an …

And all set. Check out the recording:

Hello everybody!

Coming up this Wednesday, July 23rd, 2013 at 12:00pm pacific (19:00 GMT) join in to hear:

• Brandon Johnson from Mozilla talk about an issue he recently worked through with XtraBackup and the process he took to identify and resolve the issues.

And also take part in discussion around:

• How do you apply production schema changes?
  • Do you use pt-online-schema-change?
    • Issues to watch out for
  • Just run the alter!
  • Pull from a pool and apply

Make sure to follow the #DBHangops twitter search, the DBHangops Twitter Feed, or this blog …

In MySQL a big portion of the problems you’re facing is different replication delays so there’s no surprise this is one of the most common interview questions on DBA interviews and I still found people having problems with explaining what they would do in a certain situation. This is why I decided to write a bit about the subject.

1. IO

99% of times the reason is IO. The slave cannot keep up with the amount of writes it gets from the binary logs while in parallel it has to return results of queries as well. In spite of the common belief in MySQL it’s much easier to saturate the disk subsystem (even a raid 10 with 8 SAS disk and cache) than the network.

In this situation all you can do is try to remove some pressure from the slaves.

One way to do this is setting innodb_flush_log_at_trx_commit  to 2 if it used to be 1. Usually this is enough.

Every once in a while the Continuous Integration reminds me that the code I write isn't "that" portable. I develop on Linux, push to the SCM and the CI goes out and builds on several Unixes and Windows.

Fixing windows build issues through the CI takes quite a while. It is far easier to have a local windows build-environment around to do the build, testing before you push. You could make that quite efficient by installing Windows in a VM, use shared-folders, use cygwin+sshd to log into it from the command-line ...

... or you simplify it even more and just use wine.

The main reason for me to go this path:

• I don't need a GUI (I could start the VM headless)
• I don't want to polute windows with cygwin (I could use WinRM)
• I don't need most of the things a full …

One of my favorite MySQL tools ever is pt-query-digest. It's the tool you use to generate a report of your slow query log (or some other supported sources), and is similar to for example the Query Analyzer in MySQL Enterprise Monitor. Especially in the kind of job I am, where I often just land out of nowhere on a server at the customer site, and need to quickly get an overview of what is going on, this tool is always the first one I run. I will show some examples below.

read more

How InnoDB work with transactions:

When any transaction will be completed with COMMIT,  InnoDB will write those changes in InnoDB Buffer Pool. After that InnoDB will run some background operations like checkpoint.  Checkpoint is the most important operation which will writes the changes on disk.   Lets see how it will work.

During the checkpoint phase, InnoDB writes dirty pages to the double write buffer, and then writes pages from the doublewrite buffer to the actual tablespace. During checkpointing, as pages are flushed to the actual tablespace making the data changes persistent on disk, log_sequence_numbers (LSN) are also updated on the pages. The LSN info written to the page is what identifies whether a data page has current data or not, during the crash recovery phase.

How InnoDB does crash / auto …

Valeriy has mentioned that MySQL manual has no documentation about EXPLAIN FORMAT=JSON feature. There was a bug filed for this since September, 2012. I had spent some time looking at EXPLAIN FORMAT=JSON, so I thought I would share my findings.

The first blog post about EXPLAIN FORMAT=JSON was made by Sheeri. She listed these features of FORMAT=JSON:

• attached_condition and implicit casts
• used_key_parts field

In addition to those, I was able to find

• Pushed index condition information
• More information about sorting/grouping
• Subquery …

"mysqldump requires at least the SELECT privilege for dumped tables, SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK TABLES if the --single-transaction option is not used. Certain options might require other privileges as noted in the option descriptions."
- http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html

It is everywhere in the world of MySQL that if your replication is broken because an event caused a duplicate key or a row was not found and it cannot be updated or deleted, then you can use ‘

STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;

 ’ and be done with it. In some cases this is fine and you can repair the offending row or statements later on. But what if the statement is part of a multi-statement transaction? Well, then it becomes more interesting, because skipping the offending statement will cause the whole transaction to be skipped. This is well documented in the manual by the way. So here’s a quick example.

3 rows on the master:

master> select * from t;
+----+-----+
| id | pid |
+----+-----+
|  1 |   1 |
|  2 |   2 |
|  3 |   3 |
+----+-----+
3 rows in set (0.00 …