由于公司新服务器在北京要上线,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文件
然后查看第一次报错的地方:
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点上班。
其实年轻的时候多吃点苦无所谓。不要再最能吃苦的时候选择安逸(送一句自己最喜欢的话)
©著作权归作者所有:来自51CTO博客作者小罗ge11的原创作品,如需转载,请注明出处,否则将追究法律责任
mysql服务器解决方案mysql
共同学习,写下你的评论
评论加载中...
作者其他优质文章