MySQL Performance Blog » Backups http://www.mysqlperformanceblog.com Everything about MySQL Performance Sat, 21 Nov 2009 03:11:18 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 Statistics of InnoDB tables and indexes available in xtrabackup http://www.mysqlperformanceblog.com/2009/09/14/statistics-of-innodb-tables-and-indexes-available-in-xtrabackup/ http://www.mysqlperformanceblog.com/2009/09/14/statistics-of-innodb-tables-and-indexes-available-in-xtrabackup/#comments Mon, 14 Sep 2009 16:52:53 +0000 Vadim http://www.mysqlperformanceblog.com/?p=1095 If you ever wondered how big is that or another index in InnoDB ... you had to calculate it yourself by multiplying size of row (which I should add is harder in the case of a VARCHAR - since you need to estimate average length) on count of records. And it still would be quite inaccurate as secondary indexes tend to take more space. So we added more detailed index statistics into our xtrabackup utility. The thanks for this feature goes to a well known Social Network who sponsored the development.

We chose to put this into xtrabackup for a couple of reasons - the first is that running statistics on your backup database does not need to hurt production servers, and the second reason is that running statistic on a stopped database is more accurate than with online (although online is also supported, but you may have inexact results).

Let's see how it works. I have one table with size 13Gb what was filled during about 2.5 years.
The table is:

PLAIN TEXT
CODE:
  1. CREATE TABLE `link_out104` (
  2.   `domain_id` int(10) unsigned NOT NULL,
  3.   `link_id` int(10) unsigned NOT NULL auto_increment,
  4.   `url_from` varchar(255) NOT NULL,
  5.   `url_to` varchar(255) NOT NULL,
  6.   `anchor` varchar(255) NOT NULL,
  7.   `from_site_id` int(10) unsigned NOT NULL,
  8.   `from_forum_id` int(10) unsigned NOT NULL,
  9.   `from_author_id` int(10) unsigned NOT NULL,
  10.   `from_message_id` bigint(20) unsigned NOT NULL,
  11.   `message_published` timestamp NOT NULL default CURRENT_TIMESTAMP,
  12.   `kind` enum('link','img') NOT NULL,
  13.   `url_title` varchar(255) NOT NULL,
  14.   `isexternal` tinyint(3) unsigned NOT NULL,
  15.   `revert_domain` varchar(255) NOT NULL,
  16.   `url_prefix` varchar(255) NOT NULL,
  17.   `from_domain_id` int(10) unsigned NOT NULL,
  18.   `ext` varchar(25) NOT NULL,
  19.   `linktype` enum('html','video','mp3','image','pdf','other') NOT NULL,
  20.   `message_day` date NOT NULL,
  21.   `mod_is` tinyint(3) unsigned NOT NULL default '0',
  22.   `is_adult` tinyint(3) unsigned NOT NULL default '0',
  23.   PRIMARY KEY  (`link_id`),
  24.   UNIQUE KEY `domain_id_2` (`domain_id`,`link_id`),
  25.   KEY `domain_id` (`domain_id`,`from_site_id`,`message_published`),
  26.   KEY `revert_domain` (`revert_domain`,`url_prefix`(80)),
  27.   KEY `from_site_id` (`from_site_id`,`message_published`),
  28.   KEY `site_message` (`from_site_id`,`message_day`,`isexternal`),
  29.   KEY `from_message_id` (`from_message_id`,`link_id`)
  30. ) ENGINE=InnoDB AUTO_INCREMENT=26141165 DEFAULT CHARSET=utf8;

And size of file is about 12.88 GB

-rw-r--r-- 1 root root 13832814592 Sep 10 14:41 link_out104.ibd

So to get statistics we run:

xtrabackup --stats --tables=art.link* --datadir=/mnt/data/mysql/

which will show something like this:

