如题，究竟该使用mysqldump还是xtrabackup，要说用，两个都能备份，都支持热备，但是生产环境我们要考虑的是效率，就是不管备份还是恢复，都要快，要稳定。
之前我在维护mysql数据库的时候，使用mysqldump来进行备份与恢复，在备份的时候锁住表，然后全部备份，在数据少的时候没问题，但如果数据很多，不允许锁表，同时需要恢复数据块的情况，mysqldump就不适合了，我在恢复一个4G数据文件的数据库的时候，恢复的数据是使用mysqldump的数据，恢复了3个小时还没有反应，造成的影响很严重，所以我开始寻找其他的别发软件来满足以上的需求，幸好找到了，就是使用
xtrabackup_55 version 1.6.7 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined)
incremental backup from 59605543 is enabled.
xtrabackup: cd to /tmp/restore
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(59606124)
xtrabackup: page size for /tmp/data/2013-03-07_21-13-44//ibdata1.delta is 16384 bytes
Applying /tmp/data/2013-03-07_21-13-44//ibdata1.delta ...
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /tmp/data/2013-03-07_21-13-44/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
130307 21:18:20 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
130307 21:18:20 InnoDB: The InnoDB memory heap is disabled
130307 21:18:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130307 21:18:20 InnoDB: Compressed tables use zlib 1.2.3
130307 21:18:20 InnoDB: Using Linux native AIO
130307 21:18:20 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
130307 21:18:20 InnoDB: Initializing buffer pool, size = 100.0M
130307 21:18:20 InnoDB: Completed initialization of buffer pool
130307 21:18:20 InnoDB: highest supported file format is Barracuda.
InnoDB: ##########################################################
InnoDB: WARNING!
InnoDB: The log sequence number in ibdata files is higher
InnoDB: than the log sequence number in the ib_logfiles! Are you sure
InnoDB: you are using the right ib_logfiles to start up the database?
InnoDB: Log sequence number in ib_logfiles is 59606124, log
InnoDB: sequence numbers stamped to ibdata file headers are between
InnoDB: 59607052 and 59607052.
InnoDB: ##########################################################
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130307 21:18:20 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 107, file name /var/log/mysql/mysql-bin.000023
130307 21:18:29 InnoDB: Waiting for the background threads to start
130307 21:18:30 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 59606124
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 107, file name /var/log/mysql/mysql-bin.000023
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
130307 21:18:30 InnoDB: Starting shutdown...
130307 21:18:34 InnoDB: Shutdown completed; log sequence number 59607339
innobackupex: Starting to copy non-InnoDB files in '/tmp/data/2013-03-07_21-13-44/'
innobackupex: to the full backup directory '/tmp/restore'
innobackupex: Copying '/tmp/data/2013-03-07_21-13-44/xtrabackup_binlog_info' to '/tmp/restore/xtrabackup_binlog_info'
innobackupex: Copying '/tmp/data/2013-03-07_21-13-44/test/test.frm' to '/tmp/restore/test/test.frm'
innobackupex: Copying '/tmp/data/2013-03-07_21-13-44/test/db.opt' to '/tmp/restore/test/db.opt'
130307 21:18:34 innobackupex: completed OK!
然后再进入恢复的目录/tmp/data
root@client2:/var/lib/mysql# cd /tmp/data
root@client2:/tmp/data# ll
total 3276
drwxr-xr-x 3 root root4096 Mar 7 21:13 ./
drwxrwxrwt 14 root root4096 Mar 7 21:18 ../
drwxr-xr-x 3 root root4096 Mar 7 21:18 2013-03-07_21-13-44/
-rw-r--r-- 1 root root3780 Mar 7 21:02 test-201303072101.log
-rw-r--r-- 1 root root 3336909 Mar 7 21:02 test-201303072101.tar.gz
root@client2:/tmp/data# cd 2013-03-07_21-13-44/
root@client2:/tmp/data/2013-03-07_21-13-44# ll
total 2288
drwxr-xr-x 3 root root4096 Mar 7 21:18 ./
drwxr-xr-x 3 root root4096 Mar 7 21:13 ../
-rw-r--r-- 1 root root 260 Mar 7 21:13 backup-my.cnf
-rw-r--r-- 1 root root 212992 Mar 7 21:13 ibdata1.delta
-rw-r--r-- 1 root root 18 Mar 7 21:13 ibdata1.meta
drwxr-xr-x 2 root root4096 Mar 7 21:14 test/
-rw-r--r-- 1 root root 13 Mar 7 21:14 xtrabackup_binary
-rw-r--r-- 1 root root 23 Mar 7 21:14 xtrabackup_binlog_info
-rw-r--r-- 1 root root 84 Mar 7 21:14 xtrabackup_checkpoints
-rw-r--r-- 1 root root 2097152 Mar 7 21:18 xtrabackup_logfile
跟全部备份一样，把test恢复到/var/lib/mysql里
root@client2:/tmp/data/2013-03-07_21-13-44# rsync -avz test ib* /var/lib/mysql/
sending incremental file list
test/
test/db.opt
test/test.frm
sent 381 bytes received 54 bytes 870.00 bytes/sec
total size is 8621 speedup is 19.82
root@client2:/tmp/data/2013-03-07_21-13-44# cd /var/lib/mysql/
root@client2:/var/lib/mysql# ll
total 77860
drwx------ 8 mysql mysql 4096 Mar 7 21:19 ./
drwxr-xr-x 38 root root 4096 Mar 7 19:52 ../
-rw-r--r-- 1 root root 0 Jan 5 14:22 debian-5.5.flag
drwx------ 2 mysql mysql 4096 Feb 11 17:39 django/
-rw-rw---- 1 mysql mysql 69206016 Mar 7 21:17 ibdata1
-rw-rw---- 1 mysql mysql 5242880 Mar 7 21:17 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 Mar 7 21:11 ib_logfile1
drwx------ 2 mysql mysql 4096 Jan 5 22:55 monitor/
drwx------ 2 mysql root 4096 Jan 5 14:22 mysql/
-rw-rw---- 1 root root 6 Jan 5 14:22 mysql_upgrade_info
drwx------ 2 mysql mysql 4096 Jan 5 14:22 performance_schema/
drwxr-xr-x 2 root root 4096 Mar 7 21:14 test/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 19:58 xtrbackup/
然后修改用户与组
root@client2:/var/lib/mysql# chown -R mysql:mysql test/
root@client2:/var/lib/mysql# ll
total 77860
drwx------ 8 mysql mysql 4096 Mar 7 21:19 ./
drwxr-xr-x 38 root root 4096 Mar 7 19:52 ../
-rw-r--r-- 1 root root 0 Jan 5 14:22 debian-5.5.flag
drwx------ 2 mysql mysql 4096 Feb 11 17:39 django/
-rw-rw---- 1 mysql mysql 69206016 Mar 7 21:17 ibdata1
-rw-rw---- 1 mysql mysql 5242880 Mar 7 21:17 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 Mar 7 21:11 ib_logfile1
drwx------ 2 mysql mysql 4096 Jan 5 22:55 monitor/
drwx------ 2 mysql root 4096 Jan 5 14:22 mysql/
-rw-rw---- 1 root root 6 Jan 5 14:22 mysql_upgrade_info
drwx------ 2 mysql mysql 4096 Jan 5 14:22 performance_schema/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 21:14 test/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 19:58 xtrbackup/
然后启动msyql，并查看test数据库里test表的内容
root@client2:/var/lib/mysql# service mysql start
mysql start/running, process 13109
root@client2:/var/lib/mysql# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.5.28-0ubuntu0.12.04.3-log (Ubuntu)
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from test;
+------+
| id |
+------+
|1 |
|2 |
|3 |
|4 |
|5 |
| 11 |
| 12 |
| 13 |
| 14 |
| 15 |
+------+
10 rows in set (0.00 sec)
可以看到增量备份已经恢复完成。
下面的链接