Chinaunix首页 | 论坛 | 博客
  • 博客访问: 308439
  • 博文数量: 33
  • 博客积分: 586
  • 博客等级: 中士
  • 技术积分: 494
  • 用 户 组: 普通用户
  • 注册时间: 2012-09-27 14:05
个人简介

衡铁刚 1)2011-2013:Alibaba MySQL DBA 2)2014-至今: Alibaba 数据库PD

文章分类

全部博文(33)

文章存档

2016年(1)

2015年(10)

2013年(5)

2012年(17)

我的朋友

分类: Mysql/postgreSQL

2013-07-30 23:27:44

对于数据迁移需求,如果在备份中心有备份集,直接从备份恢复过去是一种比较常规的方式,一般都会有脚本或系统来支持,从速度上说中规中矩,备份文件都是压缩过(pigz、pbzip2、gzip),不过发现解压过程始终无法耗尽恢复机器IO,怀疑解压使用单线程(这块尚未证实),如果没有备份集,需要恢复且时间上不宽裕,采用老路子就不行了,只好直接拷贝了,说来这种直接拷贝在日常生活中遇到问题的第一反应,但在工作上往往用不上,久而久之就遗忘了

对于需要迁移的数据一般是数据库数据文件,数据迁移从源机器上读取,[压缩] 网络传输 [解压],写到目标机器,速度优化提升目标就是在将目标机器IO压满,根据是否可以将网卡跑满来决定是否启用压缩,这就需要各方面的数据支持(这块目前欠缺),最近经常使用nc+qpress,速度不错

【1】文件迁移
目标机器:nohup nc -d -k -l 50863 | nohup /home/mysql/qpress -T32dif /data/ &
源机器:nohup /home/mysql/qpress -T32K20480orf /data |nohup  nc IP 50863 &

【2】数据库迁移
目标机器:nohup nc -d -k -l 50863 | nohup /home/mysql/qpress -T32diof |nohup  tar  -ixf - -C /bak/backup_20130726 &
源机器:nohup innobackupex  --user=root --defaults-file=/data/my.cnf   --slave-info --stream=tar --tmpdir=/data /data 2>/home/mysql/back.lo
g |nohup /home/mysql/qpress -T32K20480iof - |nohup  nc IP 50863 &

nc+qpress+tar+innobackupex ,这4个工具都比较容易上手,但合起来使用还是需要多调试下,上面迁移方式在某种场景上需要调整下管道流的输入数据才能正常使用(这块暂时没有深入研究),还无法做成比较通用的工具
阅读(4210) | 评论(0) | 转发(1) |
0

上一篇:运维DBA工作技巧

下一篇:集群迁移

给主人留下些什么吧!~~