PLAIN TEXT
CODE:
  1. <INDEX STATISTICS>
  2.  
  3.   table: art/link_out104, index: PRIMARY, space id: 12, root page 3
  4.   estimated statistics in dictionary:
  5.     key vals: 25265338, leaf pages 497839, size pages 498304
  6.   real statistics:
  7.      level 2 pages: pages=1, data=5395 bytes, data/pages=32%
  8.      level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
  9.         leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%
  10.  
  11.   table: art/link_out104, index: domain_id_2, space id: 12, root page 4
  12.   estimated statistics in dictionary:
  13.     key vals: 27755790, leaf pages 23125, size pages 26495
  14.   real statistics:
  15.      level 2 pages: pages=1, data=510 bytes, data/pages=3%
  16.      level 1 pages: pages=30, data=393125 bytes, data/pages=79%
  17.         leaf pages: recs=25958413, pages=23125, data=337459369 bytes, data/pages=89%
  18.  
  19.   table: art/link_out104, index: domain_id, space id: 12, root page 5
  20.   estimated statistics in dictionary:
  21.     key vals: 3006231, leaf pages 43255, size pages 49600
  22.   real statistics:
  23.      level 2 pages: pages=1, data=2850 bytes, data/pages=17%
  24.      level 1 pages: pages=114, data=1081375 bytes, data/pages=57%
  25.         leaf pages: recs=25953873, pages=43255, data=545031333 bytes, data/pages=76%
  26.  
  27.   table: art/link_out104, index: revert_domain, space id: 12, root page 6
  28.   estimated statistics in dictionary:
  29.     key vals: 1204830, leaf pages 133869, size pages 153984
  30.   real statistics:
  31.      level 3 pages: pages=1, data=373 bytes, data/pages=2%
  32.      level 2 pages: pages=6, data=58143 bytes, data/pages=59%
  33.      level 1 pages: pages=832, data=9146283 bytes, data/pages=67%
  34.         leaf pages: recs=25839414, pages=133869, data=1566961607 bytes, data/pages=71%
  35.  
  36.   table: art/link_out104, index: from_site_id, space id: 12, root page 7
  37.   estimated statistics in dictionary:
  38.     key vals: 330426, leaf pages 33889, size pages 38848
  39.   real statistics:
  40.      level 2 pages: pages=1, data=1764 bytes, data/pages=10%
  41.      level 1 pages: pages=84, data=711669 bytes, data/pages=51%
  42.         leaf pages: recs=25956416, pages=33889, data=441259072 bytes, data/pages=79%
  43.  
  44.   table: art/link_out104, index: site_message, space id: 12, root page 8
  45.   estimated statistics in dictionary:
  46.     key vals: 1399286, leaf pages 32260, size pages 36992
  47.   real statistics:
  48.      level 2 pages: pages=1, data=1680 bytes, data/pages=10%
  49.      level 1 pages: pages=80, data=677460 bytes, data/pages=51%
  50.         leaf pages: recs=25956043, pages=32260, data=441252731 bytes, data/pages=83%
  51.  
  52.   table: art/link_out104, index: from_message_id, space id: 12, root page 9
  53.   estimated statistics in dictionary:
  54.     key vals: 25964521, leaf pages 27979, size pages 28160
  55.   real statistics:
  56.      level 2 pages: pages=1, data=798 bytes, data/pages=4%
  57.      level 1 pages: pages=38, data=587559 bytes, data/pages=94%
  58.         leaf pages: recs=25958413, pages=27979, data=441293021 bytes, data/pages=96%

The output is intensive, let me highlight some points:

PLAIN TEXT
CODE:
  1. table: art/link_out104, index: PRIMARY, space id: 12, root page 3
  2.         leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

It says that PRIMARY key (which is the table by itself, as InnoDB is clustering data by primary key) takes 497839 pages ( 16KB each) and size of data 7492026403 bytes or (6.98 GB). And density ( fitting data into pages) is quite good - 91%. But it was expected, as table is really mostly inserted in, updates and deletes are rare).

And let's take index domain_id

PLAIN TEXT
CODE:
  1. table: art/link_out104, index: domain_id, space id: 12, root page 5
  2.         leaf pages: recs=25953873, pages=43255, data=545031333 bytes, data/pages=76%

you can see the allocated pages (43255 pages or 708689920 bytes) are filled only by 76% ( data takes 545031333 bytes). And that means that 150MB are just waste of space. Which is really even worse for key revert_domain

leaf pages: recs=25839414, pages=133869, data=1566961607 bytes, data/pages=71%
.

For this key about 600MB is empty.

This needs a bit of explaining:
This does not have as good efficiency as the primary key, but a lot of this is to be expected. In a lot of cases we insert into the primary key in order which makes things very predictable, but the inserts into the secondary key index are random - which leads to a lot of page splits.

One helpful new feature to address this is in XtraDB/InnoDB plugin - fast index creation. With this feature, InnoDB creates indexes by sort, so page fill factor should be quite good.

