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 …

I have a 5G mysqldump which takes 30 minutes to restore from backup.  That means that when the database reaches 50G, it should take 30x10=5 hours to restore.  Right?  Wrong.

Mysqldump recovery time is not linear.  Bigger tables, or tables with more indexes will always take more time to restore.

If I restore from a raw backup (LVM snapshot, xtrabackup, innodb hot backup), it is very easy to model how much longer recovery time will take:

Backup is 80G
Copy is at 70MB/s.
10G is already complete.
= ((80-10) * 1024)/70/60 = ~17 minutes


I can tell progress with mysqldump by monitoring the rate at which show global status like 'Handler_write'; increases and compare it to my knowledge of about how many rows are in each table.  But progress != a magic number like "17 minutes".  Not unless I do a lot of complex modeling.

I am …

MySQL is the most popular open-source database in the world. It has the distinction of being the only database that is used in every continent. Yes, even Antartica!!! The reasons for such popularity is its availability, performance, robustness, etc. It provides three types of database engines, MyISAM, InnoDB, and MySQL Archive. Out of these, the MyISAM table is the default table type. It is fast, simple, and allows full-text searching. Although it is reliable, it can become corrupt and, thus, inaccessible following a system crash. You should use appropriate corrective measures to repair MySQL database. However, if you are not able to do so then you should use a third-party MySQL recovery software to do so.

Consider a scenario wherein you have MySQL 5.0.22 database running in your system. You use it for MediaWiki installation that is reported as corrupt. When you try to repair the table, the following error message is displayed:
…

Any corruption in MyISAM table is a terrible situation for Database Administrator. These MyISAM tables are the most important components in the MySQL Database to store personal as well as professional data, and the corruption in these tables may inaccessibility to the database. In this situation, a database backup allows you to restore the database and access the records in the table. Duplicate file (Backup) of the database is mostly stored on a different storage media, the changes of database corruption still exist. In that situation, you will need to perform MySQL database repair by the using of third party software.

Some error messages that enable you to identify that your MyISAM table (student) is corrupt:

“Student.frm is locked against change”
Or
“Got error message student from table handler”

Or
“Can't find file student.MYI (Errcode: nnn)”

The record …

Crash Safety is a big deal in the database league. Lack of durability can lead to all sorts of terrible things upon a catastrophic event. Many projects, especially in the so called NoSQL world compromises crash safety in return for higher QPS. The argument there is that the availability of the overall system should be accomplished by replication since a database server can’t be rescued if the physical disk breaks. I happen to agree with this philosophy but I am also aware that this isn’t a correct answer for everyone. So, what will I do with BlitzDB?

Several relational database hackers have pointed out that BlitzDB isn’t any safer than MyISAM since it doesn’t guarantee crash safety. This is currently true but I plan on making BlitzDB much safer than MyISAM by providing following features.

1. Auto Recovery Routine (startup option)
2. Tokyo Cabinet’s Transaction API (table-specific option)

The …