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


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的位置从而达到恢复的目的,仅此而已。