To check that, there is xtrabackup --stats for index domain_id created for table in Barracuda format with Fast creation method:

PLAIN TEXT
CODE:
  1. table: art/link_out104, index: domain_id, space id: 15, root page 49160
  2.   estimated statistics in dictionary:
  3.     key vals: 5750565, leaf pages 34383, size pages 34496
  4.   real statistics:
  5.      level 2 pages: pages=1, data=1375 bytes, data/pages=8%
  6.      level 1 pages: pages=55, data=859575 bytes, data/pages=95%
  7.         leaf pages: recs=25958413, pages=34383, data=545126673 bytes, data/pages=96%

As you see this time it takes 34383 pages (compare to 43255 in previous statistics).

Though it would be interesting to see how it will grow with further inserts, and I also suspect random INSERTS into so dense space going to be slower than in previous case.

The --stats is not in xtrabackup release yet, only in source code repository, but should be released quite soon.

And the last point of the post - if you are badly missing some features in MySQL, InnoDB, InnoDB-plugin, XtraDB, XtraBackup - you know whom ask for!

Entry posted by Vadim | 5 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/09/14/statistics-of-innodb-tables-and-indexes-available-in-xtrabackup/feed/ 5 xtrabackup-0.9 http://www.mysqlperformanceblog.com/2009/08/20/xtrabackup-0-9/ http://www.mysqlperformanceblog.com/2009/08/20/xtrabackup-0-9/#comments Thu, 20 Aug 2009 18:51:16 +0000 Aleksandr Kuzminsky http://www.mysqlperformanceblog.com/?p=1026 Dear Community,

The release 0.9 of the opensource backup tool for InnoDB and XtraDB is available for download.

Changelog:

  • tar4ibd could not treat over 8GB file, now max 64GB
  • prepare-speed-hack is added

Fixed bugs:

The binary packages for RHEL4,5, Debian, FreeBSD, MacOS as well as source code of the XtraBackup is available on http://www.percona.com/mysql/xtrabackup/0.9/.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki.

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona.

Entry posted by Aleksandr Kuzminsky | 4 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/08/20/xtrabackup-0-9/feed/ 4 Just how useful are binary logs for incremental backups? http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/ http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/#comments Tue, 21 Jul 2009 20:26:23 +0000 Morgan Tocker http://www.mysqlperformanceblog.com/?p=843 We've written about replication slaves lagging behind masters before, but one of the other side effects of the binary log being serialized, is that it also limits the effectiveness of using it for incremental backup.  Let me make up some numbers for the purposes of this example:

  • We have 2 Servers in a Master-Slave topology.
  • The database size is 100 GB (same tables on each).
  • The slave machine barely keeps up with the master (at 90% capacity during peak, 75% during offpeak)
  • The peak window is 12 hours, the offpeak window is 12 hours.

Provided that the backup method was raw data files, it shouldn't take much more than 30 minutes to restore 100GB (50MB/s), but to replay one day of binary logs  it would take an additional 20 hours ((12 * 0.9) + (12 * 0.75) = 19h48m).

If you wanted to do something like setup a new slave with a 24-hour old backup, and apply the binary logs continuously until it catches up, you will be waiting almost 5 days until that happens (each day has 24hr-19h48m = 4h12m "free" capacity, 19h48m/4h12m = 4.7 days).

So what are the solutions?
If you are using all InnoDB tables, an XtraBackup incremental backup should be much faster than using binary logs.  You can understand Vadim's excitement when he announced this feature a few months ago.

If you are using multiple storage engines, then your options are to either try and time delay slaves (to keep them close to up to date), or hope that it's not often that you need to restore!  Eventually this problem should be lessened by a MySQL Server feature - parallel execution on slaves.  Lets hope that it can get enough testers so that it makes it into a new release very quickly.

Entry posted by Morgan Tocker | 6 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/feed/ 6 Improving InnoDB recovery time http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/ http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/#comments Wed, 08 Jul 2009 02:42:22 +0000 Vadim http://www.mysqlperformanceblog.com/?p=718 Speed of InnoDB recovery is known and quite annoying problem. It was discussed many times, see:

http://bugs.mysql.com/bug.php?id=29847

http://dammit.lt/2008/10/26/innodb-crash-recovery/

This is problem when your InnoDB crashes, it may takes long time to start. Also it affects restoring from backup (both LVM and xtrabackup / innobackup)

