由于公司新服务器在北京要上线，LAMP环境和性能调优已经做好。接下来就是导出数据导入之后主从同步数据。本来以为很简单的事，因为各种各样的小事故差不多搞了一个通宵，这里分享一下:
第一、凌晨锁表，进行导出操作使用命令(这里我导出函数，存储过程和事件):
mysqldump -uroot -p –opt -R –events –tirggers mall > /data/mall_$(date +%Y%m%d_%H%M).sql
第二、把生成的.sql文件放到另一个机房的机器上面然后用进行还原:
mysql -uroot -p mall<mall.sql
第三、解锁，然后在my.cnf定义主从文件(这里忽略)
第四、主从同步：主要问题:
类似情况描述(因为那个时候凌晨，我已经没有时间 慢慢截图，大致的错误描述是这样的)
090910 22:47:18 [ERROR] Got fatal error 1236: ‘Client requested master to start replication from impossible position’ from master when reading data from binary log090910 22:47:18 [Note] Slave I/O thread exiting, read up to log ‘mysql-bin.000008’, position 753871857
大概的意思就是说在主从同步的时候，数据出现了偏差，需要我们查看日志去慢慢找出，第一次报错的地方进行同步:(开始的时候试过重新查看msater status的值重新做不成功，好吧慢慢看二进制日志了)
第五、执行:
[root@im_offlog2b mysql]# mysqlbinlog –start-position=753871857 mysql-bin.000008 〉less.txt文件
然后查看第一次报错的地方:
这里可以看到最近一次报错是在107开始的，所以我们重新定义。position的值为 107 mysl-bin.0000008,再重新执行一次主从就可以了。
本来以为大功告成的，已启动查看的时候又报错，，我晕:
明显的提升是主键报错，可能是导入过程的时候，重复导入。或者网络影响的，我原来的思路是看那个表的逐渐报错，直接从主库上面导入表过来，但是发现一堆的表报错不可能那样来了，干错直接跳过这个错误，因为只是主键的话不太会影响数据的完整性:
在重库my.cnf加上:
slave_skip_errors = 1062 slave_skip_errors = all
然后重启从库:
show slave status\G发现已经成功了。
算了一下时间，1点钟起床倒数据，倒完之后穿数据，然后导入数据，已经是2点多，然后订一个闹铃5点钟，(但是发现自己没有睡着，)5点钟起床后继续弄同步，花费了将近一个小时。6点钟又躺下，9点上班。
其实年轻的时候多吃点苦无所谓。不要再最能吃苦的时候选择安逸(送一句自己最喜欢的话)
本文出自 “小罗” 博客，请务必保留此出处
怠惰是贫穷的制造厂。
