The latest from the MySQL community

I found Dennis the Menace, he now has a job as system administrator for a hosting company. Scenario: client has a problem with a server becoming unavailable (cause unknown) and has it restarted. MySQL had some page corruption in the InnoDB tablespace.

The hosting provider, being really helpful, goes in as root and first deletes ib_logfile* then ib* in /var/lib/mysql. He later says “I am sorry if I deleted it. I thought I deleted the log only. Sorry again.”  Now this may appear nice, but people who know what they’re doing with MySQL will realise that deleting the iblogfiles actually destroys data also. MySQL of course screams loudly that while it has FRM files it can’t find the tables. No kidding!

Then, while he’s been told to not touch anything any more, and I’m trying to see if I can recover the deleted files on ext3 filesystem (yes there are tools for that), he goes in again and puts an ibdata1 file back. No, …

All DBAs understand the importance and priority of quick, reliable database backup and recovery operations.  In fact, dating back to my early days with MySQL, the most commonly requested product features from the MySQL user base have been around online, non-blocking backup solutions for running MySQL servers.  In response, Oracle now provides MySQL Enterprise Backup ("MEB") which performs high performant, online "hot" backups for MySQL databases.  MEB provides all of the backup/recovery features and functionality DBAs expect, all from a scriptable command line interface.  You can learn all about MEB in the related MySQL docs.

My congratulations and appreciation go out to Lars Thalmann and the MySQL Enterprise Backup engineering team for the …

There are two ways InnoDB can organize tablespaces. First is when all data, indexes and system buffers are stored in a single tablespace. This is typicaly one or several ibdata files. A well known innodb_file_per_table option brings the second one. Tables and system areas are split into different files. Usually system tablespace is located in ibdata1 file and every InnoDB table has two files e.g.  actor.frm and actor.ibd.

The annoying thing about .ibd files you can’t easily copy the an .ibd file to another MySQL server. If you try to very often you’ll get an error in the log:

InnoDB: Error: tablespace id is 10 in the data dictionary
InnoDB: but in file ./sakila/actor.ibd it is 15!

However sometimes you have to connect the .ibd file to an alien ibdata1.

There are several situation when you have to:

1. ibdata1 is erroneously removed

2. ibdata1 is …

A user on a linux user group mailing list asked about this, and I was one of the people replying. Re-posting here as I reckon it’s of wider interest.

> [...] tens of gigs of data in MySQL databases. > Some in memory tables, some MyISAM, a fair bit InnoDB. According to my > understanding, when one doesn’t have several hours to take a DB > offline and do dbbackup, there was/is ibbackup from InnoBase.. but now > that MySQL and InnoBase have both been ‘Oracle Enterprised’, said > product is now restricted to MySQL Enterprise customers.. > > Some quick searching has suggested Percona XtraBackup as a potential > FOSS alternative. > What backup techniques do people employ around these parts for backups > of large mixed MySQL data sets where downtime *must* be minimised? > > Has your backup plan ever been put to the test?

You should put it to the test regularly, not just when it’s needed. …

On September 8, 2010 Oracle announced the availability of Oracle Solaris Cluster 3.3

Oracle Solaris Cluster 3.3, built on the solid foundation of Oracle Solaris, offers the 
most extensive Oracle enterprise High Availability and Disaster Recovery solutions for the 
largest portfolio of mission-critical applications.

Integrated and thoroughly tested with Oracle's Sun servers, storage, connectivity 
solutions and Solaris 10 features, Oracle Solaris Cluster is now qualified with Solaris 
Trusted Extensions, supports Infiniband for general networking or storage usage, and can 
be deployed with Oracle Unified Storage in Campus Cluster configurations. It extends its 
applications support to new Oracle applications such as Oracle Business Intelligence, 
PeopleSoft, TimesTen, and MySQL Cluster.

The single, integrated HA and DR solution enables multi-tier deployments in virtualized 
environments. In this release, Oracle Solaris Containers clusters supports even more 
configurations …

On September 8, 2010 Oracle announced the availability of Oracle Solaris Cluster 3.3

Oracle Solaris Cluster 3.3, built on the solid foundation of Oracle Solaris, offers the 
most extensive Oracle enterprise High Availability and Disaster Recovery solutions for the 
largest portfolio of mission-critical applications.

Integrated and thoroughly tested with Oracle's Sun servers, storage, connectivity 
solutions and Solaris 10 features, Oracle Solaris Cluster is now qualified with Solaris 
Trusted Extensions, supports Infiniband for general networking or storage usage, and can 
be deployed with Oracle Unified Storage in Campus Cluster configurations. It extends its 
applications support to new Oracle applications such as Oracle Business Intelligence, 
PeopleSoft, TimesTen, and MySQL Cluster.

The single, integrated HA and DR solution enables multi-tier deployments in virtualized 
environments. In this release, Oracle Solaris Containers clusters supports even more 
configurations …

On September 8, 2010 Oracle announced the availability of Oracle Solaris Cluster 3.3

Oracle Solaris Cluster 3.3, built on the solid foundation of Oracle Solaris, offers the 
most extensive Oracle enterprise High Availability and Disaster Recovery solutions for the 
largest portfolio of mission-critical applications.

Integrated and thoroughly tested with Oracle's Sun servers, storage, connectivity 
solutions and Solaris 10 features, Oracle Solaris Cluster is now qualified with Solaris 
Trusted Extensions, supports Infiniband for general networking or storage usage, and can 
be deployed with Oracle Unified Storage in Campus Cluster configurations. It extends its 
applications support to new Oracle applications such as Oracle Business Intelligence, 
PeopleSoft, TimesTen, and MySQL Cluster.

The single, integrated HA and DR solution enables multi-tier deployments in virtualized 
environments. In this release, Oracle Solaris Containers clusters supports even more 
configurations …

In my previous posts I highlighted that one of improvements in Percona Server is support of innodb_log_file_size > 4G. This test was done using Percona Server 5.5.7, but the same performance expected for InnoDB-plugin and MySQL 5.5.

The valid question how long is recovery in this case, so let's test it. I took the same tpcc-mysql 1000W workload with 52GB and 144GB innodb_buffer_pool_size with data located on Virident tachIOn card and killed mysqld after 30 mins of work.

The recovery time after start is:
for 52GB innodb_buffer_pool_size:

PLAIN TEXT CODE:

1. 101220 …

Although MyISAM has been the default storage engine for MySQL but its soon going to change with the release of MySQL server 5.5. Not only that, more and more people are shifting over to the Innodb storage engine and the reasons for that is the tremendous benefits, not only in terms of performance, concurrency, ACID-transactions, foreign key constraints, but also because of the way it helps out the DBA with hot-backups support, automatic crash recovery and avoiding data inconsistencies which can prove to be a pain with MyISAM. In this article I try to hammer out the reasons why you should move on to using Innodb instead of MyISAM.

Before I start a story about the data recovery case I worked on yesterday, here's a quick tip - having a database backup does not mean you can restore from it. Always verify your backup can be used to restore the database! If not automatically, do this manually, at least once a month. No, seriously - in most of the recovery cases I worked on, customers did have some sort of backup, but it just wasn't working, complete and what not. Someone set it up and never bothered to check if it still works after a while.

Anyway, this post is not really about the backups but rather about few interesting things I learned during last recovery case.

First, some facts about the system and how data was lost:

• MySQL had a dedicated partition on XFS file system
• Server was running innodb_file_per_table
• There was a …