您的位置:首页 > 数据库 > MySQL

slave断电,mysql主从奔溃恢复从服务至正常

2016-03-30 14:40 603 查看
本想连照片一起上传的,这样更直观;很遗憾照片无法上传,但是也无法阻止我发文!!!

slave上操作:
[root@slave mysql]# tail slave.err

160121 21:44:43 [Note] Event Scheduler: Purging the queue. 0 events
160121 21:44:43 [Note] Error reading relay log event: slave SQL thread was killed
160121 21:44:43 [Note] Slave I/O thread killed while reading event
160121 21:44:43 [Note] Slave I/O thread exiting, read up to log 'test.000003', position 1048964
160121 21:44:43 InnoDB: Starting shutdown...
160121 21:44:44 InnoDB: Shutdown completed; log sequence number 0 44243
160121 21:44:44 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

160121 21:44:44 mysqld_safe mysqld from pid file /data/mysql/slave.pid ended

上面有个position值为1048964;这就是同步这个binlog位置的时候出错了;为了避免错误,先去主上面看看是不是有这个position值;

master上操作:
mysqlbinlog test.000003 >test000003.txt
vim test000003.txt#查找1048964,确定有这个位置;

slave上操作:
mysqlbinlog slave-relay-bin.000008 > 0008.txt
vim 0008.txt#查找1048964,发现1048964的位置在文件记录的最下端

上面生成的那两个txt还可以对比下内容,两者1048964位置附近内容是一致的,所以确定1048964这个位置是slave奔溃前同步主的位置了

继续从上操作:
mysql
slave stop;#显示OK
change master to master_host='192.168.20.125', master_port=3306, master_user='repl',master_password='123456', master_log_file='test.000003', master_log_pos=1049044;
#重新change master to;报错!!
ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
只能先清空了
reset slave;#显示OK;再重新操作上面的change master to;就可以执行了;显示OK
slave start;#显示OK
show slave status\G; #IO和SQL线程Yes,主从恢复。查询下数据库表,发现数据都同步了过来了

注:mysqlbinlog后那几步操作,如果在比较大的日志文件中直接vim后查找需要很长时间和特别费劲;
可以先grep -n 1048964 0008.txt,得出他的行号,再使用tail和head 截取他们的一段。

最后说说,mysql主从配置不难;只是很脆弱,需要写个脚本监控,在此不阐述;
奔溃后应该怎么恢复,这得理清mysql主从的机制;mysql主从运行机制大概为:
1.Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;
3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的。

从上面第三点可以理解恢复的时候应该怎么操作了;也就是指定binlog的位置从而达到恢复的目的,仅此而已。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息