在Mysql中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入。如果某一个表数据量很大,导出dump文
在Mysql中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入。如果某一个表数据量很大,导出dump文件很大的情况下,使用导出导入工具其实会花费不少的时间.
怎么样提高效率呢,可以有一种想法就是直接拷贝数据文件到目标环境,当然在早期版本中这么做是不可取的,因为会有很多关联数据在ibdata中,InnoDB的数据存在对应的数据字典信息,是存放在共享表空间中,无法直接剥离出来,而在5.6/5.7中,就推出了一个很不错的特性,就是迁移表空间,可以把这个配置信息剥离出来,简单来说就是把数据文件直接拷贝到目标环境,在目标端挂载即可。
这样一个操作的一个基本前提是使用了独立表空间,开启innodb_file_per_table.
>show variables like '%per_table%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)
我们做一个有代表意义的测试,比如把某一个表从Mysql 5.6环境迁移到MySQL 5.7环境中。
我们选择一个表users作为测试所用,数据量在2万条左右。数据文件情况:
-rw-rw---- 1 mysql mysql 8602 Feb 13 23:10 users.frm
-rw-rw---- 1 mysql mysql 11534336 Mar 12 22:55 users.ibd数据情况:
> select count(*) from users;
+----------+
| count(*) |
+----------+
| 20001 |
+----------+
1 row in set (0.01 sec)我们开始迁移数据,首先要生成一个cfg文件,导出配置信息。
>flush tables users for export;
Query OK, 0 rows affected (0.00 sec)
这个命令值得一提的是,保持当前的窗口,不要关闭,如果关闭,cfg文件就会自动删除,可以看到命令运行后生成了cfg文件。
-rw-rw---- 1 mysql mysql 599 Mar 13 08:17 users.cfg
-rw-rw---- 1 mysql mysql 8602 Feb 13 23:10 users.frm
-rw-rw---- 1 mysql mysql 11534336 Mar 12 22:55 users.ibd在flush table之后,这个表users就被锁定了,DML操作是阻塞的,也就意味着迁移的过程中,是无法直接写入数据的。
>insert into users values(20234312310,'aa');
ERROR 1099 (HY000): Table 'users' was locked with a READ lock and can't be updated表users的定义信息如下,可以使用show create table users或者mysqldump --no-date test users这种方式得到。
DROP TABLE IF EXISTS `users`;
CREATE TABLE `users` (
`userid` int(11) unsigned NOT NULL,
`username` varchar(64) DEFAULT NULL,
PRIMARY KEY (`userid`),
KEY `username` (`username`),
KEY `idx_users` (`userid`,`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;而cfg文件的格式有一些明显的差别,可以通过strings一窥其中的概要信息。
# strings users.cfg
mbionline.test.com
test/users
userid
username
DB_ROW_ID
DB_TRX_ID
DB_ROLL_PTR
PRIMARY
userid
DB_TRX_ID
DB_ROLL_PTR
username
username
username
userid
idx_users
userid
username完成之后推出会话,设置unlock tables即可。
目标端的操作非常关键,目标端是MySQL 5.7的环境。
首先需要在目标端创建相应的空表。然后使用如下的语句把数据文件截断。
> alter table users discard tablespace;
cp /tmp/users.cfg /home/mysql/test
cp /tmp/users.ibd /home/mysql/test这个时候尤其需要注意文件的权限,拷贝完成,我们就可以通过import tablespace来进行数据文件挂载。
> alter table users import tablespace;
ERROR 1808 (HY000): Schema mismatch (Table flags don't match, server table has 0x5 and the meta-data file has 0x1)或者下面的错误:
> alter table users import tablespace;
ERROR 1808 (HY000): Schema mismatch (Table has ROW_TYPE_DYNAMIC row fORMat, .ibd file has ROW_TYPE_COMPACT row format.)通过错误信息可以发现和表的一个属性有关。我们先解决问题,添加属性row_format
CREATE TABLE `users` (
`userid` int(11) unsigned NOT NULL,
`username` varchar(64) DEFAULT NULL,
PRIMARY KEY (`userid`),
KEY `username` (`username`),
KEY `idx_users` (`userid`,`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 row_format=compact;然后继续尝试Import tablespace操作。
> alter table users discard tablespace;
Query OK, 0 rows affected (0.00 sec)可见整个过程是非常快的,执行完成之后,我们检查一下表的情况。[test]> check table users;
+------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------+-------+----------+----------+
| test.users | check | status | OK |
+------------+-------+----------+----------+
1 row in set (0.16 sec)查看表的数据进行验证。
[test]> select count(*)from users;
+----------+
| count(*) |
+----------+
| 20001 |
+----------+
1 row in set (0.00 sec)这样迁移的过程就告一段落,我们很顺利的把一个表从MySQL 5.6迁移到了5.7环境中。
回到刚刚碰到的问题,为什么在5.6迁移至5.7会有报错。
> alter table users import tablespace;
ERROR 1808 (HY000): Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, .ibd file has ROW_TYPE_COMPACT row format.)原因就是Innodb_file_format在5.6中是Antelope,在MySQL 5.7中是Barracuda,主要是在表压缩和行的动态格式上有所改变。更详细的内容可以参考:
其实这个特性在oracle中已经有耳熟能详的的方案,TTS,支持跨平台,转换字节顺序,甚至可以支持基于增量备份的迁移方案,MySQL中的迁移方式和Oracle传统的TTS有些相似。当然上面的操作还可以使用Percona的工具innobackupex 来完成,我们下一篇来进行演示。
怎么能够形象的表达这种迁移的感觉呢,我连超市里看葡萄酒都能看成 read write。
--结束END--
本文标题: MySQL传输表空间小结(r12笔记第2天)
本文链接: https://lsjlt.com/news/48443.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0