In this is simple test, I do crash mysql during in-memory tpcc-mysql benchmark with 16 running threads.
MySQL params are:

PLAIN TEXT
CODE:
  1. innodb_buffer_pool_size=16G
  2. innodb_log_files_in_group=3
  3. innodb_log_file_size=512M

So let's take standard MySQL 5.4.1, it starts:

PLAIN TEXT
CODE:
  1. 090706 15:39:47  InnoDB: Database was not shut down normally!
  2. ...
  3. 090706 16:51:56 [Note] libexec/mysqld: ready for connections.

So you see it takes 1h 12 mins to start.

In XtraDB we made some improvements, and it shows:

PLAIN TEXT
CODE:
  1. 090706 17:04:11  InnoDB: Database was not shut down normally!
  2. ...
  3. 090706 18:10:53 [Note] libexec/mysqld: ready for connections.

1h 06mins. Better, but still not good.

So Yasufumi sat, scratched his head and made new patch for InnoDB. With this patch
mysqld starts:

PLAIN TEXT
CODE:
  1. 090707 19:00:01  InnoDB: Database was not shut down normally!
  2. ...
  3. 090707 19:06:42 [Note] libexec/mysqld: ready for connections.

6 mins 41 secs. 10x improvement. Something to think about.

The patch is not in official XtraDB tree yet, it lives in
http://bazaar.launchpad.net/~percona-dev/percona-xtradb/recovery-speed-hack/
 tree.

The patch by itself is quite small, I would ask InnoDB experts to review it:

http://bazaar.launchpad.net/~percona-dev/percona-xtradb/recovery-speed-hack/revision/86

So your comments about patch is welcome! If it is stable it will go to XtraDB and XtraBackup.

Entry posted by Vadim | 12 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/feed/ 12 xtrabackup-0.8 http://www.mysqlperformanceblog.com/2009/07/01/xtrabackup-08/ http://www.mysqlperformanceblog.com/2009/07/01/xtrabackup-08/#comments Wed, 01 Jul 2009 15:09:04 +0000 Aleksandr Kuzminsky http://www.mysqlperformanceblog.com/?p=709 Dear community,

The release 0.8 of the opensource backup tool for InnoDB and XtraDB is available for download.

Key features:

tar4ibd is made to be sure that read of InnoDB page is consistent. Before we had some complains what in stream mode some pages are getting corrupted, and we suspect tar can do read of pages in time when they changed. So we patches libtar to make read consistent.

Export is added to support moving .ibd tablespaces between servers.

The list of other features in the release includes:

  • Support of ARCHIVE tables
  • Addded incremental option to innobackupex-1.5.1 script
  • Rollback XA PREPAREd transaction automatically at --prepare
  • To extend tablespace size, if needed after --prepare
  • Data page corruption check is added to local backup mode
  • innobackupex can pass --export option
  • Bug #389360: innobackupex-1.5.1 accepts scp options

Fixed bugs:

  • Bug #388062: Update to innobackupex to include incremental
  • fix error handling of tar stream

The binary packages for RHEL4,5, Debian, FreeBSD as well as source code of the XtraBackup is available on http://www.percona.com/mysql/xtrabackup/0.8/.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki.

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona.

Entry posted by Aleksandr Kuzminsky | 7 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/07/01/xtrabackup-08/feed/ 7 xtrabackup-0.7 (RC) http://www.mysqlperformanceblog.com/2009/05/21/xtrabackup-07-rc/ http://www.mysqlperformanceblog.com/2009/05/21/xtrabackup-07-rc/#comments Thu, 21 May 2009 13:43:18 +0000 Vadim http://www.mysqlperformanceblog.com/?p=693 We announce next version of our xtrabackup tool and we consider it stable enough to put label RC on it.

Changelist includes:

- use O_DIRECT by default for handling InnoDB files
- use posix fadvise call to disable OS caching of copying files
- disable recovery of double buffer

Also we added binary builds for FreeBSD 7 64bit platform

You can download current binaries (64bit) RPM for RHEL4 and RHEL5 (compatible with CentOS also), DEB for Debian/Ubuntu, tar.gz for Mac OS / Intel and .tar.gz for FreeBSD 7:
http://www.percona.com/mysql/xtrabackup/0.7/.
By the same link you can find general .tar.gz with binaries which can be run on any modern Linux distribution.
By the same link you can download source code if you do not want to deal with bazaar and Launchpad.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona

