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

Posted 2020-07-01

本想连照片一起上传的，这样更直观；很遗憾照片无法上传，但是也无法阻止我发文！！！

slave上操作：

[[email protected] 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的位置从而达到恢复的目的，仅此而已。

本文出自 “kw_lee” 博客，请务必保留此出处http://11398377.blog.51cto.com/11388377/1758396