由于公司新服务器在北京要上线,LAMP环境和性能调优已经做好。接下来就是导出数据导入之后主从同步数据。本来以为很简单的事,因为各种各样的小事故差不多搞了一个通宵,这里分享一下:

第一、凌晨锁表,进行导出操作使用命令(这里我导出函数,存储过程和事件):

mysqldump -uroot -p --opt -R --events --tirggers mall > /data/mall_$(date +%Y%m%d_%H%M).sql

第二、把生成的.sql文件放到另一个机房的机器上面然后用进行还原:

mysql -uroot -p mall

第三、解锁,然后在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文件

然后查看第一次报错的地方:

wKioL1RaKwvzzzscAAB7LooxZ6M656.jpg

这里可以看到最近一次报错是在107开始的,所以我们重新定义。position的值为 107  mysl-bin.0000008,再重新执行一次主从就可以了。

本来以为大功告成的,已启动查看的时候又报错,我晕:

wKioL1RaK7jiG5fcAADtUJd8w1I969.jpg

明显的提醒是主键报错,可能是导入过程的时候,重复导入。或者网络影响的,我原来的思路是看那个表的主键报错,直接从主库上面导入表过来,但是发现一堆的表报错不可能那样来了,干错直接跳过这个错误,因为只是主键的话不太会影响数据的完整性:

在重库my.cnf加上:

 slave_skip_errors = 1062  slave_skip_errors = all   

然后重启从库:

show slave status\G发现已经成功了。

算了一下时间,1点钟起床倒数据,倒完之后传数据,然后导入数据,已经是2点多,然后订一个闹铃5点钟,(但是发现自己没有睡着,)5点钟起床后继续弄同步,花费了将近一个小时。6点钟又躺下,9点上班。

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