由于公司新服务器在北京要上线，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定义主从文件(这里忽略)

第四、主从同步：主要问题:

类似情况描述(因为那个时候凌晨，我已经没有时间 慢慢截图，大致的错误描述是这样的)

0910 22:47:18 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
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 log
090910 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点上班。

其实年轻的时候多吃点苦无所谓。不要再最能吃苦的时候选择安逸(送一句自己最喜欢的话)