环境描述：原mysql实例有db1、db2库，只迁移db1库到新的mysql实例。迁移后测试存储过程、触发器迁移成功；在新mysql实例中新建db2库并在db2库中创建与源库相同的表，可以正常创建，不会有与公共表空间原数据冲突的问题。

一、备份源实例中的所有库，恢复指定库进行迁移

创建存储过程

create procedure t1pro(a1 int,b1 int) begin declare a2 int; declare b2 int; declare c2 int; set a2=a1; set b2=b1; set c2=a2+b2; insert into t1 values(a2,b2,c2); end//

创建触发器

create trigger t1trigger before update on t1 for each row begin insert into t2 values(old.a,new.a,old.b,new.b,old.c,new.c); end;//

1、 完整备份

innobackupex --defaults-file=/home/local/mysql/my.cnf --user=root --password=probiz  --socket=/mylvmnt/mysql.sock  /home/bakup/20120722/1550

2、恢复指定的库

复制备份文件

cp -R 2012-07-22_00-50-35/ filebak

cd filebak/

删除db2库的备份

rm -rf db2

使用复制的备份文件恢复数据

innobackupex --apply-log --user=root --password=probiz --socket=/mylvmnt/mysql.sock --defaults-file=/home/local/mysql/my.cnf /home/bakup/20120722/1550/filebak/

3、迁移到新的mysql实例

使用二进制包部署新的mysql，注意配置中的表公共表空间、使用独立表空间、联机重做日志的配置一定要和备份mysql一致。

把恢复好的ibdata1、ibdata2、ib_logfile0、ib_logfile1、ib_logfile2、db1目录及其下的文件、mysql目录及其下的文件复制到/home/local/mysql3308/data目录(新mysql实例的数据目录)下，并把复制好的文件属主和属组改为mysql，并把复制好的权限设置为660。

注意一定要公共表空间和联机重做日志复制到新的mysql实例，如果使用新mysql实例生产的公共表空间和联机重做日志，并在新的实例中新建相同的表再把表的独立空间文件复制到新实例中会导致表的独立表空间文件的ID与公共表空间中记录的表的独立表空间文件ID不同，访问该表时导致mysqld重启。

另外要注意的是如果新的mysql实例不是全新的，在新的mysql实例中有原来其他库就不能用从源实例备份中恢复的公共表空间文件和联机重做日志覆盖新实例中的相同文件，如果覆盖是导致mysql无法启动或启动后访问不了原有库。

启动新的mysql实例，测试存储过程、触发器及各表mysql库中的记录(如用户权限等)都正常。

测试创建db2数据库，用use db2进入db2库，创建备份库中的表test和test2都可以正常创建。

二、备份指定库，进行迁移

1、备份:只备份db1库

vi  table.txt

db1.audit.frm

db1.t1

db1.audit

db1.db.opt

db1.t1.frm

db1.t1.TRG

db1.testref.TRN

注意：db1.t1不能写成db1.t1.ibd,如果写成db1.t1.ibd innobackupex 调用xtrabackup时是不会备份t1.ibd文件的。

innobackupex --defaults-file=/home/mysql/mysql3308/my.cnf --user=root --password=probiz --socket=/home/mysql/mysql3308/data/mysql.sock   --tables-file=./tables.txt    /home/bak/20120721/1812/

2、恢复

innobackupex --apply-log --defaults-file=/home/mysql/mysql3308/my.cnf  --user=root --password=probiz --socket=/home/mysql/mysql-3306/data/mysql.sock /home/bak/20120721/1812/2012-07-21_18-19-10/

检查/home/bak/20120721/1812/2012-07-21_18-19-10/目录下如果生成了3个联机重做日志就恢复成功了(备份的数据库配置是3个联机重做日志)

3、部署新的mysql，注意配置中的表公共表空间、使用独立表空间、联机重做日志的配置一定要和备份mysql一致。

4、把/home/bak/20120721/1812/2012-07-21_18-19-10/目录下的公共表空间文件和联机重做日志文件复制到新mysql的数据目录。

5、把/home/bak/20120721/1812/2012-07-21_18-19-10/db1(db1是个数据库)目录及目录下的文件复制到新的mysql的数据目录中。把mysql数据目录下的公共表空间文件和联机日志文件的属主和属组改为mysql用户，权限设置为660；/home/mysql/mysql3310/data/db1目录下的文件属主和属组改为mysql用户，权限设置为660.

注意一定要公共表空间和联机重做日志复制到新的mysql实例，如果使用新mysql实例生产的公共表空间和联机重做日志，并在新的实例中新建相同的表再把表的空间文件复制到新实例中会导致独立表空间文件的ID与公共表空间中记录的独立表空间文件ID不同，访问该表时导致mysqld重启。

另外要注意的是如果新的mysql实例不是全新的，在新的mysql实例中有原来其他库就不能用从源实例备份中恢复的公共表空间文件和联机重做日志覆盖新实例中的相同文件，如果覆盖是导致mysql无法启动或启动后访问不了原有库。

6、启动新的mysql实例，登录验证。

工作心得：

1、要完整查看与自己操作相关的日志及其它输出信息。此次innobackupex备份迁移mysql，在新的mysql实例中创建相同表，然后用恢复的独立表空间文件覆盖新实例中的独立表空间文件导致独立表空间文件ID与公共表空间中记录的独立表空间文件ID不一致导致访问迁移库时mysqld会重启(无法访问该库)。想删除表无法删除，在执行删除表或重命名表的操作时就会在mysql错误日志文件中写入独立表空间文件ID与公共表空间中记录的独立表空间ID不一致。但自己只看了后10调记录，没看操作时间中产生的全部日志，以致浪费了大量时间做了很多无用功。

2、操作前先想好操作步骤(流程)。

3、使用一款软件时要弄清楚其工作原理，这样遇到问题才能有依据的分析问题，否则就只会使用指令，     不断的瞎操作无法解决问题。

4、在32为linux上使用64位的xtrabackup,报错无法执行的二进制文件和没有指定数据目录的错误，自己     忽略了不可执行的二进制文件的信息，以没有指定数据文件为关键字在网上搜索信息并尝试了几个小     时无法解决问题。后来想到不可执行的二进制文件，可能是64位的文件，用file命令查看果然是64为     的文件，换32位程序后问题解决。

此次由于工作方法不对导致几分钟可以解决的问题使用了几个小时。

改善：

收集完整错误信息，对每条信息进行分析，把各个原因列出来，从最容易验证的原因开始实施验证，接下来验证第二容易解决的原因，依此类推最后验证最难解决的原因提升工作效率。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21582653/viewspace-736323/，如需转载，请注明出处，否则将追究法律责任。