We announce next beta version of our xtrabackup tool.

Changelist includes:

- set innodb_fast_shutdown=1 on xtrabackup shutdown
- set innodb_write_io_threads=10 by default for fast buffer_pool flushing during recovery
- build xtrabackup with --with-extra-charsets=complex
Bug #357653: innobackupex-1.5.1 --copy-back fails
Bug #358194: 2nd-phase is very slow
Bug #358266: xtrabackup-0.5 dies with SEGV on bad command line arguments
Bug #359341: innobackupex still does not read defaults-file

You can download current binaries RPM for RHEL4 and RHEL5 (compatible with CentOS also), DEB for Debian/Ubuntu and tar.gz for Mac OS / Intel 64bit there:
http://www.percona.com/mysql/xtrabackup/0.6/.
By the same link you can find general .tar.gz with binaries which can be run on any modern Linux distribution.
…

I am happy to announce next build of our backup tool. This version contains several bugfixes and introduces initial implementation of incremental backup.

Incremental backup works in next way. When you do regular backup, at the end of procedure you can see output:

PLAIN TEXT CODE:

1. The latest check point (for incremental): '1319:813219999'
2. >> log scanned up to (1319 813701532)
3. Transaction log of lsn (1318 3034677302) to (1319 813701532) was copied.
4. 090404 06:03:29  innobackupex: All tables unlocked
5. 090404 06:03:29  innobackupex: Connection to database server closed
6.  
7. innobackupex: Backup created in directory '/mnt/data/tmp'
8. innobackupex: MySQL binlog position: filename …

We added some new features to our backup tool, namely:

• Now we can handle log file taken during backup with size exceeding 4GB, it may happen if backup takes too long and you have a lot of updates on InnoDB tables
• Progress meter during recovery step, now you can see what percentage of log file was handled

PLAIN TEXT CODE:

1. InnoDB: Doing recovery: scanned up to log sequence number 1316 3688693248 (34 %)
2. ...
3. InnoDB: Doing recovery: scanned up to log sequence number 1316 4113366528 (68 %)
4. InnoDB: Doing recovery: scanned up to log sequence number 1316 4117548544 (68 %)

Also we did extensive testing and fixed bugs, so now we consider current state as feature complete and with beta-release stability.

You can …

We are coming with next version of xtrabackup - online backup solution for MySQL 5.0 / 5.1 and InnoDB standard version, plugin modification and XtraDB. We still consider it as alpha version, though it shows perfect stable results in our tests.

Let me address two often asked question about xtrabackup:
1) Does it work only with XtraDB or with InnoDB also ?
A: xtrabackup is designed to work with standard version of InnoDB in MySQL 5.0. MySQL 5.1 + standard InnoDB / InnoDB-plugin also are supported. It can fully work as drop-in replacement of innodbackup tool and InnoDB Hot Backup online backup.

2) Do we need to run patched MySQL, because the build instruction mentions the patch for MySQL ?
A: xtrabackup can be run with any version of MySQL: community release, enterprise release, percona builds, ourdelta distributions. You do not need to patch …

Percona presented two talks at PHP Quebec last week - one on A Tour of MySQL High Availability, and another on Performance Tuning MySQL. There was a great reaction to showcasing some of the quick-wins that can be found by using the Percona patches. Unfortunately, the one thing that I forgot to mention in the slides is that the patches are Open Source and free to use.

Entry posted by morgan | 4 comments

Add to: | …

After I wrote about things you need to know about MySQL backups, a customer contacted me and asked me what I know about SecoBackup for MySQL. I see it has a very low cost and Percona has Amazon accounts for testing purposes, so I quickly downloaded s3sql_2.2.0.1-2.01_i386.deb, installed it, configured it, and gave it a whirl.

Since I just want to see what it does to take a backup, I started up a sandbox running from /tmp/12345 and configured it to backup msandbox:msandbox@127.0.0.1 (I shut down my main mysqld on my laptop to make sure it can’t connect to the default instance).

Then I configured a backup set and tried to take a backup. Right away I saw it isn’t full featured enough. It doesn’t let you specify a port to connect to. This …

After some sprint coding and testing I am more than happy to declare Xtrabackup getting into alpha stage. And alpha means more that we have some dirty hacks in code / not fully scripted builds / not fully tested all MySQL versions, but backups work just fine! I am able to backup our production box and restore it!

As there were some questions how xtrabackup works, let me explain it: it is supposed to be online, non-blocking backup solution for InnoDB / XtraDB engines for MySQL 5.0 / 5.1 versions. Currently we tested only for 5.0.75 / 5.0.77 and it works just fine. We also modified innobackup script ( thanks InnoDB for making it GPL), so it can be used to backup of MyISAM tables also.

Beside standard --backup and --prepare options we have implemented --throttle to limit IO activity during backup, so we do not hurt production box by intensive file copying operations.

As for now it is available only in source code version on …

Are you using someone else's backup solution for your MySQL data? Do you care a lot about your data? Are you sure you're getting a reliable, recoverable backup that'll work for your business and your application, and won't impact your critical processes while it runs? Here are ten questions you need to be able to answer:

1. Does the backup require shutting down MySQL? If not, what is the impact on the running server? Blocking, I/O load, cache pollution, etc?
2. What technique is used for the backup? Is it mysqldump or a custom product that does something similar? Is it a filesystem copy?
3. Does the backup system understand that you cannot back up InnoDB by simply copying its files?
4. Does the backup use FLUSH TABLES, LOCK TABLES, or FLUSH TABLES WITH READ LOCK? These all interrupt processing.
5. What other effects are there on MySQL? I've seen systems that do a RESET MASTER, which …

If you are using InnoDB Hot Backup utility and the innobackup.pl wrapper script, be very careful if you are not running backups under the system mysql user. There is a bug which causes InnoDB Hot Backup to sometimes report a successful backup when it actually failed.

The last few dozen lines of the output was from the backup was (after generalizing the db and table names):

InnoDB: File name /var/lib/mysql/data/dbname/TABLE_A.frm
InnoDB: File operation call: 'stat'.
090210Â  3:55:00Â  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name /var/lib/mysql/data/dbname/TABLE_B.frm
InnoDB: File operation call: 'stat'.
090210Â  3:55:00Â  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name …

I keep reading that Ma.gnolia’s data is permanently lost because “a specialist had been unable to recover any data from the corrupted hard drive.” This is not in itself a reason to consider data completely lost.

It is not clear to me whether the hard drive itself is unusable, e.g. the spindle won’t spin and the head won’t read the ones and zeroes, or whether the filesystem is corrupted. It sounds to me, from reading Larry Hallf’s comments, like it’s a simple matter of filesystem corruption. And even if the disk is dead, there is apparently a backup made from the corrupted filesystem, so there should be more than one way to …