Entry posted by Vadim | 4 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/05/21/xtrabackup-07-rc/feed/ 4 Hint: throttling xtrabackup http://www.mysqlperformanceblog.com/2009/05/20/hint-throttling-xtrabackup/ http://www.mysqlperformanceblog.com/2009/05/20/hint-throttling-xtrabackup/#comments Thu, 21 May 2009 06:21:00 +0000 Vadim http://www.mysqlperformanceblog.com/?p=692 Using xtrabackup for copying files can really saturate your disks, and that why we made special option --throttle=rate to limit rate of IO per second. But it really works when you do local copy.
What about stream backup ? Even you copy just to remote box with
innobackupex --stream=tar | ssh remotebox "tar xfi -"
, read may be so intensive so your mysqld feels impact, slave getting behind, etc...

For this there is a nice small utility - pv .

With pv you run:
innobackupex --stream=tar | pv -q -L10m | ssh remotebox "tar xfi -"

and it will limit channel rate to 10 M per second.

Entry posted by Vadim | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/05/20/hint-throttling-xtrabackup/feed/ 0 xtrabackup-0.6 http://www.mysqlperformanceblog.com/2009/04/29/xtrabackup-06/ http://www.mysqlperformanceblog.com/2009/04/29/xtrabackup-06/#comments Wed, 29 Apr 2009 16:17:53 +0000 Vadim http://www.mysqlperformanceblog.com/?p=673 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.
By the same link you can download source code if you do not want to deal with bazaar and Launchpad.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona

Entry posted by Vadim | 6 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/04/29/xtrabackup-06/feed/ 6 xtrabackup-0.5, bugfixes, incremental backup introduction http://www.mysqlperformanceblog.com/2009/04/07/xtrabackup-05-bugfixes-introduction-incremental-backup/ http://www.mysqlperformanceblog.com/2009/04/07/xtrabackup-05-bugfixes-introduction-incremental-backup/#comments Wed, 08 Apr 2009 03:23:07 +0000 Vadim http://www.mysqlperformanceblog.com/?p=653 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 'db02-bin.001271', position 247627478
  9. 090404 06:07:58  innobackupex: innobackup completed OK!
  10. innobackupex: You must use -i (--ignore-zeros) option for extraction of the tar stream.

which gives start point 1319:813219999 for further incremental backup. This point is LSN of last checkpoint operations. Now next time when you want only copy changed pages you can do:

PLAIN TEXT
CODE:
  1. xtrabackup --incremental_lsn=1319:813219999 --backup --target-dir=/data/backup/increment_day1

and only changed pages (ones with LSN greater than given) will be copied to specified dir. You may have several incremental dir, and apply them one-by-one.

Current version does not allow to copy incremental changes to remote box or to stream, it is only local copy for now, but we are going to change it in next release. Beside putting last checkpoint LSN to output we also store it in xtrabackup_checkpoint file to use it in scripts.
More about incremental you can read on our draft page http://www.percona.com/docs/wiki/percona-xtrabackup:spec:incremental

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.5/.
By the same link you can find general .tar.gz with binaries which can be run on any modern Linux distribution.
By the same link you can download source code if you do not want to deal with bazaar and Launchpad.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona

Entry posted by Vadim | 6 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/04/07/xtrabackup-05-bugfixes-introduction-incremental-backup/feed/ 6 xtrabackup-0.4, going beta, progress meter http://www.mysqlperformanceblog.com/2009/03/30/xtrabackup-04-going-beta-progress-meter/ http://www.mysqlperformanceblog.com/2009/03/30/xtrabackup-04-going-beta-progress-meter/#comments Mon, 30 Mar 2009 17:27:36 +0000 Vadim http://www.mysqlperformanceblog.com/?p=650 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 download current binaries RPM for RHEL4 and RHEL5 (compatible with CentOS also) and DEB for Debian/Ubuntu there
http://www.percona.com/mysql/xtrabackup/0.4/.
By the same link you can find general .tar.gz with binaries which can be run on any modern Linux distribution.
By the same link you can download source code if you do not want to deal with bazaar and Launchpad.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona

Entry posted by Vadim | 7 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

]]> http://www.mysqlperformanceblog.com/2009/03/30/xtrabackup-04-going-beta-progress-meter/feed/ 7