XtraBackup简介
XtraBackup取代innodbbackup的工具并且XtraBackup能够完全兼容innodb存储引擎，并对innodb存储引擎实现完全的物理层的热备。
官方站点：http://www.percona.com/
percona本身对mysql做了修改，并拥有更高的性能，其为percona server
并且percona server对mysql本身的修改还提供了同步复制集群功能，所以percona在圈子的影响力甚至超过了mysql官方。
对于MyISAM表只能是温备，而且也不支持增量备份
XtraBackup更多高级特性通常只能在innodb存储引擎上实现，而且高级特性还都依赖于mysql数据库对innodb引擎实现了单独表空间，否则没办法实现单表或单库导出
使用每表单个表空间
在使用xtrabackup之前，我们需要查看我们当前mysql是否是使用每表单个表空间，如果不是则必须将其修改为每表单独表空间
mysql> show global variables like '%innodb_file_p%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF |
+-----------------------+-------+
1 row in set (0.00 sec)
这里是关闭状态，由此我们要启动这个功能，将来一旦要用到xtrabackup或各种高级功能的话建议刚安装mysql的时候直接将默认配置去写进配置文件，中途再更改的话会非常麻烦，好在我们是测试环境，需能将数据导出更改配置再进行导入
[root@test2 ~]#mysqldump -uroot --lock-all-tables --all-databases --master-data=2 --events> ./1.sql
关闭数据库
[root@test2 ~]#/etc/init.d/mysqld stop
Shutting down MySQL.. SUCCESS!
编辑配置文件加入以下参数
[root@test2 ~]# vim/etc/my.cnf
innodb_file_per_table= 1
而后删除数据文件并重新初始化
[root@test2 data]#pwd
/mydata/data
删除所有数据文件
[root@test2 data]# rm -fr *
初始化mysql
[root@test mysql]#pwd
/usr/local/mysql
[root@test mysql]# scripts/mysql_install_db --user=mysql--datadir=/mydata/data/ --basedir=/usr/local/mysql/
[root@test mysql]#/etc/init.d/mysqld start
再次查看是否是每表单独表空间
mysql> showglobal variables like '%innodb_file_per%';
+-----------------------+-------+
|Variable_name | Value |
+-----------------------+-------+
|innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00sec)
恢复数据
mysql> source~/1.sql
[root@test2 data]#ll wpdb/
total 220
-rw-r--r--. 1 mysqlmysql 61 Apr 6 11:05 db.opt
-rw-r--r--.1 mysql mysql 8646 Apr 6 11:05 students.frm
-rw-r--r--.1 mysql mysql 98304 Apr 6 11:05students.ibd
-rw-r--r--. 1 mysql mysql 8556 Apr 6 11:05 tb4.frm
-rw-r--r--. 1 mysql mysql 98304 Apr 6 11:05 tb4.ibd
如上所示每个表都有单独对应的表空间了
安装percona-xtrabackup
解决依赖关系
[root@test ~]# yum-y install libaio perl-Time-HiRes perl-DBD-MySQL perl-IO-Socket-SSL
首先安装percona-xtrabackup
[root@test2 tools]#rpm -ivh percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm
warning:percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm: Header V4 DSA/SHA1 Signature,key ID cd2efd2a: NOKEY
Preparing... ########################################### [100%]
1:percona-xtrabackup ###########################################[100%]
查看软件相应属性
[root@test tools]#rpm -qlpercona-xtrabackup
/usr/bin/innobackupex #统一命令接口
/usr/bin/innobackupex-1.5.1
/usr/bin/xbcrypt
/usr/bin/xbstream #支持流式备份
/usr/bin/xtrabackup
/usr/bin/xtrabackup_55 #分别应用于mysql5.5 和5.6的工具，会根据程序自动判断mysql当前版本而后应用与之匹配的工具来进行备份的
/usr/bin/xtrabackup_56
/usr/share/doc/percona-xtrabackup-2.1.4
/usr/share/doc/percona-xtrabackup-2.1.4/COPYING
使用xtrabackup实现完全备份
xtracbackup备份innodb表的时候可以实现热备，但是备份方式比较简单，首先表结构备份的文件是直接复制的，数据文件是通过读取其相应的数据块LSN号（日志序列号）而后再去判断是否需要备份，其完全备份就是从序列号0到目前为止最新的序列号进行备份
而后增量备份的时候会从上一次备份完成或增量备份以来的序列号到当前最新的序列号进行备份的，所以它是通过来扫描每个数据块的日志序列号判定其是否需要备份以及如何进行备份的
完全备份毋庸置疑，每个块都需要备份
增量备份一定是从上一次备份的序列号向后直到更新的序列号的数据块
所以是在物理级别直接备份数据块的
在实现备份的时候会在相关目录下生成以下几个文件：
xtrabackup_checkpoints 检查点文件
·备份类型（如完全或增量）
·备份状态（如是否已经为prepared状态，简单来讲，所备份的数据，不能立即用来恢复，还需要对其做一次将所有的事物日志中的事物已提交的事物进行同步至数据文件，将未提交的事物进行回滚，这个过程被称为预处理过程，因此备份处理的数据如果没有做好预处理的话是不能拿来恢复的）
LSN(日志序列号)范围信息，比如：
·完全备份LSN号范围 0-16000
·增量备份LSN号范围 16001-17000
·第二次备份LSN号范围17001-18000
·通过LSN号码判定当前是完全还是增量，并且增量到哪种程度（从上一次到目前变化的数据）
对xtrabackup来讲，当我们使用完全备份+增量备份之后，如果我们期望恢复的时候期望使用完全+增量进行恢复必须知道以下几点：
1、事务日志中有些日志被提交还有些日志未被提交，而未提交的事物需要回滚；
2、一但如果在第一次增量中有一些事物在完全备份的时候没有被提交单是在做第一次增量备份的时候被提交了，在完全备份中回滚中去那么这么次还原就没有任何意义，所以使用xtra备份数据，并跟我们之前使用mysqldump恢复的流程一样，而是先使完全备份而后将完全备份做好预处理，只不过执行预处理的时候只对完全备份进行一半的处理；
3、只将已经提交的事物同步至数据文件，而未提交的事物不回滚；
4、所以只要有增量未提交的事物是不能回滚的，而后在已经提交的事物同步至于数据文件以后开始向完全备份中应用第一个增量备份（假如有多个增量备份的数据），将增量备份合并至完全备份中去，所以第一个增量中有些事物已经提交了但是完全备份数据中则没有被提交过，所以对其进行合并，合并完成则将第二个增量进行合并，以此类推。
5、合并完数据之后LNS号已经是从0至当前最新的LNS号码；完后则使用二进制再对其进行恢复。
因此当我们有增量备份的时候，一定不能回滚未提交事物，否则增量将无法使用，如果不再回滚未提交事物，那么最后一个增量也有可能存在未提交事物，那么这时只能启动mysql 让其对数据库进行修复操作，所以最后一个阶段是依赖于mysql自身存储引擎
使用xtrabackup实现完全备份的话过程非常简单，但需要注意的是必须只有执行权限的用户才能够去备份
如果要使用一个最小权限的用户进行备份，则可基于如下命令创建此类用户：
mysql> CREATEUSER ’bkpuser’@’localhost’ IDENTIFIED BY ’s3cret’;
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM ’bkpuser’;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’bkpuser’@’localhost’; #授权，这三个权限是保证备份的最小权限
mysql> FLUSHPRIVILEGES;
这里由于是测试环境，我们就使用root进行备份/还原
实现数据库完全备份
建立目录让其作为xtrabackup备份目录
[root@test2 ~]#mkdir /innobackup
使用innobackupex 命令对数据库进行完全备份
[root@test2innobackup]# innobackupex --user=root --password=mypasswd /innobackup/
备份过程中，如果出现” innobackupex: completed OK!” 代表已经备份成功
备份过程中其他信息：
xtrabackup: Transactionlog of lsn (1613626) to (1613626) was copied. #逻辑号码从0一直到1613626
备份文件以当前时间命名
[root@test2innobackup]# ll -th /innobackup/2014-04-06_15-02-15/
total 19M
-rw-r--r--. 1 rootroot 13 Apr 6 15:02 xtrabackup_binary
-rw-r-----. 1 rootroot 89 Apr 6 15:02 xtrabackup_checkpoints
-rw-r-----. 1 rootroot 2.5K Apr 6 15:02 xtrabackup_logfile
drwxr-xr-x. 2 rootroot 4.0K Apr 6 15:02 performance_schema
drwx------. 2 rootroot 4.0K Apr 6 15:02 wpdb
drwxr-xr-x. 2 rootroot 4.0K Apr 6 15:02 mysql
drwxr-xr-x. 2 rootroot 4.0K Apr 6 15:02 test
-rw-r--r--. 1 rootroot 23 Apr 6 15:02 xtrabackup_binlog_info
-rw-r-----. 1 rootroot 18M Apr 6 15:02 ibdata1
-rw-r--r--. 1 rootroot 260 Apr 6 15:02 backup-my.cnf
备份文件说明
xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。会自动记录二进制位置的，不需要手动记录；
xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。特定于innodb存储引擎的；
xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；
backup-my.cnf —— 备份命令用到的配置选项信息，将选项全部保留；
目前操作，主要我们关注xtrabackup_checkpoints
[root@test22014-04-06_15-02-15]# cat xtrabackup_checkpoints
backup_type =full-backuped #备份类型为完全备份
from_lsn = 0 #从哪个逻辑单元号开始
to_lsn = 1613626 #到哪个逻辑单元号码
last_lsn = 1613626 #上一次最近最后一个单元号码
compact = 0 #是否压缩，0为没有，以没有为加密方式备份
#对应二进制文件的事件位置
[root@test2 2014-04-06_15-02-15]# catxtrabackup_binlog_info
mysql-bin.000001 107
二进制本身的日志文件
[root@test22014-04-06_15-02-15]# file xtrabackup_logfile
xtrabackup_logfile:data
备份数据时使用的配置文件信息
关于mysqld相关配置
[root@test22014-04-06_15-02-15]# cat backup-my.cnf
# This MySQLoptions file was generated by innobackupex.
# The MySQL server
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=5242880
innodb_fast_checksum=0
innodb_page_size=16384
innodb_log_block_size=512
备份完成之后是不能用来直接恢复的，还需要做准备工作
如果有增量备份只能提交事物不能回滚事物
使用--apply-log参数提已提交事物至数据文件，回滚提交事物
使用此参数的时候必须确保mysqld已启动
这里后面再说
如果做了完全备份之后，没有出现任何意外情况，也没修改任何数据，那么就在这时数据库崩溃了，所以我们要对其进行恢复操作
恢复数据
恢复过程必须将mysql停止，毫无疑问
[root@test2data]# /etc/init.d/mysqld stop
[root@test2data]# pwd
/mydata/data
删除所有数据
[root@test2data]# rm -fr *
要进行恢复的话首先必须准备完全备份，则使用apply-log参数指定备份位置即可
[root@test2data]# innobackupex --copy-back /innobackup/2014-04-06_15-02-15/
恢复的时候不需要密码
[root@test2data]# innobackupex --copy-back /innobackup/2014-04-06_15-02-15/
数据已经成功恢复，但是文件的属组却变了，需要手动更改属组
确保修改完成，接下来启动服务
[root@test2data]# chown mysql.mysql -R *
[root@test2data]# /etc/init.d/mysqld start
StartingMySQL.... [ OK ]
查看数据库是否存在
mysql>show databases;
mysql>show tables;
使用innobackup进行增量备份
既然是增量备份那么就必须指定是基于哪个文件做的增量备份
如果期望现在就做一次备份的话，那么每次恢复的时候都需要立即做完全备份
一次完整的备份过程
进行完全备份
我们要以之前的基础上再次做一次完整备份
[root@test2innobackup]# innobackupex --user=root --password=mypasswd /innobackup/
[root@test2innobackup]# ls /innobackup/
2014-04-06_15-33-17
对数据库做修改操作
mysql>use wpdb;
Databasechanged
mysql>create table tb2(id int);
QueryOK, 0 rows affected (0.06 sec)
mysql>create table tb3(id int);
QueryOK, 0 rows affected (0.15 sec)
mysql>insert into tb4 values ('1'),('2'),('3');
QueryOK, 3 rows affected (0.03 sec)
Records:3 Duplicates: 0 Warnings: 0
使用参数incremental对其做增量备份
格式：
#innobackupex --incremental /backup --incremental-basedir=BASEDIR
指定备份目录/backup 并且告知增量是相对于--incremental-basedir=/路径
第一次增量对应为上一次完全备份，第二次增量对应为第一次增量以此类推。所以这里明确说明增量相对位置
而对于MyISAM表是没办法做增量备份的，所以每次对MyISAM做备份的时候都是完全备份，准备增量备份与准备完全备份有所不同，只提交事物，而不会滚事物
[root@test2backup]# innobackupex --user=root --password=mypasswd--defaults-file=/etc/my.cnf --incremental /backup/--incremental-basedir=/innobackup/2014-04-06_15-33-17/
查看文件
[root@test2backup]# ll /backup/2014-04-06_15-40-04/
total360
-rw-r--r--.1 root root 260 Apr 6 15:40 backup-my.cnf
-rw-r-----.1 root root 327680 Apr 6 15:40ibdata1.delta
-rw-r-----.1 root root 44 Apr 6 15:40 ibdata1.meta
drwxr-xr-x.2 root root 4096 Apr 6 15:40 mysql
drwxr-xr-x.2 root root 4096 Apr 6 15:40 performance_schema
drwxr-xr-x.2 root root 4096 Apr 6 15:40 test
drwx------.2 root root 4096 Apr 6 15:40 wpdb
-rw-r--r--.1 root root 13 Apr 6 15:40 xtrabackup_binary
-rw-r--r--.1 root root 23 Apr 6 15:40 xtrabackup_binlog_info
-rw-r-----.1 root root 93 Apr 6 15:40 xtrabackup_checkpoints
-rw-r-----.1 root root 2560 Apr 6 15:40 xtrabackup_logfile
查看位置
[root@test22014-04-06_15-40-04]# cat xtrabackup_checkpoints
backup_type= incremental #类型为增量备份
from_lsn= 1615147 #从此位置开始，这个位置正是完全备份后的最后的位置
to_lsn= 1621213 #到此位置结束
last_lsn= 1621213
compact= 0
如果做第二次增量的话与上面是一样的，只不要指定上一次增量为basedir
再次修改数据库
mysql>drop table tb2;
QueryOK, 0 rows affected (0.03 sec)
mysql>create table tb5(id int);
QueryOK, 0 rows affected (0.03 sec)
mysql>show tables;
+----------------+
|Tables_in_wpdb |
+----------------+
|students |
|tb1 |
|tb3 |
|tb4 |
|tb5 |
+----------------+
5 rowsin set (0.00 sec)
接下来做第二次增量
明确指定上一次备份的路径
[root@test22014-04-06_15-40-04]# innobackupex --user=root --password=mypasswd--defaults-file=/etc/my.cnf --incremental /backup/ --incremental-basedir=/backup/2014-04-06_15-40-04/
[root@test22014-04-06_15-40-04]# ll /backup/ -th
total8.0K
drwxr-xr-x.6 root root 4.0K Apr 6 15:54 2014-04-06_15-54-14
drwxr-xr-x.6 root root 4.0K Apr 6 15:40 2014-04-06_15-40-04
验证第二次增量
[root@test2backup]# cd 2014-04-06_15-54-14/
[root@test22014-04-06_15-54-14]# cat xtrabackup_checkpoints
backup_type= incremental
from_lsn= 1621213 ##上一次增量的位置，与上一次备份位置对应
to_lsn= 1625355
last_lsn= 1625355
compact= 0
第二次增量我们又做了一次操作，而操作完后没有对其做额外备份，这时只能依赖二进制日志文件进行恢复
mysql>create table tb6(id int);
QueryOK, 0 rows affected (0.06 sec)
mysql>drop table tb5;
QueryOK, 0 rows affected (0.01 sec)
在生产环境下二进制文件必须在其他目录，这里我们放在同一目录下，所以只能将其备份，不然无法恢复
[root@test2data]# cp mysql-bin.000001 ~/
使数据库崩溃
/etc/init.d/mysqldstop
[root@test2data]# rm -fr *
恢复数据
涉及参数：
--apply-log
--redo-only
使用以上参数进行准备工作，准备依然是--allpy-log ,而又增量备份时则需加--redo-only参数，意思为不做提交，回滚事物
首先进行完全备份恢复：
[root@test2data]# innobackupex --apply-log --redo-only /innobackup/2014-04-06_15-33-17/
恢复第一个增量
[root@test2data]# innobackupex --apply-log --redo-only /innobackup/2014-04-06_15-33-17/ --incremental-dir=/backup/2014-04-06_15-40-04/
恢复第二个增量
[root@test2data]# innobackupex --apply-log --redo-only /innobackup/2014-04-06_15-33-17/ --incremental-dir=/backup/2014-04-06_15-54-14/
验证是否恢复
切换至完全备份目录中
[root@test2data]# cd /innobackup/2014-04-06_15-33-17/
[root@test22014-04-06_15-33-17]# cat xtrabackup_checkpoints
backup_type= full-prepared
from_lsn= 0
to_lsn= 1625355
last_lsn= 1625355
compact= 0
我们看到已经将之前的增量备份合并到完全备份的数据文件中，那么接下来再次进行恢复
使用copy-back参数恢复数据，指定完全备份目录
[root@test22014-04-06_15-33-17]# innobackupex --copy-back /innobackup/2014-04-06_15-33-17/
一旦我们使用--apply-log 对其做合并的时候，完全备份的lsn已经被修改了
因为我们合并了完全备份，这个备份就已经到最后的状态了
如上，我们已经记下了最后的lns号码状态，那么再来看一下最后增量备份的位置
[root@test22014-04-06_15-33-17]# cat /backup/2014-04-06_15-54-14/xtrabackup_checkpoints
backup_type= incremental
from_lsn= 1621213
to_lsn= 1625355
last_lsn= 1625355
compact= 0
有了这个信息，我们就可以确定我们的恢复是没有任何问题的，一旦合并了后面几个增量就没有意义了，可以将其删除了，然后恢复之后再次对其做完全备份
修改权限
[root@test22014-04-06_15-33-17]# cd /mydata/data/
[root@test2data]# chown -R mysql.mysql *
[root@test2data]# ll
total18448
-rw-r--r--.1 mysql mysql 18874368 Apr 6 16:06ibdata1
drwxr-xr-x.2 mysql mysql 4096 Apr 6 16:06 mysql
drwxr-xr-x.2 mysql mysql 4096 Apr 6 16:06 performance_schema
drwxr-xr-x.2 mysql mysql 4096 Apr 6 16:06 test
drwxr-xr-x.2 mysql mysql 4096 Apr 6 16:06 wpdb
启动数据库
[root@test2data]# /etc/init.d/mysqld start
查看数据
mysql>use wpdb;
Databasechanged
mysql>show tables;
+----------------+
|Tables_in_wpdb |
+----------------+
|students |
|tb1 |
|tb3 |
|tb4 |
|tb5 |
+----------------+
5 rowsin set (0.00 sec)
由此我们发现之前我们创建了表tb6 删除了表tb5 但目前的表是为备份之后删除和创建的表，所以我们需要应用二进制日志文件，将库恢复如初
使用二进制文件进行最后恢复
进入完全备份目录
[root@test22014-04-06_15-33-17]# cat xtrabackup_binlog_info
mysql-bin.000001 758
查看增量备份目录的binglog位置
[root@test22014-04-06_15-33-17]# cd /backup/2014-04-06_15-54-14/
[root@test22014-04-06_15-54-14]# cat xtrabackup_binlog_info
mysql-bin.000001 758
可以看到我们已经完全合并了信息，并且明确说明二进制日志的位置，记下当前位置号
[root@test2~]# cd
[root@test2~]# mysqlbinlog mysql-bin.000001
找到758之后的信息
# at758
#14040615:58:21 server id 1 end_log_pos 845 Query thread_id=5 exec_time=0 error_code=0
SETTIMESTAMP=1396771101/*!*/;
createtable tb6(id int)
/*!*/;
# at845
#14040615:58:30 server id 1 end_log_pos 950 Query thread_id=5 exec_time=0 error_code=0
SETTIMESTAMP=1396771110/*!*/;
DROPTABLE `tb5` /* generated by server */
/*!*/;
DELIMITER;
# Endof log file
将758之后的信息导出到单独文件并恢复至mysql
[root@test2~]# mysqlbinlog --start-position=758 mysql-bin.000001 > source.sql
进入mysql关闭log_bin
mysql>set sql_log_bin=0;
QueryOK, 0 rows affected (0.00 sec)
导入数据文件
mysql>source ~/source.sql
查看数据
mysql>show tables;
+----------------+
|Tables_in_wpdb |
+----------------+
|students |
|tb1 |
|tb3 |
|tb4 |
|tb6 |
+----------------+
5 rowsin set (0.00 sec)
如上所示，tb5已经被清除，tb6已经被恢复
再次进行完全备份，以防万一
[root@test2data]# innobackupex --user=root --password=mypasswd /innobackup/
Xtrabackup其他高级功能
·流式压缩功能
xtrabackup对备份的数据文件支持“流”功能，即可以将备份的数据通过STDOUT传输给tar程序进行归档，而不是默认的直接保存至某备份目录中。要使用此功能，仅需要使用--stream选项即可。如
innobackupex--stream=tar /backup | gzip > /backup/`date +%F_%H-%M-%S`.tar.gz
·使用tar将其编码为数据流之后再通过ssh将数据流传送至备份服务器
#innobackupex --stream=tar /backup | ssh user@IP "cat - > /backups/`date +%F_%H-%M-%S`.tar"
在执行本地备份时，还可以使用--parallel选项对多个文件进行并行复制。此选项用于指定在复制时启动的线程数目。当然，在实际进行备份时要利用此功能的便利性，也需要启用innodb_file_per_table选项或共享的表空间通过innodb_data_file_path选项存储在多个ibdata文件中。
·对某一数据库的多个文件的复制无法利用到此功能。其简单使用方法如下：
#innobackupex --parallel /path/to/backup# innobackupex --stream=tar /backup | ssh user@IP "cat - > /backups/`date+%F_%H-%M-%S`.tar"
导入导出单张表：
[root@test2tmp]# innobackupex --help | grep export
--export
This option is passed directly toxtrabackup's --export option. It
enables exporting individual tablesfor import into another server.
#每个表都会被导入出保存为单独相应表文件，偶尔在某些情况下我们是需要在数据库间移动表的，这时export参数就显得格外的重要
首先对其做完全备份
[root@test2tmp]# innobackupex --user=root --password=mypasswd /innobackup/
完全备份之后对其apply-log的时候加入参数export即可
[root@test2tmp]# innobackupex --apply-log --export /innobackup/2014-04-06_13-17-12/
[root@test22014-04-06_13-17-12]# ll
total 30756
-rw-r--r--. 1 root root 260 Apr 6 13:17backup-my.cnf
-rw-r-----. 1 root root 18874368Apr 6 13:19 ibdata1
-rw-r--r--. 1 root root 5242880Apr 6 13:19 ib_logfile0
-rw-r--r--. 1 root root 5242880Apr 6 13:19 ib_logfile1
drwxr-xr-x. 2 root root 4096 Apr 6 13:17 mysql
drwxr-xr-x. 2 root root 4096Apr 6 13:17 performance_schema
drwxr-xr-x. 2 root root 4096Apr 6 13:17 test
drwx------. 2 root root 4096 Apr 6 13:19 wpdb
-rw-r--r--. 1 root root 13 Apr 613:17 xtrabackup_binary
-rw-r--r--. 1 root root 23 Apr 613:17 xtrabackup_binlog_info
-rw-r--r--. 1 root root 23 Apr 613:19 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 root root 89 Apr 613:19 xtrabackup_checkpoints
-rw-r-----. 1 root root 2097152Apr 6 13:19 xtrabackup_logfile
导入表
由此我们将其导入到其他数据库中或导入单独一个库中
在被导入服务器或库操作，必须确保其使用单独表空间
首先创建表结构
mysql>show create table students;
得出数据：
CREATETABLE `students` (
`name` char(30) NOT NULL,
`id` tinyint(3) unsigned DEFAULT NULL,
`Age` tinyint(3) unsigned DEFAULT NULL,
`class` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
创建对应表，要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入
mysql>CREATE TABLE `students` ( `name`char(30) NOT NULL, `id` tinyint(3)unsigned DEFAULT NULL, `Age` tinyint(3)unsigned DEFAULT NULL, `class`varchar(20) NOT NULL, PRIMARY KEY(`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;
QueryOK, 0 rows affected (0.08 sec)
删除此表的表空间
ALTERTABLE test11.students DISCARD TABLESPACE;
接下来，将来自于“导出”表的服务器的students表的xxx.ibd和xxxx.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：
mysql>ALTER TABLE test11.students IMPORTTABLESPACE;