mysql slave的安全恢复

一.基本信息
主库：192.168.65.30
从库：192.168.65.33
版本：mysql 5.7.14
mysql参数设置：
binlog_format:row
tx_isolation:READ-COMMITTED
master_info_repository:FILE  对应
relay_log_info_repository:FILE
sync_master_info:10000
sync_relay_log_info:10000
relay_log_recovery :off

二.断电同步故障修复
针对从库主机断电引起的同步问题，如下进行针对性分析和预防问题发生。
1.relay log损坏的修复：
从库主机断电或磁盘故障引起binlog或relay log损坏：
Last_Errno: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
  由于断电或磁盘故障引起binlog或relay log损坏，sql线程无法对一个损坏的log进行读取分析和执行应用操作，mysql 5.5开始有一个参数:当设置relay_log_recovery=1时，可以从sql线程最后一次正常执行
的位置去从主库重新读取binlog。
2.从库主机断电或磁盘故障引起主键冲突修复:
Last_Errno: 1062
Last_Error: Could not execute Write_rows event on table test.sbtest5; Duplicate entry '32257' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000128, end_log_pos 532773
 出现上面报错，是因为master.info和relay log.info两文件的信息没有及时刷盘更新，导致从master中读取或执行了重复的log，产生主键冲突报1062错误。
A relay-info信息同步方式改善：
 将relay-info.log的信息保存在InnoDB的事务表中，这时执行relay log中的事务和写relay info在一个事务中，就能得到原子性保证。从而避免已执行的binlog位点和写入relay log info 的位点信息不一致的情况发生。
B master info信息同步方式改善：
 从IO thread的工作原理来看，它没有办法将写入master info和拉取binlog放到同一个事务中而保持原子操作，因此IO thread 的行为是会对数据一致性会产生影响。解决方案有：
方案一 通过参数sync_master_info可以控制fdatasync的时间。默认值是10000,表示IO线程的偏移量每10000个事务更新一次 ，通过设置其为1，每写一次事务便同步到master.info，这个会影响性能。
方案二 通过MySQL 5.5版本开始提供的参数relay_log_recovery ，当slave发生crash后重启之后重连master时，slave不根据master-info.log的信息进行重连，而是根据relay-info中执行到master的位置信息重新开始拉master上的日志数据。

3.综合性能考虑，我们采用方案二，所以最后修复方法为：
  a 停止slave的mysql实例
  b my.cnf文件中添加
   master-info-repository=TABL  #对应表名为mysql.slave_master_info
   relay-log-info-repository=TABLE #对应表名为mysql.slave_relay_log_info
   relay-log-recovery
  c 重启slave的mysql实例
三.验证修复方法是否有效
再次模拟主库写入数据的同时发生从库主机断电操作。
1.主库模拟数据写入:
sysbench --test=/data/software/sysbench-0.5/sysbench/tests/db/oltp.lua --mysql-table-engine=innodb --oltp-table-size=1000000 --max-requests=10000 \
--num-threads=100 --oltp_tables_count=10 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=admin --mysql-password=Dmjxjbgc6u \
--mysql-db=test --max-time=600 --mysql-socket=/tmp/mysql3306.sock prepare
2.从库操作：
 将从库主机断电
3.从库主机恢复
4.从库检查同步情况
 start slave;
 show slave status\G
(product)root@localhost [mysql]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.65.30
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000173
          Read_Master_Log_Pos: 93388631
               Relay_Log_File: relay-bin.000099
                Relay_Log_Pos: 93388844
        Relay_Master_Log_File: mysql-bin.000173
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 93388631

上面显示同步正常，确认方法有效。