Mysql5.6支持在线修改表结构
2014-07-07 14:05
288 查看
周五研发提出需求,根据工业业务,需要对一个核心业务表,增加字段。费了老劲了。总算成功了。
总结两条:1. 明白了 tmpdir 目录设置的真正意义。
2. 深刻的体会理解了5.6在线修改表结构的过程。同时再一次验证了,支持在线修改表结构的功能。
放心的在线修改吧,什么pt-online-schema-change也弱爆了,不用那么麻烦了
可以直接修改了。
下面是具体的过程:
在修改表结构的过程中,首先对备份的表进行备份:
create table bak_pd_info as select * from productinfo.pd_info ;
该表在备份完成后,只是对表记录等进行了拷贝,不会对表重建索引。
备份完成后大约18.6G,同时备份后会造成所有从库出现延迟的现象。
备份完成后,对bak_info表进行修改表结构,在修改的过程中,会发现/ 目录不断变大,最后空间耗尽,跟新报错如下:
调整了表空间
mysql> set global max_allowed_packet=134217728;
mysql> show global variables like '%tmp%';
mysql> set global tmp_table_size=134217728;
mysql> set global max_heap_table_size=1024*1024*1024
mysql> rename table bak_pd_info to bk_pd_info;
尽管想利用更多的内存,减少临时表,但是发现32G的临时目录远远不够,当备份表bak_pd_info为18.6G时40分钟后,当数据传输估算有3分之二时,即报空间满的错误。
mysql 默认的临时表空间位置 /tmp
所以空间不足是最主要的原因,办法有2个:
1. 增大临时表空间磁盘空间。
2. 修改临时表空间路径,指向较大的空间。 需要重启数据库
本次采用第二种方法:
1. 重启163
tmpdir=/data/mysql
2. 重启172 /173
tmpdir=/data/mysql
166
tmpdir=/data/mysql
replicate_wild_ignore_table=productinfo.%
3. 165 162 181 都重启过。
备份pd_info表。
重启161 所有的从库都指向162
修改表结构。
ALTER TABLE pd_info ADD prokey VARCHAR(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
mysql> ALTER TABLE productinfo.pd_info ADD prokey VARCHAR(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;
Query OK, 0 rows affected (2 hours 55 min 3.24 sec)
Records: 0 Duplicates: 0 Warnings: 0
发现在更改过正中,原表25.3G,用临时表空间:53G多。
重原状,重启:
161 162
166 165 172 172 163 181
总结两条:1. 明白了 tmpdir 目录设置的真正意义。
2. 深刻的体会理解了5.6在线修改表结构的过程。同时再一次验证了,支持在线修改表结构的功能。
放心的在线修改吧,什么pt-online-schema-change也弱爆了,不用那么麻烦了
可以直接修改了。
下面是具体的过程:
在修改表结构的过程中,首先对备份的表进行备份:
create table bak_pd_info as select * from productinfo.pd_info ;
该表在备份完成后,只是对表记录等进行了拷贝,不会对表重建索引。
备份完成后大约18.6G,同时备份后会造成所有从库出现延迟的现象。
备份完成后,对bak_info表进行修改表结构,在修改的过程中,会发现/ 目录不断变大,最后空间耗尽,跟新报错如下:
调整了表空间
mysql> set global max_allowed_packet=134217728;
mysql> show global variables like '%tmp%';
mysql> set global tmp_table_size=134217728;
mysql> set global max_heap_table_size=1024*1024*1024
mysql> rename table bak_pd_info to bk_pd_info;
尽管想利用更多的内存,减少临时表,但是发现32G的临时目录远远不够,当备份表bak_pd_info为18.6G时40分钟后,当数据传输估算有3分之二时,即报空间满的错误。
mysql 默认的临时表空间位置 /tmp
所以空间不足是最主要的原因,办法有2个:
1. 增大临时表空间磁盘空间。
2. 修改临时表空间路径,指向较大的空间。 需要重启数据库
本次采用第二种方法:
1. 重启163
tmpdir=/data/mysql
2. 重启172 /173
tmpdir=/data/mysql
166
tmpdir=/data/mysql
replicate_wild_ignore_table=productinfo.%
3. 165 162 181 都重启过。
备份pd_info表。
重启161 所有的从库都指向162
修改表结构。
ALTER TABLE pd_info ADD prokey VARCHAR(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
mysql> ALTER TABLE productinfo.pd_info ADD prokey VARCHAR(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;
Query OK, 0 rows affected (2 hours 55 min 3.24 sec)
Records: 0 Duplicates: 0 Warnings: 0
发现在更改过正中,原表25.3G,用临时表空间:53G多。
重原状,重启:
161 162
166 165 172 172 163 181
相关文章推荐
- 在线修改MySQL大表的表结构
- mysql 在线修改表结构工具 gh-ost
- mysql在线修改表结构大数据表的风险与解决办法归纳
- MySQL在线修改表结构pt-osc
- mysql在线修改表结构大数据表的风险与解决办法归纳
- mysql在线修改表结构大数据表的风险与解决办法归纳
- MySQL5.6在线表结构变更(online ddl)总结
- mysql在线修改表结构大数据表的风险与解决办法归纳
- mysql5.6在线DDL修改字段测试
- mysql在线修改表结构大数据表的风险与解决办法归纳
- mysql在线修改表结构大数据表的风险与解决办法归纳
- MySQL5.6在线表结构变更(online ddl)总结
- mysql在线修改表结构大数据表的风险与解决办法归纳(数据量大的时候,alter死锁表)
- 在线修改MySQL大表的表结构
- mysql在线修改表结构大数据表的风险与解决办法归纳
- mysql 主从复制双主架构在线修改表结构、在线DDL
- 在线修改MySQL大表的表结构
- MySQL使用pt-online-change-schema工具在线修改1.6亿级数据表结构
- mysql修改表名,查看表结构,删除表
- 不停机修改mysql表结构