标签：mysql thread sequence position mysql主从.mysql主从奔溃
本想连照片一起上传的，这样更直观；很遗憾照片无法上传，但是也无法阻止我发文！！！
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的位置从而达到恢复的目的，仅此而已。
本文出自 “kw_lee” 博客，请务必保留此出处http://11398377.blog.51cto.com/11388377/1758396
标签：mysql thread sequence position mysql主从.mysql主从奔溃
原文地址：http://11398377.blog.51cto.com/11388377/1758396
